Fwd: Re: [PATCH][RFC] appling preasure to icache and dcache
-- Forwarded Message --
Subject: Re: [PATCH][RFC] appling preasure to icache and dcache
Date: Tue, 3 Apr 2001 17:22:10 -0400
From: Ed Tomlinson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: l
On Tuesday 03 April 2001 11:03, Benjamin Redelings I wrote:
> Hi, I'm glad somebody is working on this! VM-time seems like a pretty
> useful concept.
Think it might be useful for detecting trashing too. If vmtime is made
to directly relate to the page allocation rate then you can do something
like this. Let K be a number intially representing 25% of ram pages.
Because vmtime is directly releated to allocation rates its meanful to
subtract K from the current vmtime. For each swapped out page, record
the current vmtime. Now if the recorded vmtime of the page you are
swapping in is greater than vmtime-K increment A otherwise increment B.
If A>B we are thrashing. We decay A and B via kswapd. We adjust K
depending on the swapping rate. Thoughts?
> I think you have a bug in your patch here:
>
> + if (base > pages) /* If the cache shrunk reset base, The
> cache
> + base = pages;* growing applies preasure as does
> expanding
> + if (free > old) * free space - even if later shrinks */
> + base -= (base>free-old) ? free-old : base;
>
> It looks like you unintentionally commented out two lines of code?
Geez. That will teach me to add comments _after_ testing the code...
The patch as it stands, will not apply pressure as the caches expands.
Good catch. Thanks.
> I have been successfully running your patch. But I think it needs
> benchmarks. At the very least, compile the kernel twice w/o and twice
> w/ your patch and see how it changes the times. I do not think I will
> have time to do it myself anytime soon unfortunately.
> I have a 64Mb RAM machine, and the patch makes the system feel a little
> bit slower when hitting the disk. BUt that is subjective...
Where I see a difference is with backups. With the patch applied they take
about 2:20 or so, and use over 60K inodes/dentries, without the patch they
take 2:35 (plus or minus 5 mins) and use over 190K inodes/dentries. On a box
with lots of memory pressure (ie with 64M) I doubt that the calls to shrink
the caches get triggered often from my code - expect that you are usually
shrinking via do_try_to_free_pages. What might cause your subjective
difference may be the change in:
refill_inactive_scan(DEF_PRIORITY, delta);
You might want to try replacing this delta with 0 (in kswapd). If this
improves things for you I have to do a little rethinking...
Corrected patch follows:
---
diff -u -r --exclude-from=ex.txt linux.ac28/mm/page_alloc.c
linux/mm/page_alloc.c --- linux.ac28/mm/page_alloc.c Sun Apr 1 18:52:22
2001
+++ linux/mm/page_alloc.c Mon Apr 2 07:54:05 2001
@@ -138,11 +138,9 @@
/*
* We don't want to protect this variable from race conditions
-* since it's nothing important, but we do want to make sure
-* it never gets negative.
+* since it's nothing important.
*/
- if (memory_pressure > NR_CPUS)
- memory_pressure--;
+ inactivate_pressure++;
}
#define MARK_USED(index, order, area) \
diff -u -r --exclude-from=ex.txt linux.ac28/mm/swap.c linux/mm/swap.c
--- linux.ac28/mm/swap.cMon Jan 22 16:30:21 2001
+++ linux/mm/swap.c Thu Mar 29 11:37:47 2001
@@ -47,10 +47,12 @@
* many inactive pages we should have.
*
* In reclaim_page and __alloc_pages: memory_pressure++
- * In __free_pages_ok: memory_pressure--
+ * In __free_pages_ok: inactivate_pressure++
+ * In invalidate_pages_scan: inactivate_pressure++
* In recalculate_vm_stats the value is decayed (once a second)
*/
int memory_pressure;
+int inactivate_pressure;
/* We track the number of pages currently being asynchronously swapped
out, so that we don't try to swap TOO many pages out at once */
@@ -287,6 +289,7 @@
* memory_pressure.
*/
memory_pressure -= (memory_pressure >> INACTIVE_SHIFT);
+ inactivate_pressure -= (inactivate_pressure >> INACTIVE_SHIFT);
}
/*
diff -u -r --exclude-from=ex.txt linux.ac28/mm/vmscan.c linux/mm/vmscan.c
--- linux.ac28/mm/vmscan.c Sun Apr 1 18:52:22 2001
+++ linux/mm/vmscan.c Mon Apr 2 07:42:55 2001
@@ -759,6 +791,8 @@
}
spin_unlock(&pagemap_lru_lock);
+ inactivate_pressure += nr_deactivated;
+
return nr_deactivated;
}
@@ -937,6 +971,76 @@
return ret;
}
+/*
+ * Try to shrink the dcache if either its size or free space
+ * has grown, and it looks like we might get the required pages.
+ * This function would simplify if the caches tracked how
+ * many _pages_ were freeable.
+ */
+int try_shrinking_dcache(int goal, unsigned int gfp_mask)
+{
+
+ /* base - proj
[PATCH][RFC] appling pressure to icache and dcache - simplified
Hi,
Rik asked, "Can it be made simpler?"
So I went back to the basics, inserted a printk in kswapd and watched
the dentry_stat and inodes_stat numbers for a while. I observed
the following pattern. The dentry cache grows as does the number of
unused entries in it. Unless we shrink this cache objects do not seem
to be reused. At the same time the inode cache usually kept about 15%
free.
At this point I starting to shrink the dcache. The goal being to keep
the size of the cache as observed in /proc/slabinfo reasonable without
much overhead. From experimenting, it turns out that if the shrink
call is made when there is over 50% free space the cache stays small.
Using 66% is not quite as aggressive but achieves its effect with about
half the shrink calls.
With the pressure on the dcache, I looked at the icache numbers. With
the dcache shrinking the amount of free space in the icache was much
higher. It turns out that using the same logic as above with, 80% as
the amount of free space, it works well.
Here are the results against 2.4.3-ac3
Thoughs?
-
--- linux.ac3.orig/mm/vmscan.c Sat Apr 7 15:20:49 2001
+++ linux/mm/vmscan.c Sat Apr 7 12:37:27 2001
@@ -997,6 +997,21 @@
*/
refill_inactive_scan(DEF_PRIORITY, 0);
+ /*
+* Here we apply pressure to the dcache and icache.
+* The nr_inodes and nr_dentry track the used part of
+* the slab caches. When there is more than X% objs free
+* in these lists, as reported by the nr_unused fields,
+* there is a very good chance that shrinking will free
+* pages from the slab caches. For the dcache 66% works,
+* and 80% seems optimal for the icache.
+*/
+
+ if ((dentry_stat.nr_unused+(dentry_stat.nr_unused>>1)) >
+dentry_stat.nr_dentry)
+ shrink_dcache_memory(DEF_PRIORITY, GFP_KSWAPD);
+ if ((inodes_stat.nr_unused+(inodes_stat.nr_unused>>2)) >
+inodes_stat.nr_inodes)
+ shrink_icache_memory(DEF_PRIORITY, GFP_KSWAPD);
+
/* Once a second, recalculate some VM stats. */
if (time_after(jiffies, recalc + HZ)) {
recalc = jiffies;
-
Ed Tomlinson <[EMAIL PROTECTED]>
-
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/
[PATCH] Re: memory usage - dentry_cacheg
Hi,
I have been playing around with patches that fix this problem. What seems to happen is
that the VM code is pretty efficent at avoiding the calls to shrink the caches. When
they
do get called its a case of to little to late. This is espically bad in lightly
loaded
systems. The following patch helps here. I also have a more complex version that uses
autotuning, but would rather push the simple code, _if_ it does the job.
-
--- linux.ac3.orig/mm/vmscan.c Sat Apr 7 15:20:49 2001
+++ linux/mm/vmscan.c Sat Apr 7 12:37:27 2001
@@ -997,6 +997,21 @@
*/
refill_inactive_scan(DEF_PRIORITY, 0);
+ /*
+* Here we apply pressure to the dcache and icache.
+* The nr_inodes and nr_dentry track the used part of
+* the slab caches. When there is more than X% objs free
+* in these lists, as reported by the nr_unused fields,
+* there is a very good chance that shrinking will free
+* pages from the slab caches. For the dcache 66% works,
+* and 80% seems optimal for the icache.
+*/
+
+ if ((dentry_stat.nr_unused+(dentry_stat.nr_unused>>1)) >
+dentry_stat.nr_dentry)
+ shrink_dcache_memory(DEF_PRIORITY, GFP_KSWAPD);
+ if ((inodes_stat.nr_unused+(inodes_stat.nr_unused>>2)) >
+inodes_stat.nr_inodes)
+ shrink_icache_memory(DEF_PRIORITY, GFP_KSWAPD);
+
/* Once a second, recalculate some VM stats. */
if (time_after(jiffies, recalc + HZ)) {
recalc = jiffies;
-
Ed Tomlinson
Alexander Viro wrote:
>
> On Wed, 11 Apr 2001, Andreas Dilger wrote:
>
>> I just discovered a similar problem when testing Daniel Philip's new ext2
>> directory indexing code with bonnie++. I was running bonnie under single
>> user mode (basically nothing else running) to create 100k files with 1 data
>> block each (in a single directory). This would create a directory about
>> 8MB in size, 32MB of dirty inode tables, and about 400M of dirty buffers.
>> I have 128MB RAM, no swap for the testing.
>>
>> In short order, my single user shell was OOM killed, and in another test
>> bonnie was OOM-killed (even though the process itself is only 8MB in size).
>> There were 80k entries each of icache and dcache (38MB and 10MB respectively)
>> and only dirty buffers otherwise. Clearly we need some VM pressure on the
>> icache and dcache in this case. Probably also need more agressive flushing
>> of dirty buffers before invoking OOM.
>
> We _have_ VM pressure there. However, such loads had never been used, so
> there's no wonder that system gets unbalanced under them.
>
> I suspect that simple replacement of goto next; with continue; in the
> fs/dcache.c::prune_dcache() may make situation seriously better.
>
> Al
>
> -
> 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/
>
-
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/
Re: [PATCH] Re: memory usage - dentry_cacheg
On Thursday 12 April 2001 11:12, Alexander Viro wrote: > On Thu, 12 Apr 2001, Rik van Riel wrote: > > On Thu, 12 Apr 2001, Ed Tomlinson wrote: > > > I have been playing around with patches that fix this problem. What > > > seems to happen is that the VM code is pretty efficent at avoiding the > > > calls to shrink the caches. When they do get called its a case of to > > > little to late. This is espically bad in lightly loaded systems. > > > The following patch helps here. I also have a more complex version > > > that uses autotuning, but would rather push the simple code, _if_ it > > > does the job. > > > > I like this patch. The thing I like most is that it tries to free > > from this cache if there is little activity, not when we are low > > on memory and it is physically impossible to get rid of the cache. > > > > Remember that evicting early from the inode and dentry cache doesn't > > matter since we can easily rebuild this data from the buffer and page > > cache. > > Ahem. Yes, for local block-based filesystems, provided that directories are > small and that indirect blocks will not flush the inode table buffers out > of buffer cache, etc., etc. > > Keeping inodes clean when pressure is low is a nice idea. That way you can > easily evict when needed. Evicting early... Not really. What prompted my patch was observing situations where the icache (and dcache too) got so big that they were applying artifical pressure to the page and buffer caches. I say artifical since checking the stats these caches showed over 95% of the entries unused. At this point there is usually another 10% or so of objects allocated by the slab caches but not accounted for in the stats (not a problem they are accounted if the cache starts using them). Suspect your change to the prune logic is not going to help the above situation much - if the shrink functions are not called often enough we end up with over size caches. Comments? Ed Tomlinson <[EMAIL PROTECTED]> - 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/
Re: [PATCH] Re: memory usage - dentry_cacheg
On Thursday 12 April 2001 22:03, Alexander Viro wrote: > On Thu, 12 Apr 2001, Ed Tomlinson wrote: > > On Thursday 12 April 2001 11:12, Alexander Viro wrote: > > What prompted my patch was observing situations where the icache (and > > dcache too) got so big that they were applying artifical pressure to the > > page and buffer caches. I say artifical since checking the stats these > > caches showed over 95% of the entries unused. At this point there is > > usually another 10% or so of objects allocated by the slab caches but not > > accounted for in the stats (not a problem they are accounted if the cache > > starts using them). > > "Unused" as in "->d_count==0"? That _is_ OK. Basically, you will have > positive ->d_count only on directories and currently opened files. > E.g. during compile in /usr/include/* you will have 3-5 file dentries > with ->d_count > 0 - ones that are opened _now_. It doesn't mean that > everything else rest is unused in any meaningful sense. Can be freed - yes, > but that's a different story. > > If you are talking about "unused" from the slab POV - _ouch_. Looks like > extremely bad fragmentation ;-/ It's surprising, and if that's thte case > I'd like to see more details. >From the POV of dentry_stat.nr_unused. From the slab POV, dentry_stat.nr_dentry always equals the number of objects used as reported in /proc/slabinfo. If I could remember my stats from ages back I could take a stab at estimating the fragmentation... From experience if you look at memory_pressure before and after a shrink of the dcache you will usually see it decrease if there if there is more that 75% or so free reported by dentry_stat.nr_unused. The inode cache is not as good. With fewer inodes per page (slab) I would expect that percentage to be lower. Instead it usually has to be above 80% to get pages free... I am trying your change now. Ed Tomlinson - 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/
[BUG] 8139too 'too much work at interrupt'
Hi, Upgraded to ac5 tonight. It stalled shortly after start a program to suck news. Looking at a serial console I see hundreds of the above message with a status of intrStatus = 0x0001 Sysrq was active on the serial console so I did a T and P before syncing are rebooting... If the translated traces are of any use just ask. Ed Tomlinson <[EMAIL PROTECTED]> - 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/
[BUG] ide-tape is readonly here
Hi, Upgraded to ac5 tonight. Problems with 8139too.o caused a few crashes and scrambled a few files. Restoring them was fun. Seems that while ide-tape can write to my 'HP Colorado 20G' drive, it gets an I/O error when it trys to read... If I flip to ide-scsi and friends (much slower for backups btw) the restore works. What is needed to debug this? Ed Tomlinson <[EMAIL PROTECTED]> - 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/
more via wierdness
Hi, Strange thing that shows up here. Using a MB with a MVP3 chipset I have hda - 13G udma2 hdb - nothing physical but the driver does not always agree hdc - cdrom udma2 sometimes... hdd - HP Colorada 20GB tape dma - sometimes... I say sometimes for the devices ide1 since what /proc/ide/via and hdparm (used only for info) report changes boot to boot. Why is this happening? I am using ac5 but have observed this for a while. Note that everything seem to work fine in both cases (PIO or DMA)... What else would help debuging this? Ed Tomlinson <[EMAIL PROTECTED]> 00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset- FastB2B- 00: 06 11 98 85 07 00 20 22 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 90 90 00 00 20: 00 e4 f0 e7 00 e8 f0 e9 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 00 40: 60 ec 60 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 47) Subsystem: VIA Technologies, Inc. MVP3 ISA Bridge Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [f0] AGP version 2.0 Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2 Command: RQ=7 SBA+ AGP+ 64bit- FW- Rate=x1 00: 2b 10 25 05 07 00 90 02 04 00 00 03 08 40 00 00 10: 08 00 00 e8 00 00 00 e4 00 00 00 e5 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 2b 10 79 21 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 10 20 40: 20 c1 53 50 00 3c 00 00 06 ff ff 07 00 00 00 00 50: 00 30 00 01 19 84 9b 01 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 f0 22 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 02 00 20 00 03 02 00 1f 01 03 00 07 00 00 00 00 --VIA BusMastering IDE Configuration Driver Version: 3.23 South Bridge: VIA vt82c586b Revision: ISA 0x47 IDE 0x6 Highest DMA rate: UDMA33 BM-DMA base:0xa000 PCI clock: 33MHz Master Read Cycle IRDY:1ws Master Write Cycle IRDY:1ws BM IDE Status Register Read Retry: yes Max DRDY Pulse Width: No limit ---Primary IDE---Secondary IDE-- Read DMA FIFO flush: yes yes End Sector FIFO flush: no no Prefetch Buffer: yes yes Post Write Buffer:yes no Enabled: yes yes Simplex only: no no Cable Type: 40w 40w ---drive0drive1drive2drive3- Transfer Mode: UDMA DMA UDMA DMA Address Setup: 30ns 120ns 30ns 30ns Cmd Active: 90ns 90ns 90ns 90ns Cmd Recovery:30ns 30ns 30ns 30ns Data Active: 90ns 330ns 90ns 90ns Data Recovery: 30ns 270ns 30ns 30ns Cycle Time: 60ns 600ns 60ns 120ns Transfer Rate: 33.0MB/s 3.3MB/s 33.0MB/s 16.5MB/s # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y #
Re: [PATCH] Re: memory usage - dentry_cacheg
On Friday 13 April 2001 00:45, Ed Tomlinson wrote: > On Thursday 12 April 2001 22:03, Alexander Viro wrote: > > If you are talking about "unused" from the slab POV - _ouch_. Looks like > > extremely bad fragmentation ;-/ It's surprising, and if that's thte case > > I'd like to see more details. > From the POV of dentry_stat.nr_unused. From the slab POV, > dentry_stat.nr_dentry always equals the number of objects used as reported > in /proc/slabinfo. If I could remember my stats from ages back I could > take a stab at estimating the fragmentation... From experience if you look > at memory_pressure before and after a shrink of the dcache you will usually > see it decrease if there if there is more that 75% or so free reported by > dentry_stat.nr_unused. > > The inode cache is not as good. With fewer inodes per page (slab) I > would expect that percentage to be lower. Instead it usually has to be > above 80% to get pages free... > > I am trying your change now. And it does seem to help here. Worst case during an afio backup was: inode_cache14187 16952480 2119 21191 dentry_cache1832 3840128 128 1281 4 1 0 45256 1600 36828 165156 4 8 57679 163 612 39 6 55 without the patch 2+ inode slabs was not uncommon. Here are some numbers snapshoting every 120 seconds at the start of a backup. oscar% while true;do cat /proc/slabinfo | egrep "dentry|inode"; vmstat | tail -1; sleep 120; done inode_cache11083 11592480 1449 14491 dentry_cache4477 4500128 150 1501 0 0 0136 7116 17048 198072 0 03664 129 443 20 3 77 inode_cache11493 11816480 1477 14771 dentry_cache2611 3690128 123 1231 4 0 0 8784 1596 66728 152484 0 14465 131 448 20 3 77 inode_cache 4512 6168480 771 7711 dentry_cache2708 4320128 144 1441 3 0 0 24168 2936 170108 50196 0 36266 135 457 20 4 76 inode_cache 1651 4184480 523 5231 dentry_cache 778 3330128 111 1111 2 0 0156 18560 130504 74848 4 57768 138 462 21 4 75 inode_cache11426 11432480 1429 14291 dentry_cache 672 3240128 108 1081 2 0 0 44928 1740 58292 151932 4 11 10177 140 467 21 4 74 inode_cache10572 11480480 1435 14351 dentry_cache1099 3240128 108 1081 3 0 0 45668 1852 21412 189600 4 11 12679 142 474 22 4 74 inode_cache10620 11416480 1427 14271 dentry_cache1611 3240128 108 1081 3 0 0 45648 2068 13020 202140 4 11 15278 143 482 23 4 73 inode_cache10637 11416480 1427 14271 dentry_cache1628 3240128 108 1081 3 0 0 45648 1588 12412 200832 4 11 17177 143 489 24 4 72 inode_cache10652 11416480 1427 14271 dentry_cache1643 3240128 108 1081 2 0 0 45648 1808 12556 191080 4 11 19076 143 497 25 5 71 inode_cache10698 11416480 1427 14271 dentry_cache1697 3240128 108 1081 2 0 0 45648 1736 12788 191300 4 10 20875 143 504 26 5 70 inode_cache10729 11416480 1427 14271 dentry_cache1728 3240128 108 1081 Looks like there is some fragmentation ocuring. It stays at near a 1:2 ratio for most of the backup (using afio) and ends up with the slab cache having 10-20% more entries than the dcache is using. Thanks Ed Tomlinson <[EMAIL PROTECTED]> - 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/
Re: [BUG] 8139too 'too much work at interrupt'
Forgot to mention that reverting to the driver too the version in ac3 cures the problem I am seeing. Ed On Friday 13 April 2001 00:50, Ed Tomlinson wrote: > Upgraded to ac5 tonight. It stalled shortly after start a > program to suck news. Looking at a serial console I see > hundreds of the above message with a status of > intrStatus = 0x0001 > > Sysrq was active on the serial console so I did a T and P > before syncing are rebooting... If the translated traces > are of any use just ask. > > Ed Tomlinson <[EMAIL PROTECTED]> - 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/
[BUG] tmpfs and loop
Hi,
loop and temp fs do not get along well (2.4.3-ac5)
oscar% dd if=/dev/zero of=/tmp/disk bs=4096 count=1000
1000+0 records in
1000+0 records out
oscar% sudo mke2fs /tmp/disk
mke2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
...
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
oscar% sudo mount /tmp/disk /snap -oloop -text2
ioctl: LOOP_SET_FD: Invalid argument
oscar% sudo mount /tmp/test /snap -oloop -text2
/tmp/test: No such file or directory
oscar% ls -l /tmp/test
ls: /tmp/test: No such file or directory
oscar% sudo mount /tmp/disk /snap -oloop -text2
ioctl: LOOP_SET_FD: Invalid argument
oscar% sudo strace mount /tmp/disk /snap -oloop -text2
execve("/bin/mount", ["mount", "/tmp/disk", "/snap", "-oloop", "-text2"], [/* 34 vars
*/]) = 0
uname({sys="Linux", node="oscar", ...}) = 0
brk(0) = 0x805ac40
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=66123, ...}) = 0
old_mmap(NULL, 66123, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0008\322"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1108076, ...}) = 0
old_mmap(NULL, 1123780, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40028000
mprotect(0x40131000, 38340, PROT_NONE) = 0
old_mmap(0x40131000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x108000)
= 0x40131000
old_mmap(0x40137000, 13764, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x40137000
close(3)= 0
munmap(0x40017000, 66123) = 0
getpid()= 24752
brk(0) = 0x805ac40
brk(0x805ac68) = 0x805ac68
brk(0x805b000) = 0x805b000
open("/dev/null", O_RDWR|O_LARGEFILE) = 3
close(3)= 0
brk(0x805c000) = 0x805c000
getuid32() = 0
geteuid32() = 0
lstat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=262, ...}) = 0
stat64("/dev/loop0", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) = 0
open("/dev/loop0", O_RDONLY|O_LARGEFILE) = 3
ioctl(3, 0x4c03, 0xb7fc)= -1 ENXIO (No such device or address)
close(3)= 0
open("/tmp/disk", O_RDWR|O_LARGEFILE) = 3
open("/dev/loop0", O_RDWR|O_LARGEFILE) = 4
mlockall(MCL_CURRENT|MCL_FUTURE)= 0
ioctl(4, 0x4c00, 0x3) = -1 EINVAL (Invalid argument)
write(2, "ioctl: LOOP_SET_FD: Invalid argu"..., 37ioctl: LOOP_SET_FD: Invalid argument
) = 37
_exit(32) = ?
oscar%
Filesystem 1k-blocks Used Available Use% Mounted on
tmpfs 768000 2556765444 1% /tmp
Bug?
Ed Tomlinson <[EMAIL PROTECTED]>
-
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/
[BUG] lvm beta7 and ac11 problems
Hi, building a kernel with 2.4.3-ac11 and lvm beta7 + vfs_locking_patch-2.4.2 yields: oscar# depmod -ae 2.4.3-ac11 depmod: *** Unresolved symbols in /lib/modules/2.4.3-ac11/kernel/drivers/md/lvm-mod.o depmod: get_hardblocksize ideas? Ed Tomlinson - 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/
Re: hundreds of mount --bind mountpoints?
Andreas Dilger wrote: > Consider, when I was doing some fs benchmark, my inode slab cache was > over 120k items on a 128MB machine. At 480 butes per inode, this is > almost 58 MB, close to half of RAM. Reducing this to exactly ext2 > sized inodes would save (50 - 27) * 4 * 120k = 11MB of memory (on 32-bit > systems)!!! (This assumes nfs_inode_info is the largest). Was this with a recient kernel (post Alexander Viro's dcache pressure fix)? If not I suggest rerunning the benchmark. I had/have a patch to apply pressure to the dcache and icache from kswapd but its not been needed here since the above fix. Ed Tomlinson <[EMAIL PROTECTED]> - 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/
Re: [rfc] Near-constant time directory index for Ext2
Alan Cox wrote: >> probably a bad idea to use it, because in theory at least the VFS layer >> might decide to switch the hash function around. I'm more interested in >> hearing whether it's a good hash, and maybe we could improve the VFS hash >> enough that there's no reason to use anything else.. > > Reiserfs seems to have done a lot of work on this and be using tea, which is > also nice as tea is non trivial to abuse as a user to create pessimal file > searches intentionally The default in reiserfs is now the R5 hash, but you are right that lots of efforts went into finding this hash. This includes testing various hashes on real directory structures to see which one worked best. R5 won. Ed Tomlinson - 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/
Re: [rfc] Near-constant time directory index for Ext2
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> >The default in reiserfs is now the R5 hash, but you are right that lots of
> > efforts went into finding this hash. This includes testing various
> > hashes on real directory structures to see which one worked best. R5
> > won.
>
> That's interesting. The R5 hash is easily also the only one of the
> reiser hashes that might be useable for the generic VFS hashing. It's
> not so different in spirit from the current one, and if you've done the
> work to test it, it's bound to be a lot better.
It was not me personally. I just remembered the thread (from june 2000) on
the reiserfs list... I have summerized the results for you below.
For the program see: http://www.jedi.claranet.fr/hash_torture.tar.gz
Ed
PS. I am still seeing hangs with (2.4.2pre2 then I switched to ac7 or so and
have had hangs with all pre and ac(s) tried and that is most of them) ac20
plus the latest reiserfs fixes has stayed up 8 hours so far - it can take two
or three days to trigger the hang though. When it hangs it really dead, a
UPS connected via a serial port cannot shut it down. pings to the box fail.
A+SysRQ is dead, and the software watchdog does not trigger a reboot.
ideas?
> (The current VFS name hash is probably _really_ stupid - I think it's
> still my original one, and nobody probably ever even tried to run it
> through any testing. For example, I bet that using a shift factor of 4
> is really bad, because it evenly divides a byte, which together with the
> xor means that you can really easily generate trivial bad cases).
>
> What did you use for a test-case? Real-life directory contents? Did you
> do any worst-case analysis too?
>
> Linus
some test results from june 2000 with Hans's summary first.
---
(reiserfs) Re: r5 hash
From: Hans Reiser <[EMAIL PROTECTED]>
To: "Yury Yu. Rupasov" <[EMAIL PROTECTED]>
Cc: Jedi/Sector One <[EMAIL PROTECTED]>, Petru Paler <[EMAIL PROTECTED]>,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, Yury Shevchuk
<[EMAIL PROTECTED]>
Ok, based on this benchmark let's put rupasov5 in, and warn users who choose
the
currently used rupasov1 hash that rupasov5 has obsoleted it. Do this in both
3.6 and 3.5, and fix the the delimiting key check in 3.5 REISERFS_CHECK bug at
the same time. Cut the patch, start testing, and see if you can release by
Monday. Make rupasov5 the default. sizif, review the documentation he
creates
for users.
Jedi, if you disagree with the benchmarks let me know. You might try
concatenating two filenames together instead of adding a digit to them, or
running find on a really large FS, to improve these tests. Thanks for helping
us with analyzing the different hash methods available Jedi.
Hans
---
(reiserfs) Re: r5 hash
From: "Yury Yu. Rupasov" <[EMAIL PROTECTED]>
To: Hans Reiser <[EMAIL PROTECTED]>
Cc: Jedi/Sector One <[EMAIL PROTECTED]>, Petru Paler <[EMAIL PROTECTED]>,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, Yury Shevchuk
<[EMAIL PROTECTED]>
Hans Reiser wrote:
>
> What is the speed of the real filenames, not just the number of collisions.
>
Ok, here is the results for real names :
# find / -type d -exec ls {} \; | sort | uniq > allfiles.txt
# wc -l allfiles.txt
161101 allfiles.txt
Collisions for 161 101 names:
tea_hash : 784 total, 2 dangerous
jedi_hash2: 957 total, 2 dangerous
r5_hash :1191 total, 2 dangerous
r7_hash :8439 total, 18 dangerous
The speed for 161 101 real names :
create 161101 files of 10 bytes with names from allfiles.txt
# time create d1 allfiles.txt
# time cp d1 d2 -r
# time rm d1 -r
create copy remove
tea_hash : 1m27.223s 5m43.069s 2m33.449s
jedi_hash2 : 1m26.062s 5m40.872s 2m32.795s
r5_hash : 1m16.729s 4m14.967s 1m53.037s
r7_hash : 1m10.665s 3m34.950s 1m39.756s
As you can see the results are differ, but not too much. :)
The situation changes dramatically if we will test 1 million files.
The same test, but at the end of each name from allfiles.txt
added numbers from 0 to 6 (1 127 707 files):
create copy remove
tea_hash : 81m44.449s
jedi_hash2 : 79m46.419s
r5_hash : 15m56.037s
r7_hash : 15m30.680s
Dual Celeron 500, 128 MB RAM, 8 GB scsi HDD
Reiserfs-3.5.21, Linux-2.2.15
Thanks,
Yura.
---
body { font-family: "helvetica" } p { font-size: 12pt } a { color: #ff;
text-decoration: none; }(
[BUG] 2.4.x system Freezes
Hi, A couple of weeks age I reported a couple of problems. The first two turned out not to be serious but the third, where the system freezes, has not stopped happening. Several other people have reported similar problems... Typically my system will die while kde2.1 is starting (about 1 time in 4) or shortly after I start a caching news server (newsplex), another common trigger is dpkg, when reading its database just before it starts up unpack packages. If it gets thru these hurdles it may last up to three days - most of the time I am luckly to get one... Once it hangs its really hung. A ups cannot trigger a shutdown, sysrq is dead, the num lock indicator will not toggle. Trying to use shift, alt or control + shiftlock does not result in any data on a serial console, nor are there any unexpected messages there. Also pinging from the box running the serial console gets no answers during a stall. The software watchdog does not get triggered either. I would love NOT to have to be such close friends with the reset button. (reiserfs has been very usefully with all the crashes...) I have install kdb on the off chance that I can hit PAUSE fast enought to it to do a bt command one time it freezes. What else can be done to debug this? Could this be related to the memory problems reported reciently? TIA Ed Tomlinson <[EMAIL PROTECTED]> Current kernel is 2.4.2-ac7 + kdb 1.8 K6-III 400 via mp3 128M mga400max AGP (x1) with xfree 4.02 driver SB16 ISA, nonpnp using alsa 5.10b drivers USR ISA modem, nonpnp Tuplip based card connected to an small internal 100BaseT network VIA Rhine based cards connected to a 10BaseT xDSL modem no scsi hda=13G hdb=4.3G (both quantum, UDMA2) hdc=CDROM hdd=tape (both ATAPI PIO) usb optical MS mouse My root filesystem is on reiserfs and reiserfsck tells me its fine when booted from a recovery partition. On Feb 6 Ed Tomlinson wrote: >System hangs. This box has been quite stable. The hangs started >appearing around 2.4.1 or so. I very much doubt they are heat releated. I >have had heat problems in the past an have moved the kit into a much better >case. The old symptoms (ide tape problems) have gone and not returned even >on the hotest summer day... Next time this happens I will try to telnet or >ssh into box to see if anything is active, I will also setup a UPS on the >box and see it that can shut it down. Its interesting that the software >watchdog does not get triggered. - 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/
Re: [BUG] 2.4.x system Freezes
On Friday 02 March 2001 19:20, you wrote: > > Should an X crash really freeze my box like a block of ice? Would be > > nice if linux could just detect an X crash an recover... Is this too > > much to ask from PC harware? > > X pokes hardware, so X is kind of a device driver in part. One slip and > splat.. Yes - gather this can make life in the fast lane easier... if its all done perfectly. Just wanted to confirm that the freezes _do_ happen with X3.3.6 too. I was able to get into kdb from a serial console (an then lost the log - murphy can be a real PITA). I figure a ps, bt and bta should be enough to point out the problem task? Its there anything else I should do (sr t maybe?)? This was with 2.4.2+ac10+kdb1.8 and x3.3.6 it froze when I returned to the keyboard after a pause of three hours. TIA, Ed - 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/
Re: [reiserfs-list] reiserfs patch for 2.4.0-prerelease
Hi, I have been doing some dbench runs with the original and latest (Jan 4 22:xx) prerelease.diff kernels. Looks like both the latest kernels and the reiserfs patch both are costing some performance. prerelease MB/susersystem cpu time ext214.650.5s76.4s 29% 7:14.9m ext212.650.9s76.7s 25% 8:23.6m reiser 14.553.8s 149.2s 46% 7:16.1m reiser 10.754.1s 154.5s 35% 9:49.9m prerelease (2.4.0 jan 4 22:xx) MB/susersystem cpu time ext210.552.8s81.5s 22% 10:02.3m reiser 5.854.6s 198.5s 23% 18:12.5m reiser 6.455.1s 188.7s 24% 16.19.3m Using the notail reiserfs mount option improves the reiserfs numbers 10-20% with both kernels. All benchmarks run on a K6-III 400 with 128M just after boot with no X running. Comments? Ed Tomlinson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] reiserfs patch for 2.4.0-prerelease (dbench runs)
Hi, I ran a few more benchmarks on 2.4.0 final with 3.6.24. The results were a little susprising (all on the same box, just after boot, no X): MB/susersystem cpu time 3.6.24 7.154.0177,6 25% 14:57.5 3.6.24 14.553.2152.4 47% 7:15.7 3.6.24 5.655.6191.0 22% 18:36.4 reiserfs can do well, but notice how the system cpu seconds varies... I am not seeing such wild differences in ext2 runs, impling that they are due to something in reiserfs? Ed Tomlinson On Thursday 04 January 2001 20:41, Ed Tomlinson wrote: > Hi, > > I have been doing some dbench runs with the original and latest (Jan 4 > 22:xx) prerelease.diff kernels. Looks like both the latest kernels and the > reiserfs patch both are costing some performance. > > prerelease > MB/susersystem cpu time > ext2 14.650.5s76.4s 29% 7:14.9m > ext2 12.650.9s76.7s 25% 8:23.6m > > reiser14.553.8s 149.2s 46% 7:16.1m > reiser10.754.1s 154.5s 35% 9:49.9m > > prerelease (2.4.0 jan 4 22:xx) > MB/susersystem cpu time > ext2 10.552.8s81.5s 22% 10:02.3m > > reiser 5.854.6s 198.5s 23% 18:12.5m > reiser 6.455.1s 188.7s 24% 16.19.3m > > Using the notail reiserfs mount option improves the reiserfs numbers 10-20% > with both kernels. > > All benchmarks run on a K6-III 400 with 128M just after boot with no X > running. > > Comments? > Ed Tomlinson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Don't mix reiserfs and RAID5 in linux-2.4.1-pre8, severe corruption
Hi, This is not just a reiserfs/raid problem. Corruption has been reported on the kernel mailing list with software raid 5 and ext2... Ed On Friday 19 January 2001 16:27, Edward wrote: > Reiserfs in linux-2.4.1-pre8 does not properly with the RAID5 code that > is in that kernel. It is easy to get corrupted filesystem on device in > less than 1 minute. Please, do not use it (reiserfs) on RAID5 devices. > We are trying to figure out what is wrong. > > Edward - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2.18pre21: DRM update
Alan Cox wrote: > I'll look over it. It may be worth doing the fixing for 2.2.18, since > 2.2.17 doesnt have DRM anyway. As posted it doesnt build against vanilla > 2.2.18pre but I can see why so not a problem This patch enables a G400 to use DRI using debian woody. Without this its 2.4 time. (BTW 2.4.0test11-ac3 BUG()ed out at sched.c:513 when playing the the matrox fb stuff). Ed Tomlinson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: More on 2.2.18pre2aa2 (summary of elevator ideas)
Hi, Geez, A simple comment on IRC can _really_ generate lots of feedback. (There were over 50 messages about this in my queue - did not help that some were duplicated three times ). I made the comment because I remember back when the discussion was current on linux kernel. I thought Jeff Merkey's, message was to the point. Para- phrasing from memory, it was something to the effect that novell had tried many elevators. All had problems with some loads. The best they had found was the 'close the door' idea. I do not remember if the door was based on requests or time. Another point to remember is that the netware people came up with a what they considered a good solution. From Jeff's comment they arrived at this solution by experiments and bitter experience. Maybe we can learn something from their research? Here is what I glean from the thread: >From all the discussion I find this suggestion from Alan to make lots of sense. Think it can be made to work with number of request almost as easily as with time... >When you do the scan to decide where to insert the entry you dont consider >insertion before the time. Also you keep two queue heads the real and the >insert head. Whenever you walk from the insert head and find it points to >a 'too old' entry you update the insert_head. And this suggestion from Rik should counter most of Andrea's time vs requests vs slow block devices issues. We just have to be sure to close the door after atleast n request or m time. However, as pointed out by Chris Evan, later we may not have to do this - there are stats that can give a good idea of a device's latency. >Not really. What about just using something like >"half a second, but at least 10 requests liberty to >reorder" ? >It's simple, should be good enough for the user and >allows for a little bit of reordering even on very >slow devices ... As Andrea points out its easy enought to do some sort of test with the current code. >Well changing that is very easy, you only have to change the unit of >measure w/o changing one bit in the algorithm that is just implemented >indeed. >How >Just assume the req->elevator_sequence to be calculate in jiffy and in >elevator.c change the check for `!req->elevator_sequence' to >`time_before(req->elevator_sequence, jiffies)'. Then of course change the >initialization of req->elevator_sequence to be done with `jiffies + >elevator->read_latency'. Then also elvtune will talk in jiffies and not in >requests. I wonder if using a wandering insert pointer, as Alan suggests, would give lower overhead than the current implementation (and would it really help)? Again from Alan, Andrea> Now, I see people trying to introduce the concept of elapsed time Andrea> that fix, which smells strongly of hack. How will this hack be cobbled > > Actually my brain says that elapsed time based scheduling is the right > thing to do. It certainly works for networks And from Chris Evans, >Interesting, I'll try and run with this. The mention of networks reminds >me that any "max service time" variable is a tunable quantity depending on >current conditions.. >.. and sct's block device I/O accounting patches give us the current >average request service time on a per-device basis. Multiply that up a bit >and maybe you have your threshold for moving things to the head of the >queue. So we could end up using a figure that builds in both number of request and time on a per device level without to much effort... And Alan sums up the whole thing nicly with: Andrea> Why do you say it's not been fixed? Can you still reproduce hangs long Andrea> a write(2) can write? I certainly can't. >I cant reproduce long hangs. Im not seeing as good I/O throughput as before >but right now Im quite happy with the tradeoff. If someone can make it better >then Im happier still If the idea works, lead to simpler code, a more reponsive system maybe with better benchmarks then its a winner. Only way we can be sure is to try it. Thanks, Ed Tomlinson <[EMAIL PROTECTED]> (ontadata on IRC) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
Horst von Brand wrote: > OK, OK, OK. It is by now abundantly clear that NFSv3 is a high-priority > item for lots of people out there. But just complaining about it not being > in the kernel just generates ill will. Think Alan has made that clear. The way I read things the nfsv2 stuff needs to be split out, into sets of small independent patches. This lets Alan audit and control any bad patches easily. The nfsv3 changes should not effect anything unless they are selected in the kernel build. Comments? Ed Tomlinson <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[lkml]Re: VM problems still in 2.2.18
Alan Cox wrote: > > slrnpull --expire on a news-spool of about 600 Mb in 200,000 files gave > > a lot of 'trying_to_free..' errors. > > > > 2.2.18 + VM-global, booted with mem=32M: > > > > slrnpull --expire on the same spool worked fine. > > I think Andrea just earned his official God status ;) I have been using the aa series kernels through out the 18pre series (with reiserfs). They have worked very well. Suggest you and Andrea talk and figure out what else from this series can be put into 19pre. Believe the major changes left in the aa series are bigmem and lvm. I would love to see lvm officially in 2.2... Luck, Ed Tomlinson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: File I/O benchmarks for various kernel
Hi, Some more numbers to consider: 7.3 MB/s 54.7s user 159.6s system 25% cpu elaspsed 14:21.9m reiserfs on hda whick gets 16.1 MB/s from hdparm -t 9.7 MB/s 51.6s user 78.3s system 19% cpu elaspsed 10:50.8m ext2 on hdb which gets 10.6 MB/s from hdparm -t both drives are udma33. The sytem is a K6-III 400 with 128m running: 2.4.0test13pre6 + reil #2 + drm fix + reiserfs 3.6.23 Think ext2 is doing pretty good. I have seen comments that imply dbench does not show reiserfs at its best - they favor the bonnie suite. Luck Ed Tomlinson Daniel Phillips wrote: > I've been using dbench a lot lately for reality checks on various kernel > mods, and out of interest I decided to run benchmarks with it on a few > different kernel versions. I noticed a major difference between 2.2 and > 2.4 kernels - 2.4 is running the benchmarks about 3 times faster than > 2.2, and it seems to be getting faster with each step towards 2.4.0. On > the other hand, 2.2 seems to be getting slower. Here are a few points > on the curve. > > Test machine: 64 meg, 500 Mhz K6, IDE, Ext2, Blocksize=4K > Test: dbench 48 > > Kernel Throughput Elapsed Time > -- -- > 2.2.16 3.1 MB/sec 33 min 53 secs > 2.2.18 2.8 MB/sec 38 min 10 secs > 2.2.19-pre32.7 MB/sec 39 min 44 secs > 2.4.0-test12 7.3 MB/sec 14 min 32 secs > 2.4.0-test13-pre4 9.5 MB/sec 11 min 06 secs > 2.4.0-test13-pre5 10.8 MB/sec 9 min 48 secs > > Dbench was written by Andrew Tridgell to measure disk performance under > simulated samba network traffic load. The '48' means it's simulating > the file access patterns of 48 network clients, all doing heavy io at > the same time. > > For anyone interested in checking these results on their own hardware, > dbench is available at: > > ftp://samba.org/pub/tridge/dbench/dbench-1.1.tar.gz > > -- > Daniel > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: modutils 2.3.23 fails with tdfx.o with test13-pre6
Hi, This is lets it load. The same missing symbols happen with mga as well... This is from a patch posted here two weeks ago: --- linux/drivers/char/drm/drmP.oldThu Dec 28 16:27:34 2000 +++ linux/drivers/char/drm/drmP.hSat Dec 23 13:57:08 2000 @@ -40,6 +40,7 @@ #include #endif /* __alpha__ */ #include +#include #include #include #include Not sure if this is more than a temporay fix though. Ed Tomlinson Frank Jacobberger wrote: > I can't get the latest modutils to work with loading > tdfx.o... Even went to the directory where tdfx.o resides > and did a insmod -S tdfx.o and got the following : > > BTW - test13-pre6 here > > tdfx.o: unresolved symbol remap_page_range > tdfx.o: unresolved symbol __wake_up > tdfx.o: unresolved symbol mtrr_add > tdfx.o: unresolved symbol __generic_copy_from_user > tdfx.o: unresolved symbol schedule > tdfx.o: unresolved symbol kmalloc > tdfx.o: unresolved symbol si_meminfo > tdfx.o: unresolved symbol create_proc_entry > tdfx.o: unresolved symbol inter_module_put > tdfx.o: unresolved symbol __get_free_pages > tdfx.o: unresolved symbol boot_cpu_data > tdfx.o: unresolved symbol inter_module_get > tdfx.o: unresolved symbol remove_wait_queue > tdfx.o: unresolved symbol high_memory > tdfx.o: unresolved symbol iounmap > tdfx.o: unresolved symbol free_pages > tdfx.o: unresolved symbol __ioremap > tdfx.o: unresolved symbol del_timer > tdfx.o: unresolved symbol interruptible_sleep_on > tdfx.o: unresolved symbol __pollwait > tdfx.o: unresolved symbol kfree > tdfx.o: unresolved symbol remove_proc_entry > tdfx.o: unresolved symbol pci_find_slot > tdfx.o: unresolved symbol kill_fasync > tdfx.o: unresolved symbol fasync_helper > tdfx.o: unresolved symbol add_wait_queue > tdfx.o: unresolved symbol do_mmap_pgoff > tdfx.o: unresolved symbol mem_map > tdfx.o: unresolved symbol sprintf > tdfx.o: unresolved symbol jiffies > tdfx.o: unresolved symbol printk > tdfx.o: unresolved symbol add_timer > tdfx.o: unresolved symbol __generic_copy_to_user > > So what gives here? > > Frank > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre7...
Chris Evans wrote: > On Sat, 30 Dec 2000, Linus Torvalds wrote: > > > On Sat, 30 Dec 2000, Steven Cole wrote: > > > > > > It looks like 2.4.0-test13-pre7 is a clear winner when running dbench > > > 48 on my somewhat slow test machine (450 Mhz P-III, 192MB, IDE). > > > > This is almost certainly purely due to changing (some would say > > "fixing") the bdflush synchronous wait point. > > Nice:) > > Did Rik's drop_behind performance fix make it in or can we look forward to > another jump in the dbench benchmarks? And please do not forget marcello's swap clustering patch. I get a 13% improvement on dbench with reiserfs when patched with it. From conversations on kernelnewbies, Riel likes this one too. Ed Tomlinson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
On Thursday 22 March 2001 17:00, Guest section DW wrote: > On Thu, Mar 22, 2001 at 09:23:54PM +, Alan Cox wrote: > > > Really the whole oom_kill process seems bass-ackwards to me. I can't > > > in my mind logically justify annihilating large-VM processes that have > > > been running for days or weeks instead of just returning ENOMEM to a > > > process that just started up. > > > > How do you return an out of memory error to a C program that is out of > > memory due to a stack growth fault. There is actually not a language > > construct for it > > Alan, this is a fake argument. > Linux is bad, and you defend it by saying that it is impossible to be > perfect. > > I have used various Unix flavours for approximately thirty years. > Stack overflow has not been a real problem. Of course they occurred > every now and then, but roughly speaking only for unchecked recursion, > that is, in cases of a program bug. > > Presently however, a flawless program can be killed. > That is what makes Linux unreliable. > > > Eventually you have to kill something or the machine deadlocks. > > Alan, this is a fake argument. > When I have a computer algebra system, and it computes millions of > function values for some expensive function, then it keeps a cache > of already computed values. Maybe a value is needed again and we > save ten seconds of computation. > But of course, when we run out of memory, nothing is easier than > just throwing this cache out. > > You see, the bug is that malloc does not fail. This means that the > decisions about what to do are not taken by the program that knows > what it is doing, but by the kernel. By this arguement the OOM kill code is fine... If malloc is broken fix it. Maybe we need to stage things so that ENOMEM gets returned to requests before we are totally out of memory. If the apps ignore the errors then the kills happen. Thoughts? Ed Tomlinson - 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/
[Panic] Linux-2.4.2ac22
Hi, Got this with ac22... ksymoops 2.3.7 on i586 2.4.2-ac22. Options used -V (default) -k /var/log/ksymoops/20010323122909.ksyms (specified) -l /var/log/ksymoops/20010323122909.modules (specified) -o /lib/modules/2.4.2-ac22/ (default) -m /boot/System.map-2.4.2-ac22 (default) Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry Unable to handle kernel NULL pointer dereference at virtual address 022e c01b2b53 *pde = Oops: CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: d2636f00 ebx: 022e ecx: edx: 022e esi: d2cba0a0 edi: d2636ca0 ebp: 0060 esp: cdee1df8 ds: 0018 es: 0018 ss: 0018 Process setiathome (pid: 10662, stackpage=cdee1000) Stack: fe00 c01b2bfb d2cba0a0 fe00 d2cba0a0 c01b310a d2cba0a0 d2cba0a0 d3eae800 d22e02a0 d3eae800 c01b589a d2cba0a0 0002 c56a1940 d2cba0a0 c01b8973 d2cba0a0 d2cba0a0 0004 c01c268c c01c2705 d2cba0a0 Call Trace: [] [] [] [] [] [< [] [] [] [] [] [] [] [] [] [] [] Code: 8b 1b 8b 42 70 83 f8 01 74 0a ff 4a 70 0f 94 c0 84 c0 74 09 >>EIP; c01b2b53 <= Trace; c01b2bfb Trace; c01b310a Trace; c01b589a Trace; c01b8973 Trace; c01c268c Trace; c01bff2c Trace; c01c2672 Trace; c01c268c Trace; c01bff7a Trace; c01ba937 Trace; c01bf34f Trace; c01bf200 Trace; c01ba937 Trace; c01bf075 Trace; c01bf200 Trace; c0108e80 Code; c01b2b53 <_EIP>: Code; c01b2b53 <= 0: 8b 1b mov (%ebx),%ebx <= Code; c01b2b55 2: 8b 42 70 mov 0x70(%edx),%eax Code; c01b2b58 5: 83 f8 01 cmp $0x1,%eax Code; c01b2b5b 8: 74 0a je 14 <_EIP+0x14> c01b2b67 Code; c01b2b5d a: ff 4a 70 decl 0x70(%edx) Code; c01b2b60 d: 0f 94 c0 sete %al Code; c01b2b63 10: 84 c0 test %al,%al Code; c01b2b65 12: 74 09 je 1d <_EIP+0x1d> c01b2b70 <0>Kernel panic: Aiee, killing interrupt handler! 1 warning issued. Results may not be reliable. - 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/
Fwd: Re: [PATCH] Prevent OOM from killing init
,--- Forwarded message (begin) Subject: Re: [PATCH] Prevent OOM from killing init From: Jonathan Morton <[EMAIL PROTECTED]> Date: Fri, 23 Mar 2001 20:45:43 -0500 >Hmm... "if ( freemem < (size_of_mallocing_process / 20) ) fail_to_allocate;" Not sure this is that reasonable on a 4G box... 800M is a big chunk... Why not base this on the vm's free goal. If I remember correctly it tries to keep one second of pages ready for allocating. If memory is so tight that a second's worth of memory does not exist. Note that I mean memory free in main memory and swap. Think your malloc patch along with UID weighting (1-99 protected, 100-999 endangered, 1000+ open season - with poaching expected if there is no choise) will make help oom processing. Ed Tomlinson - 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/
[PATCH] vmtime and vm balancing
Hi,
The following patch introduces the idea of vmtime. vmtime is time as the
vm percieves it. Its advanced by memory pressure, which in the end, works
out to be the page allocation & reclaim rate. With this figure I attempt to solve
two problems.
First I slow down the background page scanning to the rate we are allocating
pages. This means that an idle machine will not end up with all page ages
equal nearly as quickly. It should also help prevent cases where kswapd
eats too much cpu. The other effect should be to prevent or reduce some
swap out spikes.
Second, I add some slab cache pressure. Without the patch the icache and
dcache will get shrunk in under extreme cases. From comments on mm
list (and personal experience) the slab cache can grow and end up causing
paging when it would make more sense to just shrink it. This also has
oom implications since the size of the slab cache, and the possible space
we can free from it, are not accounted for in the oom test. In any case
the patch should help keep this storage under control. Are there any other
parts of the slab cache we should think about shrinking?
This has survived the night on my box with printk(s) in the if(s) to verify
its actually working. It should apply to pre8 and ac25/ac26. The vmscan.c
change made by ac26 should not hurt this patch but may make it age
pages a bit more aggressivily.
We need to find out if this helps. Reports on what effect this has would
be very welcome. Rik has looked at the patch and wants to see some
feedback...
Comments on style or bugs very welcome.
---
--- linux/mm/vmscan.c.ac26 Tue Mar 27 10:02:52 2001
+++ linux/mm/vmscan.c Tue Mar 27 10:08:14 2001
@@ -985,22 +985,51 @@
for (;;) {
static int recalc = 0;
+ /* vmtime tracks time as the vm precieves it.
+* It is advanced depending on the ammount of
+* memory pressure.
+*/
+ static int vmtime = 0;
+ static int bgscan_required = 0;
+ static int slab_scan_required = 0;
+
/* If needed, try to free some memory. */
if (inactive_shortage() || free_shortage())
do_try_to_free_pages(GFP_KSWAPD, 0);
/*
* Do some (very minimal) background scanning. This
-* will scan all pages on the active list once
-* every minute. This clears old referenced bits
-* and moves unused pages to the inactive list.
+* tries to scan all pages on the active list at the
+* rate pages are allocated. This clears old referenced
+* bits and moves unused pages to the inactive list.
+*/
+ if (vmtime > bgscan_required ) {
+ refill_inactive_scan(DEF_PRIORITY, 0);
+ bgscan_required = vmtime + (nr_active_pages >> INACTIVE_SHIFT);
+ }
+
+ /*
+* Here we apply some pressure to the slab cache. We
+* apply more pressure as it gets bigger. This would
+* be cleaner if there was a nr_slab_pages...
*/
- refill_inactive_scan(DEF_PRIORITY, 0);
+ if (vmtime > slab_scan_required) {
+ shrink_dcache_memory(DEF_PRIORITY, GFP_KSWAPD);
+ shrink_icache_memory(DEF_PRIORITY, GFP_KSWAPD);
+ kmem_cache_reap(GFP_KSWAPD);
+ slab_scan_required = vmtime + num_physpages - nr_free_pages()
+- atomic_read(&page_cache_size) - atomic_read(&buffermem_pages);
+ }
- /* Once a second, recalculate some VM stats. */
+ /* Once a second, recalculate some VM stats and the vmtime. */
if (time_after(jiffies, recalc + HZ)) {
recalc = jiffies;
- recalculate_vm_stats();
+ recalculate_vm_stats();
+ vmtime += (memory_pressure >> INACTIVE_SHIFT);
+ if (vmtime > INT_MAX - num_physpages) {
+ vmtime = 0;
+ bgscan_required = 0;
+ slab_scan_required = 0;
+ }
}
run_task_queue(&tq_disk);
---
Ed Tomlinson <[EMAIL PROTECTED]>
-
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/
[PATCH][RFC] appling preasure to icache and dcache
Hi,
This patch does two things. One it applies pressure to the icache
and dcache, from kswapd, when they grow or possibly become shrinkable.
The idea being not to let them grow to the point that they start being
the source of vm pressure - this seems to be happening with the current
algorithm.
It also limits bg aging restricting it to the page inactivation rate.
This perserves aging info longer preventing paging spikes after periods
of low activity.
The try_shrinking_[i|d]cache functions would become much simpler if
the slab cache tracked the number of pages freeable in a cache. I do
not think this is a trivial task though. I have also tried to avoid
making the patch depend on 'magic numbers'. As it stands DEF_PRIORITY
is used but could be eliminated if the shrink_[i|d]cache_memory calls
took the number of pages to free and returned the number of pages
actually released. In ac28 refill_inactive_scan is already ignoring
DEF_PRIORITY.
Variants of this patch have been running here, on top of ac28, over the
for the last couple of days as I optimised the try_shrinking functions.
Reports on how well this works under differing loads would be interesting.
Comments on style, and suggestions on how to improve this code are
very welcome.
TIA
Ed Tomlinson <[EMAIL PROTECTED]>
---
diff -u -r --exclude-from=ex.txt linux.ac28/mm/page_alloc.c linux/mm/page_alloc.c
--- linux.ac28/mm/page_alloc.c Sun Apr 1 18:52:22 2001
+++ linux/mm/page_alloc.c Mon Apr 2 07:54:05 2001
@@ -138,11 +138,9 @@
/*
* We don't want to protect this variable from race conditions
-* since it's nothing important, but we do want to make sure
-* it never gets negative.
+* since it's nothing important.
*/
- if (memory_pressure > NR_CPUS)
- memory_pressure--;
+ inactivate_pressure++;
}
#define MARK_USED(index, order, area) \
diff -u -r --exclude-from=ex.txt linux.ac28/mm/swap.c linux/mm/swap.c
--- linux.ac28/mm/swap.cMon Jan 22 16:30:21 2001
+++ linux/mm/swap.c Thu Mar 29 11:37:47 2001
@@ -47,10 +47,12 @@
* many inactive pages we should have.
*
* In reclaim_page and __alloc_pages: memory_pressure++
- * In __free_pages_ok: memory_pressure--
+ * In __free_pages_ok: inactivate_pressure++
+ * In invalidate_pages_scan: inactivate_pressure++
* In recalculate_vm_stats the value is decayed (once a second)
*/
int memory_pressure;
+int inactivate_pressure;
/* We track the number of pages currently being asynchronously swapped
out, so that we don't try to swap TOO many pages out at once */
@@ -287,6 +289,7 @@
* memory_pressure.
*/
memory_pressure -= (memory_pressure >> INACTIVE_SHIFT);
+ inactivate_pressure -= (inactivate_pressure >> INACTIVE_SHIFT);
}
/*
diff -u -r --exclude-from=ex.txt linux.ac28/mm/vmscan.c linux/mm/vmscan.c
--- linux.ac28/mm/vmscan.c Sun Apr 1 18:52:22 2001
+++ linux/mm/vmscan.c Mon Apr 2 07:42:55 2001
@@ -759,6 +791,8 @@
}
spin_unlock(&pagemap_lru_lock);
+ inactivate_pressure += nr_deactivated;
+
return nr_deactivated;
}
@@ -937,6 +971,76 @@
return ret;
}
+/*
+ * Try to shrink the dcache if either its size or free space
+ * has grown, and it looks like we might get the required pages.
+ * This function would simplify if the caches tracked how
+ * many _pages_ were freeable.
+ */
+int try_shrinking_dcache(int goal, unsigned int gfp_mask)
+{
+
+ /* base - projects the threshold above which we can free pages */
+
+ static int base, free = 0;
+ int pages, old, ret;
+
+ old = free; /* save old free space size */
+
+ pages = (dentry_stat.nr_dentry * sizeof(struct dentry)) >> PAGE_SHIFT;
+ free = (dentry_stat.nr_unused * sizeof(struct dentry)) >> PAGE_SHIFT;
+
+ if (base > pages) /* If the cache shrunk reset base, The cache
+ base = pages;* growing applies preasure as does expanding
+ if (free > old) * free space - even if later shrinks */
+ base -= (base>free-old) ? free-old : base;
+
+ /* try free pages... Note that the using inactive_pressure _is_
+* racy. It does not matter, a bad guess will not hurt us.
+* Testing free here does not work effectivily.
+*/
+
+ if (pages-base >= goal) {
+ ret = inactivate_pressure;
+ shrink_dcache_memory(DEF_PRIORITY, gfp_mask);
+ ret = inactivate_pressure - ret;
+ base += (!ret) ? pages-base : (ret>goal) ? ret : goal;
+ } else
+ ret = 0;
+
+ return ret;
+}
+
+/*
+ * Same logic as above but for the icache.
+ */
+int try_shrinking_icache(int goal, unsigned int gfp_mask)
+{
+ static int base, free = 0;
+ int pages, old, ret;
+
Re: [PATCH][RFC] appling preasure to icache and dcache
Hi,
The patch in the last message was scrambled. The last two lines
belong to the previous fragment. Here is the correct beast.
Ed Tomlinson <[EMAIL PROTECTED]
---
diff -u -r --exclude-from=ex.txt linux.ac28/mm/page_alloc.c linux/mm/page_alloc.c
--- linux.ac28/mm/page_alloc.c Sun Apr 1 18:52:22 2001
+++ linux/mm/page_alloc.c Mon Apr 2 07:54:05 2001
@@ -138,11 +138,9 @@
/*
* We don't want to protect this variable from race conditions
-* since it's nothing important, but we do want to make sure
-* it never gets negative.
+* since it's nothing important.
*/
- if (memory_pressure > NR_CPUS)
- memory_pressure--;
+ inactivate_pressure++;
}
#define MARK_USED(index, order, area) \
diff -u -r --exclude-from=ex.txt linux.ac28/mm/swap.c linux/mm/swap.c
--- linux.ac28/mm/swap.cMon Jan 22 16:30:21 2001
+++ linux/mm/swap.c Thu Mar 29 11:37:47 2001
@@ -47,10 +47,12 @@
* many inactive pages we should have.
*
* In reclaim_page and __alloc_pages: memory_pressure++
- * In __free_pages_ok: memory_pressure--
+ * In __free_pages_ok: inactivate_pressure++
+ * In invalidate_pages_scan: inactivate_pressure++
* In recalculate_vm_stats the value is decayed (once a second)
*/
int memory_pressure;
+int inactivate_pressure;
/* We track the number of pages currently being asynchronously swapped
out, so that we don't try to swap TOO many pages out at once */
@@ -287,6 +289,7 @@
* memory_pressure.
*/
memory_pressure -= (memory_pressure >> INACTIVE_SHIFT);
+ inactivate_pressure -= (inactivate_pressure >> INACTIVE_SHIFT);
}
/*
diff -u -r --exclude-from=ex.txt linux.ac28/mm/vmscan.c linux/mm/vmscan.c
--- linux.ac28/mm/vmscan.c Sun Apr 1 18:52:22 2001
+++ linux/mm/vmscan.c Mon Apr 2 07:42:55 2001
@@ -759,6 +791,8 @@
}
spin_unlock(&pagemap_lru_lock);
+ inactivate_pressure += nr_deactivated;
+
return nr_deactivated;
}
@@ -937,6 +971,76 @@
return ret;
}
+/*
+ * Try to shrink the dcache if either its size or free space
+ * has grown, and it looks like we might get the required pages.
+ * This function would simplify if the caches tracked how
+ * many _pages_ were freeable.
+ */
+int try_shrinking_dcache(int goal, unsigned int gfp_mask)
+{
+
+ /* base - projects the threshold above which we can free pages */
+
+ static int base, free = 0;
+ int pages, old, ret;
+
+ old = free; /* save old free space size */
+
+ pages = (dentry_stat.nr_dentry * sizeof(struct dentry)) >> PAGE_SHIFT;
+ free = (dentry_stat.nr_unused * sizeof(struct dentry)) >> PAGE_SHIFT;
+
+ if (base > pages) /* If the cache shrunk reset base, The cache
+ base = pages;* growing applies preasure as does expanding
+ if (free > old) * free space - even if later shrinks */
+ base -= (base>free-old) ? free-old : base;
+
+ /* try free pages... Note that the using inactive_pressure _is_
+* racy. It does not matter, a bad guess will not hurt us.
+* Testing free here does not work effectivily.
+*/
+
+ if (pages-base >= goal) {
+ ret = inactivate_pressure;
+ shrink_dcache_memory(DEF_PRIORITY, gfp_mask);
+ ret = inactivate_pressure - ret;
+ base += (!ret) ? pages-base : (ret>goal) ? ret : goal;
+ } else
+ ret = 0;
+
+ return ret;
+}
+
+/*
+ * Same logic as above but for the icache.
+ */
+int try_shrinking_icache(int goal, unsigned int gfp_mask)
+{
+ static int base, free = 0;
+ int pages, old, ret;
+
+ old = free;
+
+ pages = (inodes_stat.nr_inodes * sizeof(struct inode)) >> PAGE_SHIFT;
+ free = (inodes_stat.nr_unused * sizeof(struct inode)) >> PAGE_SHIFT;
+
+ if (base > pages)
+ base = pages;
+ if (free > old)
+ base -= (base>free-old) ? free-old : base;
+
+ if (pages-base >= goal) {
+ ret = inactivate_pressure;
+ shrink_icache_memory(DEF_PRIORITY, gfp_mask);
+ ret = inactivate_pressure - ret;
+ base += (!ret) ? pages-base : (ret>goal) ? ret : goal;
+ } else
+ ret = 0;
+
+ return ret;
+}
+
+
DECLARE_WAIT_QUEUE_HEAD(kswapd_wait);
DECLARE_WAIT_QUEUE_HEAD(kswapd_done);
struct task_struct *kswapd_task;
@@ -984,18 +1088,28 @@
*/
for (;;) {
static int recalc = 0;
+ int delta = 0;
/* If needed, try to free some memory. */
if (inactive_shortage() || free_shortage())
do_try_to_free_pages(GFP_KSWAPD, 0);
/*
-* Do so
Re: 2.4.1-test10
On Tue, 23 Jan 2001, Linus Torvalds wrote:
>On Tue, 23 Jan 2001, Marcelo Tosatti wrote:
>> Any technical reason why the background page aging fix was not applied?
>Because I have not heard anybody claim that it makes a huge difference..
Linus,
Marcelo's changes make a difference here - enought of a difference that I
spent the time to merge his 'swap_max_pageout' and 'limit_bg_pte_scaning'
patches.
These patches make my system more stable when there is memory preasure. With
them I see much less 'jerky' behavior when swapping starts. Limiting the
ammout of swapping to what's actually needed seems very effective. Using pte
scaning, when under light memory peasure, looks to be effective at keeping
swapping transparent (and freepages available)... The effect of limiting the
bg aging is harder to see but I do notice that going back to a long,
intermitantly running task, often does not result in a large delay due to
swapins...
In short think you should take a serious look at Marcelo's latest work. I
have included the merged patch. Marcelo has briefly vetted it but more eyes
would be a very good idea...
TIA
Ed Tomlinson
BTW - I sent a comment on this thread this morning - it bounced due to a
knode problem with multiple address. It said the same things.
---
Only in linux-pre9e/mm/: .depend
diff -u linux/mm/swap.c linux-pre9e/mm/swap.c
--- linux/mm/swap.c Tue Nov 28 19:52:56 2000
+++ linux-pre9e/mm/swap.c Thu Jan 18 22:33:42 2001
@@ -200,17 +200,22 @@
{
if (PageInactiveDirty(page)) {
del_page_from_inactive_dirty_list(page);
- add_page_to_active_list(page);
} else if (PageInactiveClean(page)) {
del_page_from_inactive_clean_list(page);
- add_page_to_active_list(page);
} else {
/*
* The page was not on any list, so we take care
* not to do anything.
*/
+ goto inc_age;
}
+ add_page_to_active_list(page);
+
+ if(bg_page_aging < num_physpages)
+ bg_page_aging++;
+
+inc_age:
/* Make sure the page gets a fair chance at staying active. */
if (page->age < PAGE_AGE_START)
page->age = PAGE_AGE_START;
diff -u linux/mm/vmscan.c linux-pre9e/mm/vmscan.c
--- linux/mm/vmscan.c Sun Jan 21 21:44:55 2001
+++ linux-pre9e/mm/vmscan.c Sun Jan 21 11:54:09 2001
@@ -24,32 +24,21 @@
#include
-/*
- * The swap-out functions return 1 if they successfully
- * threw something out, and we got a free page. It returns
- * zero if it couldn't do anything, and any other value
- * indicates it decreased rss, but the page was shared.
- *
- * NOTE! If it sleeps, it *must* return 1 to make sure we
- * don't continue with the swap-out. Otherwise we may be
- * using a process that no longer actually exists (it might
- * have died while we slept).
- */
-static void try_to_swap_out(struct mm_struct * mm, struct vm_area_struct*
vma, unsigned long address, pte_t * page_table, struct page *page)
+int bg_page_aging = 0;
+
+static int try_to_swap_out(struct mm_struct * mm, struct vm_area_struct*
vma, unsigned long address, pte_t * page_table, struct page *page)
{
pte_t pte;
swp_entry_t entry;
/* Don't look at this pte if it's been accessed recently. */
if (ptep_test_and_clear_young(page_table)) {
- page->age += PAGE_AGE_ADV;
- if (page->age > PAGE_AGE_MAX)
- page->age = PAGE_AGE_MAX;
- return;
+ age_page_up(page);
+ return 0;
}
if (TryLockPage(page))
- return;
+ return 0;
/* From this point on, the odds are that we're going to
* nuke this pte, so read and clear the pte. This hook
@@ -73,11 +62,17 @@
set_pte(page_table, swp_entry_to_pte(entry));
drop_pte:
mm->rss--;
- if (!page->age)
+ if (!page->age) {
deactivate_page(page);
+ if(!PageActive(page)) {
+ UnlockPage(page);
+ page_cache_release(page);
+ return 1;
+ }
+ }
UnlockPage(page);
page_cache_release(page);
- return;
+ return 0;
}
/*
@@ -121,25 +116,27 @@
/* Add it to the swap cache and mark it dirty */
add_to_swap_cache(page, entry);
set_page_dirty(page);
+ if (bg_page_aging)
+ bg_page_aging--;
goto set_swap_pte;
out_unlock_restore:
set_pte(page_table, pte);
UnlockPage(page);
- return;
+ return 0;
}
-static int swap_out_pmd(s
VM breakdown, 2.4.0 family
David Ford Wrote: >Since the testN series and up through ac12, I experience total loss of >control when memory is nearly exhausted. > >I start with 256M and eat it up with programs until there is only about >7 megs left, no swap. From that point all user processes stall and the >disk begins to grind nonstop. It will continue to grind for about 25-30 >minutes until it goes completely silent. No processes get killed, no VM >messages are emitted. > >The only recourse is the magic key. If I reboot before the disk goes >silent I can cleanly kill X with sysrq-E and restart. > >If I wait until it goes silent, all is lost. I have to sysrq-SUB. You might want to try: http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.1pre10/bg_page_aging.patch or ftp://ftp.cam.org/users/tomlins/pte_aging_limit_swaps.diff The first patch from Marcelo fixes a problem with aging the wrong pages. The second patch is sort of a 'best of Marcelo' patch. It contains the aging fix and adds conditional bg pte aging (if with activate fast than we age down...). It also has code to trottle swapouts when under preasure - it only swaps out as much as we need now. I have fives days of uptime with it here (on test9 and test10). Feedback Welcome, Ed Tomlinson <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM brokenness, possibly related to reiserfs
Hi, Gather this is with no swap space allocated... And the question is why does the oom handler not get triggered? Ed Tomlinson David Ford wrote: > (Chris, changing JOURNAL_MAX_BATCH from 900 to 100 didn't affect > anything). > > Ok, having approached this slightly more intelligently here are [better] > results. > > The dumps are large so they are located at http://stuph.org/VM/. Here's > the story. I boot and startx, I load xmms and netscape to eat away > memory. When free buffers/cache falls below 7M the system stalls and > the only recovery is sysrq-E or reboot. At the moment of stall the disk > will grind continuously for about 25 to 30 minutes then go silent. At > this point in time the only recovery is reboot, sysrq-E won't work. > > If I move the mouse or type a key within 30 seconds of this incident, > that user input will take about 5 minutes to register. After that > initial minute, nothing more will happen. > > Kernel 2.4.1, with reiserfs, devfs, no patches applied. > > "klog-X" are basically the same thing but I'm running top, syslogd, and > klogd with -20 priority. I didn't note anything out of the ordinary in > top. These are snapshots where I've managed to murder processes and > restart the problem without rebooting. > > In the second instance, I had my finger on the kill button and managed > to kill netscape and recover partially. However the system was heavily > loaded even after the kill. > > I have xmms in STOPped state so it's just waiting. > > kswapd is taking 12.2% of the CPU according to ps, and kapm-idled is > taking 26.9%. bdflush is taking 2.7%, X 3.5%, all others are nominal. > The system load was hovering at 1.00 for a few minutes then dropped to > zero. However scrolling text in an rxvt is slow enough to watch blocks > move. Running "ps aux" takes nearly one third of a second for total > time. Total number of processes is ~40. > > Jan 31 22:31:51 nifty kernel: kapm-idled S CBF77F94 4124 3 > 1(L-TLB) 4 2 > Jan 31 22:31:51 nifty kernel: Call Trace: [schedule_timeout+115/148] > [process_timeout+0/72] [apm_mainloop+221/256] [apm+668/692] > [kernel_thread+31/56] [kernel_thread+40/56] > > Jan 31 22:31:51 nifty kernel: kswapdS CBF75FAC 5704 4 > 1(L-TLB) 5 3 > Jan 31 22:31:51 nifty kernel: Call Trace: [schedule_timeout+115/148] > [process_timeout+0/72] [interruptible_sleep_on_timeout+66/92] > [kswapd+213/244] [kernel_thread+40/56] > > Jan 31 22:31:52 nifty kernel: bdflush S CBF7 5912 6 > 1(L-TLB) 7 5 > Jan 31 22:31:52 nifty kernel: Call Trace: [bdflush+206/216] > [kernel_thread+40/56] > > > In the fourth snapshot, I have put xmms in STOP state again inside the > memory shortage, memory is at 4800 free buffers/cache and 1592 free mem. > > As I entered this shortage period I started a 'ps -eo ... > file' to try > and record data there. This is the only disk activity happening. Load > is ~4.00. I have now killed the ps. > > Load has dropped significantly and I have tolerable but quite laggy user > input responsiveness now. > > Memory is currently 4900/1588 like above. Load is about 2.00 and will > continue dropping if I don't do anything. Any processes I exec which > need to be loaded from disk take several seconds. I.e. 'uptime' takes > about 4 seconds to execute. > > Snapshot #5 will be the last one and I will reboot. Once memory is > freed from xmms (back to 150megs free), everything is peachy. > > > -d > > -- > There is a natural aristocracy among men. The grounds of this are virtue and talents. > Thomas Jefferson The good thing about standards is that there are so many to choose > from. Andrew S. Tanenbaum > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[BUG] linux 2.4.1 to 2.4.1-ac3 hangs
0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 47) Subsystem: VIA Technologies, Inc. MVP3 ISA Bridge Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [f0] AGP version 2.0 Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2 Command: RQ=7 SBA+ AGP+ 64bit- FW- Rate=x1 00: 2b 10 25 05 07 00 90 02 04 00 00 03 08 40 00 00 10: 08 00 00 e8 00 00 00 e4 00 00 00 e5 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 2b 10 79 21 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 10 20 40: 20 41 57 50 00 3c 00 00 06 ff ff 06 00 00 00 00 50: 00 30 00 01 19 84 9b 01 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 f0 22 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 02 00 20 00 03 02 00 1f 01 03 00 07 00 00 00 00 oscar% cat /proc/ide/via --VIA BusMastering IDE Configuration Driver Version: 3.20 South Bridge: VIA vt82c586b Revision: ISA 0x47 IDE 0x6 BM-DMA base:0xe000 PCI clock: 33MHz Master Read Cycle IRDY:1ws Master Write Cycle IRDY:1ws BM IDE Status Register Read Retry: yes Max DRDY Pulse Width: No limit ---Primary IDE---Secondary IDE-- Read DMA FIFO flush: yes yes End Sector FIFO flush: no no Prefetch Buffer: yes yes Post Write Buffer:yes no Enabled: yes yes Simplex only: no no Cable Type: 40w 40w ---drive0drive1drive2drive3- Transfer Mode: UDMA UDMA PIO PIO Address Setup: 30ns 30ns 30ns 30ns Cmd Active: 90ns 90ns 90ns 90ns Cmd Recovery:30ns 30ns 30ns 30ns Data Active: 90ns 90ns 90ns 90ns Data Recovery: 30ns 30ns 30ns 30ns Cycle Time: 60ns 60ns 120ns 120ns Transfer Rate: 33.0MB/s 33.0MB/s 16.5MB/s 16.5MB/s Ed Tomlinson <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] linux 2.4.1 to 2.4.1-ac3 hangs
Hi, In retrospect it looks like there are three problems shown here. 1. The are the packet error messages which have just started appearing in ac3, but do not seem to hurt anything... I am forced to use pppoe and do have the mtu(s) set correctly (1500 on eth1, 1492 on ppp0 (which runs on eth1), all internal PC should have 1454 (one was incorrect and is now fixed)). I am using the ipchains module and have not tried the iptables filter to clamp mtus. 2. There is a PCI routing error reported during boot. The kernel does seem to resolve this ok - is this message anything to worry about? 3. System hangs. This box has been quite stable. The hangs started appearing around 2.4.1 or so. I very much doubt they are heat releated. I have had heat problems in the past an have moved the kit into a much better case. The old symptoms (ide tape problems) have gone and not returned even on the hotest summer day... Next time this happens I will try to telnet or ssh into box to see if anything is active, I will also setup a UPS on the box and see it that can shut it down. Its interesting that the software watchdog does not get triggered. TIA, Ed Tomlinson <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm1
On Tuesday 05 April 2005 03:05, Andrew Morton wrote: > - x86 NMI handling seems to be bust in 2.6.12-rc2. Try using > `nmi_watchdog=0' if you experience weird crashes. > > - The possible kernel-timer related hangs might possibly be fixed. We > haven't heard yet. > > - Nobody said anything about the PM resume and DRI behaviour in > 2.6.12-rc1-mm4. So it's all perfect now? > > - Various fixes and updates. Nothing earth-shattering. This refuses to boot here. It dies when assigning the EHCI driver. The mb is an MSI-7030 K8N Neo Platinium based on a nForce 3 250Gb Chipset (x86_64). I`ve been on vacation - the last kernel tried was 11-mm3 which booted fine but refuses to use all the usb ports supplied by the system (two work, three do not all using low speed). Any ideas what might be happening? Ed Tomlinson - 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/
Re: 2.6.12-rc2-mm3
On Monday 11 April 2005 04:25, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/ > > > - The anticipatory I/O scheduler has always been fairly useless with SCSI > disks which perform tagged command queueing. There's a patch here from Jens > which is designed to fix that up by constraining the number of requests > which we'll leave pending in the device. > > The depth currently defaults to 1. Tunable in > /sys/block/hdX/queue/iosched/queue_depth > > This patch hasn't been performance tested at all yet. If you think it is > misbehaving (the usual symptom is processes stuck in D state) then please > report it, then boot with `elevator=cfq' or `elevator=deadline' to work > around it. > > - More CPU scheduler work. I hope someone is testing this stuff. Something is not quite right here. I built rc2-mm3 and booted (uni processor, amd64, preempt on). mm3 lasted about 30 mins before locking up with a dead keyboard. I had mm2 reboot a few times over the last couple of days too. 11-mm3 uptime of 2 weeks+ 12-rc2-mm2 reboots once every couple of days 12-rc2-mm3 locked up within 30 mins using X using kmail/bogofilter My serial console does not seem to want to work. Has anything changed with this support? TIA, Ed Tomlinson - 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/
Re: 2.6.12-rc2-mm3
On Tuesday 12 April 2005 07:39, Andrew Morton wrote: > Ed Tomlinson <[EMAIL PROTECTED]> wrote: > > > > On Monday 11 April 2005 04:25, Andrew Morton wrote: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/ > > > > > > > > > - The anticipatory I/O scheduler has always been fairly useless with SCSI > > > disks which perform tagged command queueing. There's a patch here from > > > Jens > > > which is designed to fix that up by constraining the number of requests > > > which we'll leave pending in the device. > > > > > > The depth currently defaults to 1. Tunable in > > > /sys/block/hdX/queue/iosched/queue_depth > > > > > > This patch hasn't been performance tested at all yet. If you think it > > > is > > > misbehaving (the usual symptom is processes stuck in D state) then > > > please > > > report it, then boot with `elevator=cfq' or `elevator=deadline' to work > > > around it. > > > > > > - More CPU scheduler work. I hope someone is testing this stuff. > > > > Something is not quite right here. I built rc2-mm3 and booted (uni > > processor, amd64, preempt on). > > mm3 lasted about 30 mins before locking up with a dead keyboard. I had mm2 > > reboot a few times > > over the last couple of days too. > > > > 11-mm3 uptime of 2 weeks+ > > 12-rc2-mm2 reboots once every couple of days > > 12-rc2-mm3 locked up within 30 mins using X using kmail/bogofilter > > Unpleasant. Serial console would be nice ;) > > > My serial console does not seem to want to work. Has anything changed with > > this support? > > > > Don't think so - it works OK here. Checked the .config? Does the serial > port work if you do `echo foo > /dev/ttyS0'? ACPI? Turned out it was some old ups software that got reactivated on the box displaying the console - was a pain to disable it In any case, when the box reboots there are not any messages. Any ideas on what debug options to enable or suggestions on how we can figure out the cause of the reboots. TIA, Ed Tomlinson - 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/
Re: 2.6.12-rc2-mm3
On Wednesday 13 April 2005 20:20, Andrew Morton wrote:
> Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> >
> > > Don't think so - it works OK here. Checked the .config? Does the serial
> > > port work if you do `echo foo > /dev/ttyS0'? ACPI?
> >
> > Turned out it was some old ups software that got reactivated on the box
> > displaying the
> > console - was a pain to disable it
>
> OK.
>
> > In any case, when the box reboots there are not any messages. Any ideas
> > on what debug
> > options to enable or suggestions on how we can figure out the cause of the
> > reboots.
>
> There were a few problems in the task switching area - maybe that.
These hit arch/i386. Are they going to help on an x86_64 box?
Ed
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> delay the reloading of segment registers into switch_mm(), so that if
> the LDT size changes we dont get a (silent) fault and a zeroed selector
> register upon reloading.
>
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> ---
>
> 25-akpm/arch/i386/kernel/process.c | 10 +-
> 25-akpm/include/asm-i386/mmu_context.h |7 +++
> 2 files changed, 12 insertions(+), 5 deletions(-)
>
> diff -puN arch/i386/kernel/process.c~sched-unlocked-context-switches-fix
> arch/i386/kernel/process.c
> --- 25/arch/i386/kernel/process.c~sched-unlocked-context-switches-fix
> 2005-04-12 03:43:07.254363568 -0700
> +++ 25-akpm/arch/i386/kernel/process.c2005-04-12 03:43:07.259362808
> -0700
> @@ -653,12 +653,12 @@ struct task_struct fastcall * __switch_t
> asm volatile("mov %%gs,%0":"=m" (prev->gs));
>
> /*
> - * Restore %fs and %gs if needed.
> + * Clear selectors if needed:
>*/
> - if (unlikely(prev->fs | prev->gs | next->fs | next->gs)) {
> - loadsegment(fs, next->fs);
> - loadsegment(gs, next->gs);
> - }
> +if (unlikely((prev->fs | prev->gs) && !(next->fs | next->gs))) {
> +loadsegment(fs, next->fs);
> +loadsegment(gs, next->gs);
> +}
>
> /*
>* Now maybe reload the debug registers
> diff -puN include/asm-i386/mmu_context.h~sched-unlocked-context-switches-fix
> include/asm-i386/mmu_context.h
> --- 25/include/asm-i386/mmu_context.h~sched-unlocked-context-switches-fix
> 2005-04-12 03:43:07.256363264 -0700
> +++ 25-akpm/include/asm-i386/mmu_context.h2005-04-12 03:43:07.260362656
> -0700
> @@ -61,6 +61,13 @@ static inline void switch_mm(struct mm_s
> }
> }
> #endif
> + /*
> + * Now that we've switched the LDT, load segments:
> + */
> + if (unlikely(current->thread.fs | current->thread.gs)) {
> + loadsegment(fs, current->thread.fs);
> + loadsegment(gs, current->thread.gs);
> + }
> }
>
> #define deactivate_mm(tsk, mm) \
> _
>
>
-
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/
Re: 2.4.5 + ReiserFS + SMP + umount = oops
Hi,
This was reported on the reiserfs list yesterday. Seems that the cleanup
applied late in 2.4.5-pre affected the locking of the umount process. This
was posted to fix the problem.
Ed Tomlinson
---
"Vladimir V. Saveliev" wrote:
>
> Hi
>
> Gergely Tamas wrote:
> >
> > Hi!
> >
> > Kernel is 2.4.5
> >
> > I've tried to unmount a reiserfs device (/uu.new) and got a segfault.
>
> Well, sys_umount in 2.4.5 changed to not lock_kernel() at the beginning and to not
>unlock_kernel() at the end correspondingly.
> journal_begin expectes kernel locked and it oopses when it is not. Maybe
>reiserfs_put_super should lock_kernel () itself?
>
Hi,
You are right.
It seems, the next patch can fix umount reiserfs bug in linux-2.4.5 :
diff -urN v2.4.5/fs/reiserfs/super.c linux/fs/reiserfs/super.c
--- v2.4.5/fs/reiserfs/super.c Sun Apr 29 16:02:25 2001
+++ linux/fs/reiserfs/super.cSat May 26 19:10:16 2001
@@ -104,7 +104,8 @@
{
int i;
struct reiserfs_transaction_handle th ;
-
+
+ lock_kernel() ;
/* change file system state to current state if it was mounted with
read-write permissions */
if (!(s->s_flags & MS_RDONLY)) {
journal_begin(&th, s, 10) ;
@@ -117,6 +118,7 @@
** to do a journal_end
*/
journal_release(&th, s) ;
+ unlock_kernel() ;
for (i = 0; i < SB_BMAP_NR (s); i ++)
brelse (SB_AP_BITMAP (s)[i]);
Thanks,
Yura.
-
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/
LVM status in ac7?
Hi, What is the status of LVM in ac7? Is it safe to use the ac7 LVM code on a system currently using beta7? Is the beta7 patched needed with ac7? What is not in the ac7 patches? Is it apt to cause problems? TIA, Ed Tomlinson <[EMAIL PROTECTED]> - 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/
Re: Comment on patch to remove nr_async_pages limit
Hi, To paraphase Mike, We defer doing IO until we are under short of storage. Doing IO uses storage. So delaying IO as much as we do forces us to impose limits. If we did the IO earlier we would not need this limit often, if at all. Does this make any sense? Maybe we can have the best of both worlds. Is it possible to allocate the BH early and then defer the IO? The idea being to make IO possible without having to allocate. This would let us remove the async page limit but would ensure we could still free. Thoughts? Ed Tomlinson - 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/
missing symbol do_softirq in net moduels for pre-2
Hi, Built -pre2 and noticed most of the modules in net/* are getting a missing symbol for do_softirq. Have I messed up, or is there a real error? Ed Tomlinson <[EMAIL PROTECTED]> - 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/
what is using memory?
I have been trying to figure out what is using my memory My box has 320280K >From boot I see 924 kernel 8224 reserved (initrd ramdisk?) 1488 hash tables (dentry, inode, mount, buffer, page, tcp) from lsmod I caculate 876 for loaded modules from proc/slabinfo 11992 for all slabs from proc/meminfo 17140 buffer 123696 cache 32303 free leaving unaccounted 123627K This is about 38% of my memory, and only about 46% is pageable Is it possible to figure out what is using this? This is with 2.4.6-pre2 with Rik's page_launder_improvements patch, lvm beta7 and some reieserfs patches applied, after about 12 hours of uptime. TIA, Ed Tomlinson - 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/
Re: what is using memory?
On Monday 11 June 2001 04:20, Jonathan Morton wrote: > >My box has > > > >320280K > > > >from proc/meminfo > > > > 17140 buffer > >123696 cache > > 32303 free > > > >leaving unaccounted > > > >123627K > > This is your processes' memory, the inode and dentry caches, and possibly > some extra kernel memory which may be allocated after boot time. It is > *very* much accounted for. No its not. For instance the slab caches encompass the inode and dentry caches. Point I was/am tring to make is not that this memory is lost or not need, but that is it _not_ accounted. ie. There is not way to tell what is using it, hense we cannot see leaks or places that could be optimized. I have attempted to count all memory I could. The 123M is what is left in the kernel overhead bucket... Ed Tomlinson - 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/
Re: reiser4 vs politics: linux misses out again
On Sunday 10 July 2005 20:01, Ed Cogburn wrote: > Jim Crilly wrote: > > > But in most of the changesets on the bkbits site you can go back over 2 > > years and not see anything from namesys people. Nearly all of the fixes > > commited in the past 2-3 years are from SuSe. With Chris Mason's name attached? Chris wrote the journaling support for R3 and worked for SUSE for a while (he may still?). I also remember seeing quite a few patches run though the reiser mailing list for comment... > So, for the sake of argument, if IBM were to drop official support for JFS, > we'd yank JFS out of the kernel even if there was someone else willing to > support it? Why does it now *matter* who supports it, as long as its being > maintained? And will we now block IBM's hypothetical JFS2 from the kernel > if IBM, from the programmers up to the CEO, doesn't swear on their momma's > grave that they'll continue to support JFS1, even if JFS1 is being > supported by others? Jeez, this is why it doesn't take a kernel dev to see > the problems here, common sense seems to be an increasingly rare ingredient > in these arguments against R4. If I didn't know better, I'd think you were > making this stuff up as you went along - 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/
Re: Kernel Panic: VFS cannot open a root device
On Sunday 17 July 2005 22:46, Fawad Lateef wrote: > I saw this prob when my boot device/partition in the bootloader config > was wrong or the filesystem of my root partition is not compiled as a > kernel image rather compiled as module, so plz try to solve this prob > by selecting your desired filesystem in kernel configuration as Y > rather than M .. I hope this will work One further tip. Make your root FS's type the only one that is not a module. Once you have it booting then, if you want, flip other FSes to in kernel. Ed Tomlinson - 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/
Re: 2.6.13-rc3-mm1 - breaks DRI
Hi, I just tried 13-rc2-mm1 and dri is working again. Its reported to also work with 13-rc3. What in mm1 is apt to be breaking dri? Thanks Ed Tomlinson -- Forwarded Message -- Subject: Re: Xorg and RADEON (dri disabled) Date: Wednesday 20 July 2005 21:25 From: Ed Tomlinson <[EMAIL PROTECTED]> To: debian-amd64@lists.debian.org Cc: Michal Schmidt <[EMAIL PROTECTED]> On Wednesday 20 July 2005 21:13, Michal Schmidt wrote: > Ed Tomlinson wrote: > > Hi, > > > > With Xorg I get: > > > > (==) RADEON(0): Write-combining range (0xd000,0x800) > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is -1, (No such device) > > drmOpenDevice: open result is -1, (No such device) > > drmOpenDevice: Open failed > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is -1, (No such device) > > drmOpenDevice: open result is -1, (No such device) > > drmOpenDevice: Open failed > > drmOpenByBusid: Searching for BusID pci::01:00.0 > > drmOpenDevice: node name is /dev/dri/card0 > > drmOpenDevice: open result is 7, (OK) > > drmOpenByBusid: drmOpenMinor returns 7 > > drmOpenByBusid: drmGetBusid reports pci::01:00.0 > > (II) RADEON(0): [drm] loaded kernel module for "radeon" driver > > (II) RADEON(0): [drm] DRM interface version 1.2 > > (II) RADEON(0): [drm] created "radeon" driver at busid "pci::01:00.0" > > (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2411000 > > (II) RADEON(0): [drm] drmMap failed > > (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. > > > > And glxgears reports 300 frames per second. How do I get dri back? It > > was working fine with XFree. The XF86Config-4 was changed by the upgrade > > dropping some parms in the Device section. Restoring them has no effect > > on the problem. > What kernel do you use? I get the same behaviour with 2.6.13-rc3-mm1, > but it works with 2.6.13-rc3. I also use 2.6.13-rc3-mm1. Will try with a previous version an report to lkml if it works. Thanks Ed --- - 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/
Re: 2.6.13-rc3-mm1 - breaks DRI
On Thursday 21 July 2005 11:56, Andrew Morton wrote: > Ed Tomlinson <[EMAIL PROTECTED]> wrote: > > > >> -- Forwarded Message -- > >> > >> Subject: Re: Xorg and RADEON (dri disabled) > >> Date: Wednesday 20 July 2005 21:25 > >> From: Ed Tomlinson <[EMAIL PROTECTED]> > >> To: debian-amd64@lists.debian.org > >> Cc: Michal Schmidt <[EMAIL PROTECTED]> > >> > >> On Wednesday 20 July 2005 21:13, Michal Schmidt wrote: > >> > Ed Tomlinson wrote: > >> > > Hi, > >> > > > >> > > With Xorg I get: > >> > > > >> > > (==) RADEON(0): Write-combining range (0xd000,0x800) > >> > > drmOpenDevice: node name is /dev/dri/card0 > >> > > drmOpenDevice: open result is -1, (No such device) > >> > > drmOpenDevice: open result is -1, (No such device) > >> > > drmOpenDevice: Open failed > >> > > drmOpenDevice: node name is /dev/dri/card0 > >> > > drmOpenDevice: open result is -1, (No such device) > >> > > drmOpenDevice: open result is -1, (No such device) > >> > > drmOpenDevice: Open failed > >> > > drmOpenByBusid: Searching for BusID pci::01:00.0 > >> > > drmOpenDevice: node name is /dev/dri/card0 > >> > > drmOpenDevice: open result is 7, (OK) > >> > > drmOpenByBusid: drmOpenMinor returns 7 > >> > > drmOpenByBusid: drmGetBusid reports pci::01:00.0 > >> > > (II) RADEON(0): [drm] loaded kernel module for "radeon" driver > >> > > (II) RADEON(0): [drm] DRM interface version 1.2 > >> > > (II) RADEON(0): [drm] created "radeon" driver at busid > >> > > "pci::01:00.0" > >> > > (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2411000 > >> > > (II) RADEON(0): [drm] drmMap failed > >> > > (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. > >> > > > >> > > And glxgears reports 300 frames per second. How do I get dri back? It > >> > > was working fine with XFree. The XF86Config-4 was changed by the > >> > > upgrade > >> > > dropping some parms in the Device section. Restoring them has no > >> > > effect > >> > > on the problem. > >> > >> > What kernel do you use? I get the same behaviour with 2.6.13-rc3-mm1, > >> > but it works with 2.6.13-rc3. > >> > >> I also use 2.6.13-rc3-mm1. Will try with a previous version an report to > >> lkml if > >> it works. > >> > > > > I just tried 13-rc2-mm1 and dri is working again. Its reported to also work > > with 13-rc3. > > Useful info, thanks. > > > What in mm1 is apt to be breaking dri? > > Faulty kernel programming ;) > > I assume that the failure to open /dev/dri/card0 only happens in rc3-mm1? The difference in the X logs is that the working one does not have the: (II) RADEON(0): [drm] created "radeon" driver at busid "pci::01:00.0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2411000 (II) RADEON(0): [drm] drmMap failed message. When it works it has has: (II) RADEON(0): [drm] created "radeon" driver at busid "pci::01:00.0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0x10001000 (II) RADEON(0): [drm] mapped SAREA 0x10001000 to 0x2aaab2e67000 (II) RADEON(0): [drm] framebuffer handle = 0xd000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f004209 [AGP 0x10de/0x00e1; Card 0x1002/0x5961] (II) RADEON(0): [agp] 8192 kB allocated with handle 0x0001 (II) RADEON(0): [agp] ring handle = 0xe000 > Could you compare the dmesg output for 2.6.13-rc3 versus 2.6.13-rc3-mm1? > And double-check the .config settings: occasionally config options will be > renamed and `make oldconfig' causes things to get acidentally disabled. >From 13-rc2-mm1: Jul 21 07:31:20 grover kernel: [ 13.652465] Linux agpgart interface v0.101 (c) Dave Jones Jul 21 07:31:20 grover kernel: [ 13.652492] [drm] Initialized drm 1.0.0 20040925 and later Jul 21 07:31:34 grover kernel: [ 72.401795] [drm] Initialized radeon 1.16.0 20050311 on minor 0: ATI Technologies Inc RV280 [Radeon 9200] Jul 21 07:31:34 grover kernel: [ 72.402388] agpgart: Found an AGP 3.0 compliant device at :00:00.0. Jul 21 07:31:34 grover kernel: [ 72.402399] agpgart: Putting AGP V3 device at :00:00.0 into 4x mode Jul 21 07:31:34 grover kernel: [ 72.402419] agpgart: Putting AGP V3 device at :01:00.0 i
enabled udev - empty flash drive fills log with garbage
Hi, I am running 12-mm2. I recently enabled udev_0.060-1_amd64.deb. It booted with full support (eg. /etc/init.d/udev was not disabled). However the empty sddr09 based flash drive keeps being queried - this fills the log with garbage. How do I tell udev/kernel that an empty device is ok? There is an entry in fstab for this: /dev/sda1 /mnt/sd autorw,user,noauto 0 0 should it be disabled or changed? TIA Ed Tomlinson Jul 5 07:46:16 grover kernel: [ 267.496336] usb 1-4.2: reset full speed USB device using ohci_hcd and address 4 Jul 5 07:46:17 grover kernel: [ 267.547434] usb 1-4.2: reset full speed USB device using ohci_hcd and address 4 Jul 5 07:46:17 grover kernel: [ 267.599091] usb 1-4.2: reset full speed USB device using ohci_hcd and address 4 Jul 5 07:46:17 grover kernel: [ 267.644078] sddr09: could not read card info Jul 5 07:46:17 grover kernel: [ 267.654076] sddr09: could not read card info Jul 5 07:46:17 grover kernel: [ 267.654165] Device not ready. Jul 5 07:46:17 grover kernel: [ 267.664629] sddr09: could not read card info Jul 5 07:46:17 grover kernel: [ 267.664724] Device not ready. Jul 5 07:46:17 grover kernel: [ 267.674627] sddr09: could not read card info Jul 5 07:46:17 grover kernel: [ 267.674716] Device not ready. Jul 5 07:46:17 grover kernel: [ 267.674800] sda : READ CAPACITY failed. Jul 5 07:46:17 grover kernel: [ 267.674801] sda : status=1, message=00, host=0, driver=08 Jul 5 07:46:17 grover kernel: [ 267.674836] sd: Current: sense key: No Sense Jul 5 07:46:17 grover kernel: [ 267.674853] Additional sense: No additional sense information Jul 5 07:46:17 grover kernel: [ 267.675143] sda: test WP failed, assume Write Enabled Then there will be another reset or two and it all start over... - 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/
Re: GIT tree broken? (rsync depreciated)
Hi, I resync(ed) cg and rebuild this morning and it worked fine. On another tack. Updating the kernel gave a message that rsync is depreciated and will soon be turned off. How should we be updating git/cg trees now? Thanks Ed Tomlinson On Friday 08 July 2005 06:00, Stelian Pop wrote: > Le vendredi 08 juillet 2005 à 12:30 +0300, Meelis Roos a écrit : > > I'm trying to sync with > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > > with cogito cg-update (cogito 0.11.3+20050610-1 Debian package) and it > > fails with the following error: > > > > Applying changes... > > error: cannot map sha1 file 043d051615aa5da09a7e44f1edbb69798458e067 > > error: Could not read 043d051615aa5da09a7e44f1edbb69798458e067 > > cg-merge: unable to automatically determine merge base > > I see this too, with the latest cogito git tree, reproductible even in a > fresh environment: > > $ rm -rf linux-2.6.git > $ cg-clone > http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > linux-2.6.git > defaulting to local storage area > > 11:57:48 > URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/heads/master[41/41] > -> "refs/heads/origin" [1] > progress: 2 objects, 981 bytes > error: File 2a7e338ec2fc6aac461a11fe8049799e65639166 > (http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/2a/7e338ec2fc6aac461a11fe8049799e65639166) > corrupt > > Cannot obtain needed blob 2a7e338ec2fc6aac461a11fe8049799e65639166 > while processing commit . > cg-pull: objects pull failed > cg-init: pull failed > > Stelian. - 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/
Re: reiser4 vs politics: linux misses out again
On Friday 08 July 2005 18:59, Ed Cogburn wrote: > [EMAIL PROTECTED] wrote: > > > > In reality is it doesn't count. Users don't care what level of pain is > > involved in producing the products they use. > > > > Development efforts and results for OS's are always just taken for > > granted. > > > > BTDT - if you're very lucky, a (very) few non-programming users might > > notice something nice and mention that they noticed a difference. The > > majority are still struggling to find the power switch ;-> > > > You no longer have to be a kernel dev to see that there is more to the > resistance to R4 than objective technical issues, anyone with an > understanding of English whose been reading the R4 > debates-that-quickly-turn-into-flame-wars the last couple of years here can > see that. For you guys to continue to suggest otherwise only makes you out > to be the fools, not the "lusers" (which you obviously define as anyone who > isn't a kernel dev). > > So be my guest, ignore the message and attack the messenger, I didn't > respond to start yet another flamewar, nor did I really expect much > objectivity anyway, as that's been thrown out the window even in > discussions between developers, e.g. the R4 plugins thread. > > If its a fork of the kernel that you really want, so be it. When it > happens, and given the increasing divergence going on between the > commercial distros and the vanilla kernel, maybe it's already begun, I'll > use the one that isn't afraid of giving new ideas a chance. > > Flame away, I'm done. No Flame from me. One thing to remember is that Hans and friends _have_ supported R3 for years. This is an undisputed fact. Second third parties have be able to add much function (like journaling) to R3 so the code must be sort of readable... With R4 they have created a new FS that is _fast_ and _can_ do things no other FS can - I also expect they have written cleaner code... Why are we fighting about adding this sort of function to the kernel? Yes it may not be the absolute best way to do things. How many times has tcpip be rewritten for linux? The answer is more than once. Lets put R4 in, see how it works, generalize the ideas and if we have to rewrite and rethink part of it lets do so. Please do add R4 to the kernel! Thanks, Ed Tomlinson - 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/
Re: reiser4 vs politics: linux misses out again
On Sunday 10 July 2005 01:10, Horst von Brand wrote: > Ed Cogburn <[EMAIL PROTECTED]> wrote: > > David Lang wrote: > > > On Fri, 8 Jul 2005, Ed Tomlinson wrote: > > > >> No Flame from me. One thing to remember is that Hans and friends > > >> _have_ supported R3 for years. > > They let it fall into disrepair when they started work on 4. > > > >>This is an undisputed fact. > > Exactly. This is FUD. Hans do you have figures on how many fixes for R3 have been added in the last year or so? > > >>Second > > >> third parties have be able to add much function (like journaling) > > >> to R3 so the code must be sort of readable... > > Why don't you check it? Wouldn't you much prefer if the original authors > (or somebody similarly initmate with the code) did mayor surgery on it? > Specially if it is something you depend on? > > > >> With R4 they have created a new FS that is _fast_ > > Remains to be seen. > > > >> and _can_ do things > > >> no other FS can > > Mostly useless things... Just because you do not see how to use a new feature does not mean its useless... > > >> - I also expect they have written cleaner code... > > Better check first. > > > >> Why are we fighting about adding this sort of function to the kernel? > > Because the filessytem experts in the kernel development crowd (and others) > have /serious/ problems with the ideas and the code? > > > >> Yes it may not be the absolute best way to do things. How many times > > >> has tcpip be rewritten for linux? The answer is more than once. > > So? > > > >> Lets put R4 in, see how it works, generalize the ideas and if we have > > >> to rewrite and rethink part of it lets do so. > > Why not: Let's keep it out, fix the problems that it has and evaluate it > for inclusion once the problems have been ironed out? That has been the > policy for everything else as far as I can remember (and that is from > nearly the beginning...) When you are exploring new stuff its almost impossible to see the best way to do things. Once R4 (and other FSes) use these new features (or not) it will become more obvious how they should be coded. As it is not its a bit like trying to decide your new baby will be a doctor when he/she grows up - its not something you can predict. > > > remember that Hans is on record (over a year ago) arguing that R3 should > > > not be fixed becouse R4 was replacing it. > > > > This type of thing is one of the reasons that you see arguments that > > > aren't 'purely code-related' becouse the kernel folks realize that _they_ > > > will have to maintain the code over time, Hans and company will go on and > > > develop R5 (R10, whatever) and consider R4 obsolete and stop maintaining > > > it. > > > Maybe its because Hans and Co., having only a finite amount of dev time, > > would much prefer to spend that time on R4 rather than R3? > > ext2 is still being maintained alongside ext3. And so is R3 - just no new features are being added... > >Maybe if we > > were to let R4 into the kernel, it wouldn't be long after that R3 could be > > retired because everyone has moved to R4? > > ext3 is several years old, and there are /still/ ext2 users around... > See above - this should presend NO problems. > > Devs should be free to work on whatever they want, because most of them are > > doing this on their own time anyway, otherwise they might just decide to > > hack on some other OS, or a fork of Linux instead. > > Nobody forces anybody to work on Linux, or even on the standard Linus > kernel. It is the ReiserFS crowd who are demanding something from the Linux > crowd, not the other way around. - 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/
Re: 2.6.13-rc3-mm2/mm1 breaks DRI
>> >> >> >> I also use 2.6.13-rc3-mm1. Will try with a previous version an report to >> >> lkml if >> >> it works. >> >> >> > >> > I just tried 13-rc2-mm1 and dri is working again. Its reported to also work >> > with 13-rc3. >> > >Hmm no idea what could have broken it, I'm at OLS and don't have any >DRI capable machine here yet.. so it'll be a while before I get to >take a look at it .. I wouldn't be terribly surprised if some of the >new mapping code might have some issues.. Still happens with mm2. Thanks Ed - 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/
Re: 2.6.13-rc3-mm2/mm1 breaks DRI
On Wednesday 27 July 2005 17:58, Ed Tomlinson wrote: > >> >> > >> >> I also use 2.6.13-rc3-mm1. Will try with a previous version an report > >> >> to lkml if > >> >> it works. > >> >> > >> > > >> > I just tried 13-rc2-mm1 and dri is working again. Its reported to also > >> > work > >> > with 13-rc3. > >> > > > >Hmm no idea what could have broken it, I'm at OLS and don't have any > >DRI capable machine here yet.. so it'll be a while before I get to > >take a look at it .. I wouldn't be terribly surprised if some of the > >new mapping code might have some issues.. > > Still happens with mm2. And mm3 too. Please let me know if there is anything you would like me to try. Thanks Ed Tomlinson - 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/
Re: 2.6.13-rc3-mm2/mm1 breaks DRI
On Thursday 28 July 2005 20:41, Dave Airlie wrote: > > > > > > > >Hmm no idea what could have broken it, I'm at OLS and don't have any > > > >DRI capable machine here yet.. so it'll be a while before I get to > > > >take a look at it .. I wouldn't be terribly surprised if some of the > > > >new mapping code might have some issues.. > > > > > > Still happens with mm2. > > > > And mm3 too. Please let me know if there is anything you would like me to > > try. > > Hi Ed, > > Is this all on a 64-bit system, is it a pure 64-bit or are you running > a 32-bit userspace or something like that... I don't have any 64-bit > systems so tracking the issues on them is a nightmare... Its all 64bit... > I've got a patch from Egbert Eich that I need to drop into -mm that > might fix it but I'm snowed under with real work at the moment (taking > a week off for OLS didn't help :-) Pass me the patch. If I can get it to apply I will gladly try it. Real work is always 'fun'... Ed Tomlinson - 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/
Re: 2.6.13-rc6-mm1
On Friday 19 August 2005 07:33, Andrew Morton wrote: > - Lots of fixes, updates and cleanups all over the place. > > - If you have the right debugging options set, this kernel will generate > a storm of sleeping-in-atomic-code warnings at boot, from the scsi code. > It is being worked on. > > > Changes since 2.6.13-rc5-mm1: > Hi, It does not compile here: CC drivers/acpi/sleep/main.o In file included from drivers/acpi/sleep/main.c:15: include/linux/dmi.h:55: error: field 'list' has incomplete type make[3]: *** [drivers/acpi/sleep/main.o] Error 1 make[2]: *** [drivers/acpi/sleep] Error 2 make[1]: *** [drivers/acpi] Error 2 make: *** [drivers] Error 2 [EMAIL PROTECTED]:/usr/src/13-6-1$ Probably a missing include? Note that this is a non smp x86_64 build. Thanks Ed Tomlinson - 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/
Re: 2.6.13-rc6-mm1
Hi, Adding the include to dmi.h allows the compile to get past this point though I wonder if this is the correct place to put it? (Thanks Benoit) I now get: CC [M] net/ipv4/ipvs/ip_vs_ctl.o net/ipv4/ipvs/ip_vs_ctl.c:1601: error: static declaration of 'ipv4_table' follows non-static declaration include/net/ip.h:376: error: previous declaration of 'ipv4_table' was here make[3]: *** [net/ipv4/ipvs/ip_vs_ctl.o] Error 1 make[2]: *** [net/ipv4/ipvs] Error 2 make[1]: *** [net/ipv4] Error 2 make: *** [net] Error 2 Ideas? TIA Ed Tomlinson On Friday 19 August 2005 12:04, Benoit Boissinot wrote: > On 8/19/05, Ed Tomlinson <[EMAIL PROTECTED]> wrote: > > On Friday 19 August 2005 07:33, Andrew Morton wrote: > > > - Lots of fixes, updates and cleanups all over the place. > > > > > > - If you have the right debugging options set, this kernel will generate > > > a storm of sleeping-in-atomic-code warnings at boot, from the scsi code. > > > It is being worked on. > > > > > > > > > Changes since 2.6.13-rc5-mm1: > > > > > > > Hi, > > > > It does not compile here: > > > > CC drivers/acpi/sleep/main.o > > In file included from drivers/acpi/sleep/main.c:15: > > include/linux/dmi.h:55: error: field 'list' has incomplete type > > make[3]: *** [drivers/acpi/sleep/main.o] Error 1 > > make[2]: *** [drivers/acpi/sleep] Error 2 > > make[1]: *** [drivers/acpi] Error 2 > > make: *** [drivers] Error 2 > > [EMAIL PROTECTED]:/usr/src/13-6-1$ > > > > Probably a missing include? Note that this is a non smp x86_64 build. > > > including in dmi.h should work > > regards, > > Benoit > - > 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/ > > - 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/
Re: Fw: Oops with 2.6.13-rc6-mm2 and USB mouse
On Saturday 27 August 2005 16:39, Mattia Dongili wrote: > On Sat, Aug 27, 2005 at 05:09:04PM -0300, Rog???rio Brito wrote: > > Hi, Andrew. > > > > I just tested the USB mouse with 2.6.13-rc6-mm2 and ACPI disabled > > (which, according to Linus, is one of the "usual suspects") and the > > problem still occurred. > > see here > http://marc.theaimsgroup.com/?l=linux-kernel&m=11248143851&w=2 > > Reverting driver-core-fix-bus_rescan_devices-race.patch and applying the > patch attached to the above message fixed the oops for me. I my case removing a usb device or hub triggers an immediate reboot with mm2. This is fixed removing the above patch. All is ok with mm1 too. I tried the above process but the second patch does not apply. Thanks Ed Tomlinson - 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/
Re: RFC: i386: kill !4KSTACKS
On Sunday 04 September 2005 08:49, Denis Vlasenko wrote: > On Friday 02 September 2005 09:08, Alex Davis wrote: > > ndiswrapper and driverloader will not work reliably with 4k stacks. > > This is because of the Windoze drivers they use, to which, obviously, > > they do not have the source. Since quite a few laptops have built-in > > wireless cards by companies who will not release an open-source driver, > > or won't release specs, ndiswrapper and driverloader are the only way > > to get these cards to work. > > Please don't tell me to "get a linux-supported wireless card". I don't > > want the clutter of an external wireless adapter sticking out of my laptop, > > nor do I want to spend money on a card when I have a free and working > > solution. > > Please don't tell me to "care for closed-source drivers". I don't > want the pain of debugging crashes on the machines which run unknown code > in kernel space. > > IOW, if you run closed source modules - it's _your_ problem, not ours. > -- There is no logic to the above statement. We know when a kernel is tainted and do not try hard to debug problems when tainted . We also know that ndiswrapper and friends _currently_ let people use hardware that otherwise would have to run MS stuff. We know that 4K stacks hurt the above. Do we really want to break working configs just to enforce 4K stacks? How does it hurt to make 4K the default and allow 8K? What _might_ make sense is to make 8K a reason to taint the kernel. Ed Tomlinson - 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/
Re: Fwd: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
On January 10, 2008, Ingo Molnar wrote: > > * Matthew <[EMAIL PROTECTED]> wrote: > > > this also happens with rc7-based kernels, btw > > hm, exactly what rc7 based kernel? Vanilla 2.6.24-rc7, built by you? Or > any patches ontop of it? (x86.git perhaps?) Matthew is not alone with this problem. I have it too. Its not new here. Its been happening as long as I have had gentoo amd64 installed. It can be hard to reproduce but eventually, when 32 bit apps are used, my box bricks. There is nothing in the logs (nor on a serial console) - the box just freezes. My kernel is _not_ tainted. The kernel is currently 2.6.23-gentoo-r5-crc with the latest cfs backport applied; it does not seem to be critical though as it has happen with all kernels I have tried (mm, linux and gentoo varients). The processor is: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 4 model name : AMD Athlon(tm) 64 Processor 2800+ stepping: 10 cpu MHz : 1808.802 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow rep_good bogomips: 3620.77 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp I asked about this lkml before and was told it was probably a cpu/hardware issue... Its interesting that Matthew is also running gentoo. Thanks, Ed Tomlinson -- 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/
Re: Fwd: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
On January 10, 2008, Ingo Molnar wrote: > > * Ed Tomlinson <[EMAIL PROTECTED]> wrote: > > > Matthew is not alone with this problem. I have it too. Its not new > > here. Its been happening as long as I have had gentoo amd64 > > installed. It can be hard to reproduce but eventually, when 32 bit > > apps are used, my box bricks. There is nothing in the logs (nor on a > > serial console) - the box just freezes. > > > > My kernel is _not_ tainted. [...] > > ok, good. A series of questions: > > - can you reproduce it from the VGA console? No - though I do have a serial console to see logs. > - if yes, does booting with "nmi_watchdog=2 idle=poll" give you a > working NMI watchdog? (working NMI watchdog means the NMI counts > increase for all cores in /proc/interrupts). booting with the above gives me an incrementing NMI counter in /proc/interrupts > if still 'yes', then try to reproduce the hard hang on the VGA text > console - do you perhaps get an NMI backtrace printed within 1-2 minutes > after the hard hang happens? If yes then take a photo of that or write > it down. I am booted with the NMI watchdog and serial consoles active running apps that eventually will trigger a hang... Ed Tomlinson -- 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/
Re: Fwd: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
>> - if yes, does booting with "nmi_watchdog=2 idle=poll" give you a >> working NMI watchdog? (working NMI watchdog means the NMI counts >> increase for all cores in /proc/interrupts). > booting with the above gives me an incrementing NMI counter in > /proc/interrupts Ingo, Is there anything else that needs to be set in the kernel config for the nmi watchdog to trigger? I ask because I just had a hang but nothing showed on the _serial_ console - I waited a couple of minutes before rebooting Is there any other way to verify the watchdog is working? I seem to need X active with mix of 32 and 64 bit applications active to get hung here. A massivily threaded 64 bit java app along with 32 bit firefox and a wine active will eventually trigger things here. If I had to guess I would say that it the switch from 32 to 64 (or vise versa) that triggers the isuue. TIA & test/debug patches welcome, Ed Tomlinson -- 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/
Re: Fwd: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
On January 14, 2008, Ingo Molnar wrote: > > * Matthew <[EMAIL PROTECTED]> wrote: > > > > FYI, latest x86.git should have this fix included. So if your box > > > still hangs there must be some other bug lurking as well. > > > > > > the fix from Roland ?: http://lkml.org/lkml/2008/1/11/108 > > http://forums.gentoo.org/viewtopic-p-4719206.html#4719206 (+ following > > posts) > > > > works like a charm :) > > wine-problems should be solved, > > > > 64bit firefox & 32bit flash, 32bit firefox, 32bit thunderbird, > > realplayer work fine again without hardlocking so far (at least for > > me) > > great - thanks for following through with this, this was an important > regression to get fixed! I've added: > > Tested-by: Matthew <[EMAIL PROTECTED]> Ingo, This is _not_ a regression. This has been occuring for ages here. A backport of this fix to 2.6.23 would be a very good thing - IMHO its something that should go into stable asap. Thanks, Ed Tomlinson -- 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/
Re: Fwd: Fwd: laptop / computer hardlocks during execution of 32bit applications(binaries) on 64bit system (Gentoo)
On January 15, 2008, Ingo Molnar wrote: > > * Ed Tomlinson <[EMAIL PROTECTED]> wrote: > > > This is _not_ a regression. This has been occuring for ages here. A > > backport of this fix to 2.6.23 would be a very good thing - IMHO its > > something that should go into stable asap. > > the problem is that this bug was only present in x86.git. I.e. neither > 2.6.24 nor 2.6.23 has this particular bug. > > perhaps something else in x86.git fixed your box, but this > x86.git-specific hang 'took over its place', and now that it got fixed, > you've got a working box? In any case, please monitor your box, it might > still lock up the same way it did previously ... I am now testing with a .24-rc7+fix kernel. So far so good. Running gentoo's 32 bit firefox with flash 9 is a good way to trigger the problem here as is running Delftship (freeship) under wine. The problem is usually worst with a fully preemptive kernel. I have been using both on a kernel with preempt and have an uptime of 22 hours - this is really good. I have rarely been able to get this much uptime using these apps. If it manages to run for a few more days without a lockup it would really be worth trying to figure out what in .24 fixes the problem... THANKS! Ed Tomlinson -- 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/
2.6.24 Panic
Hi, Here is a trace back: This is grover.unknown_domain (Linux x86_64 2.6.24-gentoo-crc) 12:47:13 Booted with: kernel /boot/2.6.24-gentoo-crc root=/dev/sda3 vga=0x318 video=vesafb:ywrap,mtrr:3 console=tty0 console=ttyS0,38400 nmi_watchdog=2 idle=poll grover login: [ 75.987618] NMI Watchdog detected LOCKUP on CPU 0 [ 76.006096] CPU 0 [ 76.016515] Modules linked in: ipv6 af_packet rfcomm l2cap bluetooth snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device xfs usbhid pl2303 usbserial usbmouse ohci_hcd ehci_hcd video1394 w83627hf hwmon_vid i2c_nforce2 forcedeth sr_mod cdrom sbp2 parport_pc parport floppy rtc evdev ohci1394 radeonfb ieee1394 fb_ddc i2c_algo_bit i2c_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm thermal processor button snd_timer snd soundcore snd_page_alloc psmouse k8temp hwmon pcspkr unix [ 76.179223] Pid: 0, comm: swapper Not tainted 2.6.24-gentoo-crc #1 [ 76.202663] RIP: 0010:[] [] hrtimer_reprogram+0x0/0x50 [ 76.232721] RSP: 0018:805f7e90 EFLAGS: 0002 [ 76.253592] RAX: 805b6760 RBX: 81004efc5e98 RCX: 0001 [ 76.279968] RDX: 0001 RSI: 805b67b0 RDI: 8064ee80 [ 76.306300] RBP: 805f7ec8 R08: R09: [ 76.332666] R10: 0001 R11: 0001 R12: 8064ee80 [ 76.359053] R13: 81004efc5e88 R14: 805b67b0 R15: 805b67c0 [ 76.385438] FS: 2b69384386f0() GS:805ed000() knlGS: [ 76.414815] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [ 76.437133] CR2: 2abdf10a8370 CR3: 4f9dd000 CR4: 06e0 [ 76.463733] DR0: DR1: DR2: [ 76.490267] DR3: DR6: 0ff0 DR7: 0400 [ 76.516749] Process swapper (pid: 0, threadinfo 805f6000, task 805ac360) [ 76.546119] Stack: 802464e7 805f7ec8 8064ee80 805b67b0 [ 76.575463] 0086 000c83273e02 805f7f08 [ 76.602941] 80246c85 00018020a7c0 fffedf4c 000c7d315d0c [ 76.624835] Call Trace: [ 76.642724] [] enqueue_hrtimer+0xa7/0x110 [ 76.664832] [] hrtimer_start+0x75/0x110 [ 76.686378] [] tick_nohz_stop_sched_tick+0x205/0x2b0 [ 76.711324] [] poll_idle+0x0/0x10 [ 76.731313] [] cpu_idle+0x2a/0x90 [ 76.751204] [] rest_init+0x69/0x70 [ 76.771262] [] start_kernel+0x25a/0x2a0 [ 76.792637] [] _sinittext+0x107/0x110 [ 76.813478] [ 76.822851] [ 76.822851] Code: 55 48 89 e5 53 48 83 ec 08 48 8b 5f 18 48 2b 5e 40 f6 47 30 [ 76.859658] ---[ end trace bbed4a3078ba58f5 ]--- [ 76.878661] Kernel panic - not syncing: Attempted to kill the idle task! If this is timer related, the kernel uses 'tsc' as a the clocksource 'acpi_pm' is also available. What else will help track this down to fix it? TIA, Ed Tomlinson -- 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/
Re: [BK] upgrade will be needed
On Monday 14 February 2005 10:40, Larry McVoy wrote: > On Mon, Feb 14, 2005 at 10:08:20AM -0500, Jeff Sipek wrote: > > On Mon, Feb 14, 2005 at 01:08:58PM +0100, Bartlomiej Zolnierkiewicz wrote: > > > On Sun, 13 Feb 2005 18:08:02 -0800, Larry McVoy <[EMAIL PROTECTED]> wrote: > > > > is to clarify the non-compete stuff. We've had some people who have > > > > indicated that they believed that if they used BK they were agreeing > > > > that they would never work on another SCM system. We can see how it > > > > is possible that people would interpret the license that way but that > > > > wasn't our intent. What we would like to do is change the language to > > > > say that if you use BK you are agreeing that you won't work on another > > > > SCM for 1 year after you stop using BK. But after that you would be > > > > > > I don't even plan working on some SCM system, but being > > > tainted for 1 year for just *using* BK is not worth the price IMHO. > > > > I agree, the price is just too high. No matter how much I like BK, I > > would give it up. > > The way some people are reading the license the price is even higher, > they think it is a forever tainted license as it stands today. I've had > specific requests to clarify this part of the license. > > So how would you suggest that we resolve it? The protection we need is > that people don't get to How about just reversing it. If you work on another scm you cannot use _free_ bk for 1 year after you stop. Ed Tomlinson > - use BK > - stop using BK so they can go work on another system > - start using BK again > - stop using BK so they can go work on another system > ... > > We could say that if you stop using BK and work on another system then > you can't ever use it again. We're not going to do that, we've already > had to calm the fears of people who found themselves in that situation > for their job. > > So what do you want us to do? This isn't a change to take stuff from > you, it's a change that some of your peers asked us to do so they could > use BK (and it would be nice if the people who wanted this are reading > this thread and will speak up so it doesn't look like I'm making it up). > > What we've been doing so far is telling people who were worried to act as > if there were a year long gap and they have been happy with that answer > but they are asking for us to put it in the license so they don't have > to depend on some email based side agreement. > > It would be nice if you could talk this over amongst yourselves and > suggest an answer. I can see why you think it is a bad change, I'm hoping > that you can see why other people may want us to make this sort of change. > Maybe if you think about it a bit you'll come up with a better solution. > Or maybe we will. Either way, I can't be very involved in the process, > I'm taking off for a week long vacation starting Wednesday and I won't > have email access. Which will be a good way to make sure that if this > turns into a flame war I won't be prolonging it. - 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/
Re: [BK] upgrade will be needed
On Monday 14 February 2005 21:40, Larry McVoy wrote: > On Mon, Feb 14, 2005 at 09:13:14PM -0500, Ed Tomlinson wrote: > > > The way some people are reading the license the price is even higher, > > > they think it is a forever tainted license as it stands today. I've had > > > specific requests to clarify this part of the license. > > > > > > So how would you suggest that we resolve it? The protection we need is > > > that people don't get to > > > > How about just reversing it. If you work on another scm you cannot use > > _free_ bk for 1 year after you stop. > > Hi Ed, thanks for the thought. We've discussed this idea before with > some managers of open source developers and found that no matter which > one we pick some people don't like it. People tend to cluster up based on > whether they value working on $SCM more or using BK more. If they want to > preserve the ability to move people to working on competing products then > they would like the option you suggested. If they are more interested > in using BK then they would prefer the other way. The people we spoke > with were far more interested in the ability to move people onto BK when > they needed to. > > But it's a good idea and we'd certainly be willing to flip to your way > on a case by case basis. Thanks. My though was that this was less restrictive as there is an option to purchase a nonfree licence in there and sales are almost always a good thing. Ed - 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/
Re: Message incompatible avec le système de messagerie
SVP stop. Cette message et SPAM! Pour local cet pas mal, pur l'internet cet SPAM. m'excuse mon francais terrible Ed Tomlinson On Monday 29 November 2004 11:23, Service de messagerie wrote: > Le message émis par linux-kernel@vger.kernel.org est incompatible avec le > système de messagerie, il a été supprimé. > > Certains éléments contenus dans ce message ayant pour objet :" Re: Your > details " sont susceptibles d'être dangereux pour le destinataire : [EMAIL > PROTECTED] . > > > - > 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/ > > - 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/
Re: [BK] upgrade will be needed
On Thursday 17 February 2005 11:58, Sean wrote: > On Thu, February 17, 2005 11:55 am, Chris Friesen said: > > > If you look at the archives, there have been a *lot* of people saying > > very much the same thing as you. I suspect people are getting tired of > > giving the same responses all the time. > > > > Here is what Linus had to say about it a while back: > > > > If people in the open-source SCM community wake up and notice that > > the current open-source SCM systems aren't cutting it, that's _good_. > > But it's absolutely NOT an excuse to use them today. Sorry. I use > > CVS at work, and I could never use it for Linux. I took a look at > > subversion, and it doesn't even come close to what I wanted. > > > > And I personally refuse to use inferior tools because of ideology. In > > fact, I will go as far as saying that making excuses for bad tools > > due to ideology is _stupid_, and people who do that think with their > > gonads, not their brains. > > Chris, > > Yes, I do remember that post. But i'm not arguing from an ideological > basis; i'm arguing on practical grounds that the price of using BK is too > high for its supposed benefits. I've not seen anyone else make that Huh? This ideology in my books. > argument here on the list and it is something that Linus may not have > given full consideration to. At least the comment that you quote gives > no consideration to it at all. Linus has tried other SCMs. They did not suffice. I remember the preBK days, when you had to post a patch half a dozen time to get it merged. Patches were being missed left right and center. This changed after BK. We _are_ getting large benefits from BK. They may be hard to see at our side of the keyboard - but I believe Linus when he says BK is the best tool for him. That this probably will not be the case for ever. Think it still is for now though. Ed Tomlinson - 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/
Re: [BK] upgrade will be needed
On Friday 18 February 2005 02:26, Sean wrote: > On Thu, February 17, 2005 11:00 pm, Theodore Ts'o said: > > > If you think that, you truly do not understand the value of BK, and > > why Linus chose it. > > Hey Ted, > > No, I just disagree that it was an absolute requirement or worth its cost > that so many want to completely discount. Andrew has pretty much shown > BK is not required, he's still using patches. Andrew uses BK too. He extends its function by maintaining a set of patches above and beyond the committed BK tree... Ted made a really valid point. The people at the top _are_ _very_ _very_ important. There are several ways to get kernel source if _you_ do not want to use BK. I use BK. There are enough projects around that I can avoid working on a SVM for a year... Thats my option though - you do not have to agree. Ed - 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/
Re: 2.6.11-rc1-mm2
On Thursday 20 January 2005 00:38, Andrew Morton wrote: > - This kernel isn't particularly well-tested, sorry. I've been a bit tied > up with other stuff. I recently switched my main box to a x86_64 box and installed the unofficial debian 'true64' port on it. I have been running 11-rc2 (with the aa oom patches) with no real problems. I decided to try 11-rc2-mm2. The first time (with a serial console active) it ended with a panic. When I enabled a serial console it stalled. I used alt+sysrq+T and then rebooted. Here is the log. There are no extra patches on top of mm2. I compiled using gcc 3.4, with a .config based on 11-rc2 using oldconfig. Ed Tomlinson Bootdata ok (command line is root=/dev/hda3 ro console=tty0 console=ttyS0,38400) Linux version 2.6.11-rc2-mm2 ([EMAIL PROTECTED]) (gcc version 3.4.4 20041218 (prerelease) (Debian 3.4.3-7)) #1 Sun Jan 30 09:18:40 EST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 1fff3000 (ACPI NVS) BIOS-e820: 1fff3000 - 2000 (ACPI data) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fef0 (reserved) BIOS-e820: fefffc00 - ff00 (reserved) BIOS-e820: - 0001 (reserved) Nvidia board detected. Ignoring ACPI timer override. ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information Checking aperture... CPU 0: aperture @ e000 size 128 MB Built 1 zonelists Initializing CPU#0 Kernel command line: root=/dev/hda3 ro console=tty0 console=ttyS0,38400 PID hash table entries: 2048 (order: 11, 65536 bytes) time.c: Using 1.193182 MHz PIT timer. time.c: Detected 1808.838 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Memory: 510272k/524224k available (2163k kernel code, 13180k reserved, 1393k data, 140k init) Security Framework v1.0.0 initialized Capability LSM initialized Mount-cache hash table entries: 256 (order: 0, 4096 bytes) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: AMD Athlon(tm) 64 Processor 2800+ stepping 0a Using local APIC NMI watchdog using perfctr0 Using local APIC timer interrupts. Detected 12.561 MHz APIC timer. NET: Registered protocol family 16 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050125 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: Power Resource [ISAV] (on) ACPI: PCI Interrupt Link [LNK1] (IRQs<7>Losing some ticks... checking if CPU frequency changed. 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 6 *7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LUBA] (IRQs *3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LUBB] (IRQs *3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LAPU] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LUB2] (IRQs *3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LFIR] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [L3CM] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LSID] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LFID] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [APC1] (IRQs *16), disabled. ACPI: PCI Interrupt Link [APC2] (IRQs *17), disabled. ACPI: PCI Interrupt Link [APC3] (IRQs *18), disabled. ACPI: PCI
Re: 2.6.11-rc4-mm1
On Wednesday 23 February 2005 17:38, J.A. Magallon wrote: > > On 02.23, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ > > > > > > - Various fixes and updates all over the place. Things seem to have slowed > > down a bit. > > > > - Last, final, ultimate call: if anyone has patches in here which are 2.6.11 > > material, please tell me. > > > > Two points: > > - I lost my keyboard :(. USB, but plugged into PS/2 with an adapter. Mine too. Details sent in another message... Ed > - hdb is missing. initscripts show an strange message about hdq ?? > As I read the same on other post, I think something has screwed the > ide device naming scheme ... > > TIA > > -- > J.A. Magallon \ Software is like sex: > werewolf!able!es \ It's better when it's free > Mandrakelinux release 10.2 (Cooker) for i586 > Linux 2.6.10-jam10 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-3mdk)) #2 > > > - > 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/ > > - 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/
Re: 2.6.11-rc4-mm1
On Wednesday 23 February 2005 04:42, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ > > > - Various fixes and updates all over the place. Things seem to have slowed > down a bit. > > - Last, final, ultimate call: if anyone has patches in here which are 2.6.11 > material, please tell me. It boots fine here except that my keyboard is dead, rc3-mm2 is fine. The .config was built via using rc3-mm2's config and make oldconfig. Looking it the boot log I see: in rc3-mm2 Feb 23 17:49:20 grover kernel: Initializing Cryptographic API Feb 23 17:49:20 grover kernel: Linux agpgart interface v0.101 (c) Dave Jones Feb 23 17:49:20 grover kernel: [drm] Initialized drm 1.0.0 20040925 Feb 23 17:49:20 grover kernel: ACPI: PS/2 Keyboard Controller [PS2K] at I/O 0x60, 0x64, irq 1 Feb 23 17:49:20 grover kernel: ACPI: PS/2 Mouse Controller [PS2M] at irq 12 Feb 23 17:49:20 grover kernel: serio: i8042 AUX port at 0x60,0x64 irq 12 Feb 23 17:49:20 grover kernel: serio: i8042 KBD port at 0x60,0x64 irq 1 Feb 23 17:49:20 grover kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled in rc4-mm1 Feb 23 17:46:54 grover kernel: Initializing Cryptographic API Feb 23 17:46:54 grover kernel: inotify device minor=63 Feb 23 17:46:54 grover kernel: Linux agpgart interface v0.101 (c) Dave Jones Feb 23 17:46:54 grover kernel: [drm] Initialized drm 1.0.0 20040925 Feb 23 17:46:54 grover kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled Feb 23 17:46:54 grover kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A It does not seem to be finding the keyboard at all... Ideas? Ed Tomlinson diff -u ../11-3-2/.config .config --- ../11-3-2/.config 2005-02-12 09:55:28.0 -0500 +++ .config 2005-02-23 07:10:53.0 -0500 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.11-rc3-mm2 -# Sat Feb 12 09:55:28 2005 +# Linux kernel version: 2.6.11-rc4-mm1 +# Wed Feb 23 07:10:53 2005 # CONFIG_X86_64=y CONFIG_64BIT=y @@ -91,6 +91,7 @@ CONFIG_X86_MCE_INTEL=y CONFIG_PHYSICAL_START=0x10 CONFIG_KEXEC=y +CONFIG_SECCOMP=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y @@ -119,6 +120,8 @@ CONFIG_ACPI_ASUS=m # CONFIG_ACPI_IBM is not set CONFIG_ACPI_TOSHIBA=m +# CONFIG_ACPI_PCC is not set +# CONFIG_ACPI_SONY is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y @@ -459,6 +462,7 @@ CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m +# CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs @@ -493,6 +497,7 @@ # CONFIG_SCSI_ATA_PIIX is not set CONFIG_SCSI_SATA_NV=m # CONFIG_SCSI_SATA_PROMISE is not set +# CONFIG_SCSI_SATA_QSTOR is not set # CONFIG_SCSI_SATA_SX4 is not set # CONFIG_SCSI_SATA_SIL is not set # CONFIG_SCSI_SATA_SIS is not set @@ -543,6 +548,8 @@ CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m CONFIG_DM_ZERO=m +CONFIG_DM_MULTIPATH=m +CONFIG_DM_MULTIPATH_EMC=m # # Fusion MPT device support @@ -971,6 +978,11 @@ CONFIG_BT_HCIBPA10X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIVHCI=m +CONFIG_IEEE80211=m +# CONFIG_IEEE80211_DEBUG is not set +CONFIG_IEEE80211_CRYPT_WEP=m +CONFIG_IEEE80211_CRYPT_CCMP=m +CONFIG_IEEE80211_CRYPT_TKIP=m CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_BONDING=m @@ -1263,6 +1275,8 @@ # CONFIG_JOYSTICK_JOYDUMP is not set CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_GUNZE=m +# CONFIG_TOUCHSCREEN_ELO is not set +# CONFIG_TOUCHSCREEN_MK712 is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m CONFIG_INPUT_UINPUT=m @@ -1293,6 +1307,7 @@ CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y +CONFIG_INOTIFY=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_COMPUTONE=m CONFIG_ROCKETPORT=m @@ -1370,6 +1385,7 @@ CONFIG_IB700_WDT=m CONFIG_WAFER_WDT=m CONFIG_I8XX_TCO=m +# CONFIG_I6300ESB_WDT is not set CONFIG_SC1200_WDT=m CONFIG_SCx200_WDT=m CONFIG_60XX_WDT=m @@ -1444,6 +1460,11 @@ CONFIG_HANGCHECK_TIMER=m # +# TPM devices +# +# CONFIG_TCG_TPM is not set + +# # I2C support # CONFIG_I2C=m @@ -1471,6 +1492,7 @@ CONFIG_I2C_NFORCE2=m CONFIG_I2C_PARPORT=m CONFIG_I2C_PARPORT_LIGHT=m +# CONFIG_I2C_PIIX4 is not set CONFIG_I2C_PROSAVAGE=m CONFIG_I2C_SAVAGE4=m CONFIG_SCx200_ACB=m @@ -1496,6 +1518,7 @@ CONFIG_SENSORS_FSCHER=m # CONFIG_SENSORS_FSCPOS is not set CONFIG_SENSORS_GL518SM=m +CONFIG_SENSORS_GL520SM=m CONFIG_SENSORS_IT87=m # CONFIG_SENSORS_LM63 is not set CONFIG_SENSORS_LM75=m @@ -1509,6 +1532,7 @@ CONFIG_SENSORS_MAX1619=m # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_SMSC47B397 is not set +CONFIG_SENSORS_SIS5595=m # CONFIG_SENSORS_SMSC47M1 is not set CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_W83781D=m @@ -1682,6 +1706,10 @@ # Graphics support # CONFIG_FB=y +CONFIG_FB_CFB_FILLRECT=y +CONFIG_FB_CFB_COPYAREA=y +CONFIG_FB_CFB_IMAGEBLIT=y +CONFIG_FB_SO
Re: 2.6.11-rc4-mm1
On Wednesday 23 February 2005 18:40, Dmitry Torokhov wrote: > On Wednesday 23 February 2005 18:12, Ed Tomlinson wrote: > > On Wednesday 23 February 2005 17:38, J.A. Magallon wrote: > > > > > > On 02.23, Andrew Morton wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ > > > > > > > > > > > > - Various fixes and updates all over the place. Things seem to have > > > > slowed > > > > down a bit. > > > > > > > > - Last, final, ultimate call: if anyone has patches in here which are > > > > 2.6.11 > > > > material, please tell me. > > > > > > > > > > Two points: > > > > > > - I lost my keyboard :(. USB, but plugged into PS/2 with an adapter. > > > > Mine too. Details sent in another message... > > > > Does i8042.nopnp help? Dmitry, Yes it works fine with this kernel parm. I run with hotplug on and udev off. Andrew, 11-bk is also fine (without the parm). Thanks Ed Tomlinson - 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/
Re: RFD: Kernel release numbering
On Wednesday 02 March 2005 22:37, Linus Torvalds wrote: > > On Wed, 2 Mar 2005, Jeff Garzik wrote: > > > > If we want a calming period, we need to do development like 2.4.x is > > done today. It's sane, understandable and it works. > > No. It's insane, and the only reason it works is that 2.4.x is a totally > different animal. Namely it doesn't have the kind of active development AT > ALL any more. It _only_ has the "even" number kind of things, and quite > frankly, even those are a lot less than 2.6.x has. > > > 2.6.x-pre: bugfixes and features > > 2.6.x-rc: bugfixes only > > And the reason it does _not_ work is that all the people we want testing > sure as _hell_ won't be testing -rc versions. > > That's the whole point here, at least to me. I want to have people test > things out, but it doesn't matter how many -rc kernels I'd do, it just > won't happen. It's not a "real release". > > In contrast, making it a real release, and making it clear that it's a > release in its own right, might actually get people to use it. It seems to me that the problem is not the numbering scheme. We _will_ experience the same issues no mater what scheme we use... The way I see it is that we need a way to tell how much testing a given release has had. I would suggest an opt outable scheme that records boot (via an email for instance) and asks for comments after a day or two. With this sort of method we would _know_ just how much testing is done. We eventually could start to relate the amount of testing to just how stable the kernel will be. Comments Ed Tomlinson - 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/
cs46xx and 2.4.6-pre6
Hi, Suspect the #define CS46XX_APCI_SUPPORT 1 found in cs46xxpm-24.h is bogus. With it defined I can conflicts between it an cs46xx.c with cs46xx_suspend_tlb and cs46xx_resume_tbl Removed the #define and the module built. Ed Tomlinson - 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/
Re: [RFQ] Rules for accepting patches into the linux-releases tree
On Saturday 05 March 2005 00:08, Ian Pilcher wrote: > Greg KH wrote: > > Anything else anyone can think of? Any objections to any of these? > > I based them off of Linus's original list. > > Must already be in Linus tree (i.e. 2.6.X+1)? How about must be logicily fixed in the Linus tree - Linus does not have to have the same patch... Ed - 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/
Re: 2.6.11-mm3
On Saturday 12 March 2005 06:42, Andrew Morton wrote: > 2.6.11-mm3 > From: Andrew Morton <[EMAIL PROTECTED]> > To: linux-kernel@vger.kernel.org > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm3/ > > > - A new version of the "acpi poweroff fix". People who were having trouble > with ACPI poweroff, please test and report. > > - A very large update to the CFQ I/O scheduler. Treat with caution, run > benchmarks. Remember that the I/O scheduler can be selected on a per-disk > basis with > > echo as > /sys/block/sda/queue/scheduler > echo deadline > /sys/block/sda/queue/scheduler > echo cfq > /sys/block/sda/queue/scheduler > > - video-for-linux update Building with an -mm1 oldconfiged on x86-64 arch I get: LD fs/ntfs/built-in.o CC [M] fs/ntfs/aops.o CC [M] fs/ntfs/attrib.o fs/ntfs/attrib.c: In function `ntfs_attr_make_non_resident': fs/ntfs/attrib.c:1295: warning: implicit declaration of function `ntfs_cluster_alloc' fs/ntfs/attrib.c:1296: error: `DATA_ZONE' undeclared (first use in this function) fs/ntfs/attrib.c:1296: error: (Each undeclared identifier is reported only once fs/ntfs/attrib.c:1296: error: for each function it appears in.) fs/ntfs/attrib.c:1296: warning: assignment makes pointer from integer without a cast fs/ntfs/attrib.c:1435: warning: implicit declaration of function `flush_dcache_mft_record_page' fs/ntfs/attrib.c:1436: warning: implicit declaration of function `mark_mft_record_dirty' fs/ntfs/attrib.c:1443: warning: implicit declaration of function `mark_page_accessed' fs/ntfs/attrib.c:1521: warning: implicit declaration of function `ntfs_cluster_free_from_rl' make[2]: *** [fs/ntfs/attrib.o] Error 1 make[1]: *** [fs/ntfs] Error 2 make: *** [fs] Error 2 Ed Tomlinson - 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/
2.4.4-pre8 undefined symbols
Hi
The following patch adpated from the fix in the ac series, fixes the undefined
symbols in the various drm modules in pre7/8.
-
--- linux/lib/rwsem.c.orig Fri Apr 27 13:24:48 2001
+++ linux/lib/rwsem.c Fri Apr 27 13:25:08 2001
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
struct rwsem_waiter {
struct list_headlist;
@@ -202,9 +203,9 @@
return sem;
}
-EXPORT_SYMBOL(rwsem_down_read_failed);
-EXPORT_SYMBOL(rwsem_down_write_failed);
-EXPORT_SYMBOL(rwsem_wake);
+EXPORT_SYMBOL_NOVERS(rwsem_down_read_failed);
+EXPORT_SYMBOL_NOVERS(rwsem_down_write_failed);
+EXPORT_SYMBOL_NOVERS(rwsem_wake);
#if RWSEM_DEBUG
EXPORT_SYMBOL(rwsemtrace);
#endif
-
Ed Tomlinson
-
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/
Atrocious icache/dcache in 2.4.2
Hi,
Here is a patch that prunes unused, clean inodes from the icache
faster. I have previously checked out cleaning the unused dirty
icache entries from the the same place in kswapd but did not find
it to be much a win.
This code does the following. It factors prune_icache to use,
prune_unused_icache to actually prune the list. This makes it
simple to add a shrink_unused_icache_memory routine which gets
plugged into the kswapd loop. The result is the icache is kept
smaller.
fast_prune.diff
-
--- 2.4.4-pre7/include/linux/dcache.h Thu Apr 26 12:57:47 2001
+++ linux/include/linux/dcache.hFri Apr 27 18:17:20 2001
@@ -176,6 +176,7 @@
/* icache memory management (defined in linux/fs/inode.c) */
extern void shrink_icache_memory(int, int);
+extern void shrink_unused_icache_memory(int);
extern void prune_icache(int);
/* only used at mount-time */
--- 2.4.4-pre7/mm/vmscan.c Fri Apr 27 11:36:04 2001
+++ linux/mm/vmscan.c Fri Apr 27 18:33:07 2001
@@ -953,6 +953,11 @@
*/
refill_inactive_scan(DEF_PRIORITY, 0);
+ /*
+* Free unused inodes.
+*/
+ shrink_unused_icache_memory(GFP_KSWAPD);
+
/* Once a second, recalculate some VM stats. */
if (time_after(jiffies, recalc + HZ)) {
recalc = jiffies;
--- 2.4.4-pre7/fs/inode.c Thu Apr 26 12:49:33 2001
+++ linux/fs/inode.cFri Apr 27 18:54:25 2001
@@ -540,16 +540,16 @@
!inode_has_buffers(inode))
#define INODE(entry) (list_entry(entry, struct inode, i_list))
-void prune_icache(int goal)
+/*
+ * Called with inode lock held, returns with it released.
+ */
+int prune_unused_icache(int goal)
{
LIST_HEAD(list);
struct list_head *entry, *freeable = &list;
- int count = 0, synced = 0;
+ int count = 0;
struct inode * inode;
- spin_lock(&inode_lock);
-
-free_unused:
entry = inode_unused.prev;
while (entry != &inode_unused)
{
@@ -577,19 +577,27 @@
dispose_list(freeable);
+ return count;
+}
+
+/*
+ * A goal of zero frees everything
+ */
+void prune_icache(int goal)
+{
+ spin_lock(&inode_lock);
+ goal -= prune_unused_icache(goal);
+
/*
* If we freed enough clean inodes, avoid writing
-* dirty ones. Also giveup if we already tried to
-* sync dirty inodes.
+* dirty ones.
*/
- if (!goal || synced)
+ if (!goal)
return;
- synced = 1;
-
spin_lock(&inode_lock);
try_to_sync_unused_inodes();
- goto free_unused;
+ prune_unused_icache(goal);
}
void shrink_icache_memory(int priority, int gfp_mask)
@@ -611,6 +619,20 @@
prune_icache(count);
kmem_cache_shrink(inode_cachep);
+}
+
+void shrink_unused_icache_memory(int gfp_mask)
+{
+ /*
+* Nasty deadlock avoidance..
+*/
+ if (!(gfp_mask & __GFP_IO))
+ return;
+
+ if (spin_trylock(&inode_lock)) {
+ prune_unused_icache(0);
+ kmem_cache_shrink(inode_cachep);
+ }
}
/*
-----
Comments?
Ed Tomlinson <[EMAIL PROTECTED]>
-
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/
[BUG] pdc20267 and dma timeouts
Hi,
I am running 2.4.4 with the lvm -0.91 beta7 patches applied on a debian
sid base. When I checked my box this morning the follow greeted me on
the serial console. The reiserfs errors are caused by the DMA timeout.
Note this is a ultra100 controller not supporting raid.
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
is_tree_node: node level 15360 does not match to the expected one 1
vs-5150: search_by_key: invalid format found in block 40470. Fsck?
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data
o]vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: DMA disabled
ide2: reset: success
hdg: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdg: irq timeout: status=0x50 { DriveReady pmlete }
hde: lost interrupt
hdg: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdg: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: lost interrupt
hdg: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdg: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: lost interrupt
hdg: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdg: irq timeout: status=0x50 { DriveReady SeekComplete }
hdg: DMA disabled
ide3: reset: success
hde: lost interrupt
hde: lost interrupt
hde: lost interrupt
hde: lost interrupt
hde: lost interrupt
hde: lost interrupt
hde: lost interrupt
with another lost interrupt entry added every couple of seconds. Looks like
the reset is not working... Here is a lspci -vv of the device
00:0a.0 Unknown mass storage controller: Promise Technology, Inc. 20267 (rev 02)
Subsystem: Promise Technology, Inc.: Unknown device 4d33
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR-
-
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/
Linux 2.4.4-ac5; hpt370 & new dma setup
[EMAIL PROTECTED] wrote:
> On Fri, May 04, 2001 at 11:24:58PM +0100, Alan Cox wrote:
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
>>
>> Intermediate diffs are available from
>>
>> http://www.bzimage.org
>>
>> Please test this code **carefully** if using an HPT366/370 IDE controller as
>> there are driver changes there. Otherwise its mostly just catching up with
>> the bugfixes.
>>
>> 2.4.4-ac5
>> oFix DMA setup on hpt366/370 (Tim Hockin)
>
> I see definite changes; on heavy disk-access I got the following:
>
> hdg: timeout waiting for dma
> ide_dmaproc: chipset supported ide_dma_timeout func only:14
> hdg: irq timeout: status = 0x58 { DriveReady SeekComplete DataRequest}
>
> this was repeated several times, and ide3 was being reset, but the
> kernel hung anyway after 5 minutes of waiting.
>
> I must have an unlucky set of hardware (via chipset VP6 board, Live!,
> ibm drives).
Funny I have had the same problem with 2.4.4 only with a pdc20267 (reported
to lkml with topic '[BUG] pdc20267 and dma timeouts') Is there some problem
with resets on ide2/3?
TIA
Ed Tomlinson <[EMAIL PROTECTED]>
Ed Tomlinson
-
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/
oops with 2.4.5-pre1
Hi After 4 days of uptime I got the following oops. Nothing special was happening at the time. Ideas? Ed Tomlinson <[EMAIL PROTECTED]> ksymoops 2.4.1 on i586 2.4.5-pre1. Options used -V (default) -k 20010507195318.ksyms (specified) -l 20010507195318.modules (specified) -o /lib/modules/2.4.5-pre1/ (default) -m /boot/System.map-2.4.5-pre1 (default) Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry Unable to handle kernel paging request at virtual address 8528 c01b4612 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: d1dc8d20 ebx: 8528 ecx: edx: 8528 esi: c0d76ea0 edi: d1dc85c0 ebp: 0060 esp: c023bddc ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c023b000) Stack: f900 c01b46bb c0d76ea0 f900 c0d76ea0 c01b4c63 c0d76ea0 c0d76ea0 d3eac800 d19eb0a0 d3eac800 ffe6 c01b7ad6 c0d76ea0 0002 c62af280 c0d76ea0 c01bac03 c0d76ea0 c0d76ea0 0004 c01c4b5c c01c4lcl Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [ 4[] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 1b 8b 42 70 83 f8 01 74 0a ff 4a 70 0f 94 c0 84 c0 74 09 >>EIP; c01b4612<= Trace; c01b46bb Trace; c01b4c63 Trace; c01b7ad6 Trace; c01bac03 Trace; c01c4b5c Trace; c01c4bd5 Trace; c01bccaf Trace; c01c234c Trace; c01c4b42 Trace; c01c4b5c Trace; c01c239a Trace; c01bccaf Trace; c01c22f8 Trace; c01c176b Trace; c01c1618 Trace; c01bccaf Trace; c01c1475 Trace; c01c1618 Trace; c01b806b Trace; c0115490 Trace; c0107ed2 Trace; c01051f0 Trace; c0106bf0 Trace; c01051f0 Trace; c0105213 Trace; c0105277 Trace; c0105000 Trace; c0100197 Code; c01b4612 <_EIP>: Code; c01b4612<= 0: 8b 1b mov(%ebx),%ebx <= Code; c01b4614 2: 8b 42 70 mov0x70(%edx),%eax Code; c01b4617 5: 83 f8 01 cmp$0x1,%eax Code; c01b461a 8: 74 0a je 14 <_EIP+0x14> c01b4626 Code; c01b461c a: ff 4a 70 decl 0x70(%edx) Code; c01b461f d: 0f 94 c0 sete %al Code; c01b4622 10: 84 c0 test %al,%al Code; c01b4624 12: 74 09 je 1d <_EIP+0x1d> c01b462f Kernel panic: Aiee, killing interrupt handler! kernel BUG at sched.c:709! invalid operand: - 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/
Re: ATAPI Tape Driver Failure in Kernel 2.4.4, More
Mike Dresser wrote: > Mark Bratcher wrote: > >> >> This all works OK in kernel 2.2.17. But it fails in 2.4.4. >> > hdd: HP COLORADO 20GB, ATAPI TAPE drive > > I did my own playing with 2.4.x on the 14gb model of this tape drive, all i've >managed > to do is be able to write to the tape, but not read from it. Even in 2.2.x, putting >the > IDE patches in, breaks it. Apparently the HP's aren't completely ATAPI compatible I can write my HP 20GB drive with ide-tape. For restores I use ide-scsi. Its a bit of a hack but does work around the problem. Ed Tomlinson <[EMAIL PROTECTED]> - 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/
IDE DMA timeouts and reiserfs stability
Hi, I am using 2.4.5-pre1. Over the course of the last two weeks I have had DMA timeouts occur twice. Both times corrupted my fs. While this is not ideal, its not unexpected as things stand now. I have seen at least three other reports on lkml about errors of this type - suspect that 2.4's ide is a little fragile in some corner cases... Contrary to normal practice, after an IO error and fsck is a very wise thing to do. Can we automate this process. ie can reiserfs detect that it has experienced IO error(s) and set fsck required bits (two bits) in the SB? It would also be nice to be able to manually set these bits. This way a script could be triggered at boot (from initrd for those of us with reiserfs boot disks) to do something like this reiserfsck -a this should check each FS an does a --check when the bits are set to 01. It changes the SB bits as follows (logging to 01.log) 00 - fs is ok 10 - fix-fixable run required (logging to 10.log) 11 - rebuild-tree required (logging to 11.log) writing those logs could be a bit of a catch 22... then the script would call reiserfsck -a again to do the work (if required) and ask if its ok to do the fix-fixable or rebuild-tree Think reiserfsck is getting good enough for this, and it would probably avoid many of the problem currently popping up on the list. Thoughts? Ed Tomlinson <[EMAIL PROTECTED]> PS. Chris, with the fix you supplied for LVM, snapshots work 100% of the time when I put them on hda or hde and fail 100% on hdg... - 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/
Re: 2.6.19-rc6-mm2
Andrew, I booted without the video and vga settings with earlyprintk=vga and got output. The kenerl was complaining about a crc error. Checking the patch list I found: crc32-replace-bitreverse-by-bitrev32.patch reversing this patch fixes booting here. Please do not push this on - it breaks amd64 here. Thanks Ed Tomlinson On Thursday 30 November 2006 08:03, Ed Tomlinson wrote: > On Wednesday 29 November 2006 23:10, Randy Dunlap wrote: > > On Wed, 29 Nov 2006 22:42:20 -0500 Ed Tomlinson wrote: > > > > > On Tuesday 28 November 2006 05:02, Andrew Morton wrote: > > > > > > > Will appear eventually at > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/ > > > > > > This kernel does not boot here. It does not get far enough to post > > > anything to my serial console. > > > > Have you tried using "earlyprintk=..." to see if it produces any > > more output? > > Nothing is displayed by earlyprintk. I also added it to the rc5-mm2 boot to > verify it. The messages > displayed were the same as below... > > Thanks > Ed > > > > The last booted kernel here is 19-rc5-mm2. Grub is used to boot, here > > > is the starting log > > > of rc5-mm2 build is UP AMD64: > > > > > > [0.00] Linux version 2.6.19-rc5-mm2 ([EMAIL PROTECTED]) (gcc > > > version 4.1.1 (Gentoo 4.1.1-r1)) #1 PREEM6 > > > [0.00] Command line: root=/dev/sda3 vga=0x318 > > > video=vesafb:ywrap,mtrr:3 console=tty0 console=tty1 > > > [0.00] BIOS-provided physical RAM map: > > > [0.00] BIOS-e820: - 0009f800 (usable) > > > [0.00] BIOS-e820: 0009f800 - 000a (reserved) > > > [0.00] BIOS-e820: 000f - 0010 (reserved) > > > [0.00] BIOS-e820: 0010 - 3fff (usable) > > > [0.00] BIOS-e820: 3fff - 3fff3000 (ACPI NVS) > > > [0.00] BIOS-e820: 3fff3000 - 4000 (ACPI data) > > > [0.00] BIOS-e820: fec0 - fec01000 (reserved) > > > [0.00] BIOS-e820: fee0 - fef0 (reserved) > > > [0.00] BIOS-e820: fefffc00 - ff00 (reserved) > > > [0.00] BIOS-e820: - 0001 (reserved) > > > [0.00] end_pfn_map = 1048576 > > > [0.00] DMI 2.2 present. > > > [0.00] Zone PFN ranges: > > > [0.00] DMA 0 -> 4096 > > > [0.00] DMA324096 -> 1048576 > > > [0.00] Normal1048576 -> 1048576 > > > [0.00] early_node_map[2] active PFN ranges > > > [0.00] 0:0 -> 159 > > > [0.00] 0: 256 -> 262128 > > > [0.00] Nvidia board detected. Ignoring ACPI timer override. > > > [0.00] ACPI: PM-Timer IO Port: 0x4008 > > > [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) > > > [0.00] Processor #0 (Bootup-CPU) > > > [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) > > > [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) > > > [0.00] IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 > > > [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > > > [0.00] ACPI: BIOS IRQ0 pin2 override ignored. > > > [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > > > [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high > > > edge) > > > [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high > > > edge) > > > [0.00] Setting APIC routing to flat > > > [0.00] Using ACPI (MADT) for SMP configuration information > > > [0.00] Nosave address range: 0009f000 - 000a > > > [0.00] Nosave address range: 000a - 000f > > > [0.00] Nosave address range: 000f - 0010 > > > [0.00] Allocating PCI resources starting at 5000 (gap: > > > 4000:bec0) > > > [0.00] Built 1 zonelists. Total pages: 257320 > > > [0.00] Kernel command line: root=/dev/sda3 vga=0x318 > > > video=vesafb:ywrap,mtrr:3 console=tty0 cons1 > > > [0.00] Initializing CPU#0 > > > [0.00] PID hash
Re: 2.6.19-rc6-mm2
On Friday 01 December 2006 19:32, Andrew Morton wrote: > On Fri, 1 Dec 2006 19:33:21 -0500 > Ed Tomlinson <[EMAIL PROTECTED]> wrote: > > > I booted without the video and vga settings with earlyprintk=vga and got > > output. The > > kenerl was complaining about a crc error. Checking the patch list I found: > > > > crc32-replace-bitreverse-by-bitrev32.patch > > > > reversing this patch fixes booting here. > > Odd that you're the only person seeing this - could be a miscompile? I recompiled four times. The only change the last time was to reverse the above patch. I am using gcc is 4.1.1 (gentoo 4.1.1-r1). > What was the error message, exactly? I am not sure of the exact text. Basicly the loader loaded the kernel, a crc error was reported, then the kernel halted. I am using grub, gcc 4.1.1 (Gentoo 4.1.1-r1). - 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/
Re: 2.6.19-rc6-mm2
On Friday 01 December 2006 23:09, Akinobu Mita wrote: > On Fri, Dec 01, 2006 at 10:19:00PM -0500, Ed Tomlinson wrote: > > On Friday 01 December 2006 19:32, Andrew Morton wrote: > > > On Fri, 1 Dec 2006 19:33:21 -0500 > > > Ed Tomlinson <[EMAIL PROTECTED]> wrote: > > > > > > > I booted without the video and vga settings with earlyprintk=vga and > > > > got output. The > > > > kenerl was complaining about a crc error. Checking the patch list I > > > > found: > > > > > > > > crc32-replace-bitreverse-by-bitrev32.patch > > > > > > > > reversing this patch fixes booting here. > > > > > > Odd that you're the only person seeing this - could be a miscompile? > > > > I recompiled four times. The only change the last time was to reverse the > > above patch. I am using > > gcc is 4.1.1 (gentoo 4.1.1-r1). > > > > Can you try build and boot with that patch again? > I expected there is not any logical changes in that patch. So I want to > make sure it. I rebuilt twice. Once after just appling the patch (eg no make clean) and once with a make clean. Both kernels booted fine. No idea what triggered the crc problems above... Sorry for the noise, Ed - 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/
Re: [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems
On Wednesday 13 December 2006 12:47, Nikolai Joukov wrote: > We have designed a new stackable file system that we called RAIF: > Redundant Array of Independent Filesystems Do you have a function similar to an an EMC cloneset? Basicily a cloneset tracks what has changed in both the source and target luns (drives). When one updates the cloneset the target is made identical to the source. Its a great way to do backups. Its an important feature to be able to write to the target drives. I would love to see this working at a filesystem level. Thanks Ed Tomlinson - 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/
Re: [ANNOUNCE] RAIF: Redundant Array of Independent Filesystems
On Friday 15 December 2006 15:11, Nikolai Joukov wrote: > > On Wednesday 13 December 2006 12:47, Nikolai Joukov wrote: > > > We have designed a new stackable file system that we called RAIF: > > > Redundant Array of Independent Filesystems > > > > Do you have a function similar to an an EMC cloneset? Basicily a cloneset > > tracks what has changed in both the source and target luns (drives). When > > one > > updates the cloneset the target is made identical to the source. Its a > > great > > way to do backups. Its an important feature to be able to write to the > > target drives. > > I would love to see this working at a filesystem level. > > Well, if you mount RAIF over your file system and a for-backups file > system, RAIF can replicate the files on both of them automatically. I > guess that's what you need. Yes and no. The idea behind the cloneset is that most of the blocks (or files) do not change in either source or target. This being the case its only necessary to update the changed elements. This means updates are incremental. Once the system has figured out what it needs to update its usable and if you access an element that should be updated you will see the correctly updated version - even though backgound resyncing is still in progress. This type of logic is great for backups. Thanks Ed Tomlinson - 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/
Re: 2.6.19-rc6-mm2
On Tuesday 28 November 2006 05:02, Andrew Morton wrote: > Will appear eventually at > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/ This kernel does not boot here. It does not get far enough to post anything to my serial console. The last booted kernel here is 19-rc5-mm2. Grub is used to boot, here is the starting log of rc5-mm2 build is UP AMD64: [0.00] Linux version 2.6.19-rc5-mm2 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo 4.1.1-r1)) #1 PREEM6 [0.00] Command line: root=/dev/sda3 vga=0x318 video=vesafb:ywrap,mtrr:3 console=tty0 console=tty1 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f800 (usable) [0.00] BIOS-e820: 0009f800 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3fff (usable) [0.00] BIOS-e820: 3fff - 3fff3000 (ACPI NVS) [0.00] BIOS-e820: 3fff3000 - 4000 (ACPI data) [0.00] BIOS-e820: fec0 - fec01000 (reserved) [0.00] BIOS-e820: fee0 - fef0 (reserved) [0.00] BIOS-e820: fefffc00 - ff00 (reserved) [0.00] BIOS-e820: - 0001 (reserved) [0.00] end_pfn_map = 1048576 [0.00] DMI 2.2 present. [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] DMA324096 -> 1048576 [0.00] Normal1048576 -> 1048576 [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 -> 159 [0.00] 0: 256 -> 262128 [0.00] Nvidia board detected. Ignoring ACPI timer override. [0.00] ACPI: PM-Timer IO Port: 0x4008 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: BIOS IRQ0 pin2 override ignored. [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) [0.00] Setting APIC routing to flat [0.00] Using ACPI (MADT) for SMP configuration information [0.00] Nosave address range: 0009f000 - 000a [0.00] Nosave address range: 000a - 000f [0.00] Nosave address range: 000f - 0010 [0.00] Allocating PCI resources starting at 5000 (gap: 4000:bec0) [0.00] Built 1 zonelists. Total pages: 257320 [0.00] Kernel command line: root=/dev/sda3 vga=0x318 video=vesafb:ywrap,mtrr:3 console=tty0 cons1 [0.00] Initializing CPU#0 [0.00] PID hash table entries: 4096 (order: 12, 32768 bytes) Any ideas what I should try or suggestions on patches to remove/try. Thanks Ed - 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/
Re: 2.6.19-rc6-mm2
On Wednesday 29 November 2006 23:10, Randy Dunlap wrote: > On Wed, 29 Nov 2006 22:42:20 -0500 Ed Tomlinson wrote: > > > On Tuesday 28 November 2006 05:02, Andrew Morton wrote: > > > > > Will appear eventually at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/ > > > > This kernel does not boot here. It does not get far enough to post > > anything to my serial console. > > Have you tried using "earlyprintk=..." to see if it produces any > more output? Nothing is displayed by earlyprintk. I also added it to the rc5-mm2 boot to verify it. The messages displayed were the same as below... Thanks Ed > > The last booted kernel here is 19-rc5-mm2. Grub is used to boot, here is > > the starting log > > of rc5-mm2 build is UP AMD64: > > > > [0.00] Linux version 2.6.19-rc5-mm2 ([EMAIL PROTECTED]) (gcc > > version 4.1.1 (Gentoo 4.1.1-r1)) #1 PREEM6 > > [0.00] Command line: root=/dev/sda3 vga=0x318 > > video=vesafb:ywrap,mtrr:3 console=tty0 console=tty1 > > [0.00] BIOS-provided physical RAM map: > > [0.00] BIOS-e820: - 0009f800 (usable) > > [0.00] BIOS-e820: 0009f800 - 000a (reserved) > > [0.00] BIOS-e820: 000f - 0010 (reserved) > > [0.00] BIOS-e820: 0010 - 3fff (usable) > > [0.00] BIOS-e820: 3fff - 3fff3000 (ACPI NVS) > > [0.00] BIOS-e820: 3fff3000 - 4000 (ACPI data) > > [0.00] BIOS-e820: fec0 - fec01000 (reserved) > > [0.00] BIOS-e820: fee0 - fef0 (reserved) > > [0.00] BIOS-e820: fefffc00 - ff00 (reserved) > > [0.00] BIOS-e820: - 0001 (reserved) > > [0.00] end_pfn_map = 1048576 > > [0.00] DMI 2.2 present. > > [0.00] Zone PFN ranges: > > [0.00] DMA 0 -> 4096 > > [0.00] DMA324096 -> 1048576 > > [0.00] Normal1048576 -> 1048576 > > [0.00] early_node_map[2] active PFN ranges > > [0.00] 0:0 -> 159 > > [0.00] 0: 256 -> 262128 > > [0.00] Nvidia board detected. Ignoring ACPI timer override. > > [0.00] ACPI: PM-Timer IO Port: 0x4008 > > [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) > > [0.00] Processor #0 (Bootup-CPU) > > [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) > > [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) > > [0.00] IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 > > [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > > [0.00] ACPI: BIOS IRQ0 pin2 override ignored. > > [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > > [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) > > [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) > > [0.00] Setting APIC routing to flat > > [0.00] Using ACPI (MADT) for SMP configuration information > > [0.00] Nosave address range: 0009f000 - 000a > > [0.00] Nosave address range: 000a - 000f > > [0.00] Nosave address range: 000f - 0010 > > [0.00] Allocating PCI resources starting at 5000 (gap: > > 4000:bec0) > > [0.00] Built 1 zonelists. Total pages: 257320 > > [0.00] Kernel command line: root=/dev/sda3 vga=0x318 > > video=vesafb:ywrap,mtrr:3 console=tty0 cons1 > > [0.00] Initializing CPU#0 > > [0.00] PID hash table entries: 4096 (order: 12, 32768 bytes) > > > > Any ideas what I should try or suggestions on patches to remove/try. > > > > Thanks > > Ed > > --- > ~Randy > - > 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/ > > - 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/
Re: [RFC PATCH 0/5 v2] Convert all tasklets to workqueues V2
Hi, Applied this to 2.6.21-5 along with an older version of dyntick and cfs v18, durring boot I got: [ 54.154077] hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb 81004ec55628 err -38 [ 54.154086] hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb 81004ec55628 err -38 [ 54.168147] BUG: at kernel/mutex.c:132 __mutex_lock_common() [ 54.170801] [ 54.170802] Call Trace: [ 54.175975] [] check_preempt_curr_fair+0x70/0x90 [ 54.178694] [] __mutex_lock_slowpath+0x6f/0x200 [ 54.181417] [] mutex_lock+0x19/0x20 [ 54.184165] [] flush_workqueue+0x31/0x50 [ 54.186975] [] tasklet_disable+0x15/0x20 [ 54.189829] [] :bluetooth:hci_cc_host_ctl+0x17f/0x240 [ 54.192767] [] :bluetooth:hci_event_packet+0x139c/0x1560 [ 54.195712] [] :bluetooth:hci_send_to_sock+0x134/0x180 [ 54.198657] [] :bluetooth:hci_rx_task+0x9f/0x270 [ 54.201588] [] work_tasklet_exec+0x0/0x50 [ 54.204473] [] work_tasklet_exec+0x3c/0x50 [ 54.207282] [] run_workqueue+0x94/0x130 [ 54.210032] [] worker_thread+0x149/0x190 [ 54.212781] [] default_wake_function+0x0/0x10 [ 54.215539] [] worker_thread+0x0/0x190 [ 54.218241] [] kthread+0xd3/0x110 [ 54.220880] [] child_rip+0xa/0x12 [ 54.223484] [] kthread+0x0/0x110 [ 54.226075] [] child_rip+0x0/0x12 Has this patch uncovered a problem in bluetooth or is it a problem with the patch? TIA, Ed Tomlinson On Friday 22 June 2007 14:20, Steven Rostedt wrote: > -- > > This is version 2 of the tasklet to workqueue conversion. > > Changes from version 1. > > - removed config option and simply replace the old implementation > with the work queue one (recommended by Ingo Molnar). > > - replaced clear_bit with test_and_clear_bit to avoid the race of > executing the tasklet function twice. (thanks to Oleg Nesterov > for pointing that out). > > - Removed most of the pr_debug prints. (Kept one) > (recommended by Ingo Molnar) > > - Removed call to softirq_init. > > - Added Author credit to Dipankar Sarma for the RCU tasklet to > softirq conversion. > > - Tested on my Powerbook to add another arch to the mix :-) > Funny that booting with this change was the first time that > the bcm43xx didn't get stuck for several seconds on bootup. > It's also one of the few drivers that use tasklet_disable_nosync. > So either this shows that the change fixed something, or that > it broke something (or was just a fluke). > > > -- Steve > > - > 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/ > > - 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/
Re: [patch] CFS scheduler, -v19
Hi, I run a java application at nice 15. Its been a background application here for as long as SD and CFS have been around. If I have a compile running at nice 0, with v19 java gets so little cpu that the the wrapper that runs to monitor it is timing out waiting for it to start. This is new in v19 - something in v19 is not meshing well with my mix of applications... Kernel is gentoo 2.6.22-r1 + cfs v19 How can I help to debug this? Ed Tomlinson On Friday 06 July 2007 13:33, Ingo Molnar wrote: > i'm pleased to announce release -v19 of the CFS scheduler patchset. > > The rolled-up CFS patch against today's -git kernel, v2.6.22-rc7, > v2.6.22-rc6-mm1, v2.6.21.5 or v2.6.20.14 can be downloaded from the > usual place: > > http://people.redhat.com/mingo/cfs-scheduler/ > > The biggest user-visible change in -v19 is reworked sleeper fairness: > it's similar in behavior to -v18 but works more consistently across nice > levels. Fork-happy workloads (like kernel builds) should behave better > as well. There are also a handful of speedups: unsigned math, 32-bit > speedups, O(1) task pickup, debloating and other micro-optimizations. - 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/
Re: [patch] CFS scheduler, -v19
On Monday 16 July 2007 05:17, Ingo Molnar wrote: > > * Ed Tomlinson <[EMAIL PROTECTED]> wrote: > > > I run a java application at nice 15. Its been a background > > application here for as long as SD and CFS have been around. If I > > have a compile running at nice 0, with v19 java gets so little cpu > > that the the wrapper that runs to monitor it is timing out waiting for > > it to start. This is new in v19 - something in v19 is not meshing > > well with my mix of applications... > > how much longer did the startup of the java app get relative to say v18? > > to debug this, could you check whether this problem goes away if you use > nice 10 (or nice 5) instead of nice 15? Ingo, It may take a day to two before I get to test this. I have had to revert to 2.6.21 - it seems that 22 triggers a stall here (21 also can trigger this but its harder)... Thanks Ed - 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/
Re: Renice X for cpu schedulers
On Thursday 19 April 2007 12:15, Mark Lord wrote: > Con Kolivas wrote: > > On Thursday 19 April 2007 23:17, Mark Lord wrote: > >> Con Kolivas wrote: > >> s go ahead and think up great ideas for other ways of metering out cpu > >> > >>> bandwidth for different purposes, but for X, given the absurd simplicity > >>> of renicing, why keep fighting it? Again I reiterate that most users of > >>> SD have not found the need to renice X anyway except if they stick to old > >>> habits of make -j4 on uniprocessor and the like, and I expect that those > >>> on CFS and Nicksched would also have similar experiences. > >> Just plain "make" (no -j2 or -j) is enough to kill interactivity > >> on my 2GHz P-M single-core non-HT machine with SD. > >> > >> But with the very first posted version of CFS by Ingo, > >> I can do "make -j2" no problem and still have a nicely interactive destop. > > > > Cool. Then there's clearly a bug with SD that manifests on your machine as > > it > > should not have that effect at all (and doesn't on other people's > > machines). > > I suggest trying the latest version which fixes some bugs. > > SD just doesn't do nearly as good as the stock scheduler, or CFS, here. > > I'm quite likely one of the few single-CPU/non-HT testers of this stuff. > If it should ever get more widely used I think we'd hear a lot more > complaints. amd64 UP here. SD with several makes running works just fine. Ed Tomlinson - 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/
