How VFS interacts with a file driver
Hi I am trying to implement a distributed file system. For that I write a file driver. I want to know the following things 1 . If I am writing a new file system, is it necessary to modify the existing structs including inode struct. 2 . If it is not needed, will a simple registration of the file system is needed to mount the file system More over I am new to this area. I am doing as my graduate project. I need someones help to crack the working of VFS Thanks in advance Blesson Paul Get free email and a permanent address at http://www.netaddress.com/?N=1 - 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: Getting FS access events
Linus Torvalds writes: > > On Sun, 13 May 2001, Richard Gooch wrote: > > > > Think about it:-) You need to generate prefetch accesses in ascending > > device bnum order. > > I seriously doubt it is worth it. > > Th ekernel will do the ordering for you anyway: that's what the > elevator is, and that's why you have a "prefetch" system call (to > avoid the synchronization that kills the elevator). And you'll end > up wanting to pre-fetch on virtual addresses, which implies that you > have to open the files: I doubt you want to have tons of files open > and try to get a "global" order. OK, provided the prefetch will queue up a large number of requests before starting the I/O. If there was a way of controlling when the I/O actually starts (say by having a START flag), that would be ideal, I think. > But sure, you can use bmap if you want. It would be interesting to > hear whether it makes much of a difference.. I doubt bmap() would make any difference if there is a way of controlling when the I/O starts. However, this still doesn't address the issue of indirect blocks. If the indirect block has a higher bnum than the data blocks it points to, you've got a costly seek. This is why I'm still attracted to the idea of doing this at the block device layer. It's easy to capture *all* accesses and then warm the buffer cache. So, why can't the page cache check if a block is in the buffer cache? > > Sure, this would work too. I'm a bit worried about the increased > > amount of traffic this will generate. > > No increased traffic. "path" is a pointer (to a dentry), ie 32 > bits. "ino" is at least 128 bits on some filesystems. You make for _less_ > data to save. > > > So on every page fault or read(2) call, we have to generate the full > > path from the dentry? Isn't that going to add a fair bit of overhead? > > You just save the dentry pointer. You do the path _later_, when > somebody reads it away from the /proc file. That opens up a nasty race: if the dentry is released before the pointer is harvested, you get a bogus pointer. > > I don't see the advantage of the prefetch(2) system call. It seems to > > me I can get the same effect by just making read(2) calls in another > > task. Of course, I'd need to use bmap() to generate the sort key, but > > I don't see why that's a bad thing. > > Try it. You won't be able to. "read()" is an inherently > synchronizing operation, and you cannot get _any_ overlap with > multiple reads, except for the pre-fetching that the kernel will do > for you anyway. How's that? It won't matter if read(2) synchronises, because I'll be issuing the requests in device bnum order. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [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] page_alloc.c fixes
Hi Linus,
The attached patch against 2.4.5-pre1 page_alloc.c fixes
the following things:
1) uses >= in __alloc_pages_limit(), so we can get 1 page
below the limit and tests like free_shortage() and
out_of_memory() can test for shortage with a simple '<'
... this should prevent subtle errors in the future
2) moved the 'z->pages_min + 8' test from __alloc_pages_limit()
to the first test in __alloc_pages, this should make the code
a bit more obvious (IMHO)
3) remove the wakeup tests for kswapd and bdflush from the start
of __alloc_pages(), these hardly do any more than eating CPU;
especially bdflush was in danger of being woken up with no work
to do; kswapd will be woken up as soon as the zones start hitting
z->pages_low, so that should be ok too
4) break the possible infinite loop and device driver hangs by not
looping in __alloc_pages() for higher-order allocations; that is,
we stop looping as soon as free_shortage() is reduced to 0, because
at that point we know the allocation fails due to memory fragmentation
and not due to free memory shortage
5) fix nr_free_buffer_pages() to not count highmem pages; this is needed
because highmem pages cannot be allocated as buffer memory and filling
up all of low memory with dirty buffers is "bad" for performance
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
--- linux-2.4.5-pre1/mm/page_alloc.c.orig Mon May 14 01:11:14 2001
+++ linux-2.4.5-pre1/mm/page_alloc.cMon May 14 01:42:49 2001
@@ -250,10 +250,10 @@
water_mark = z->pages_high;
}
- if (z->free_pages + z->inactive_clean_pages > water_mark) {
+ if (z->free_pages + z->inactive_clean_pages >= water_mark) {
struct page *page = NULL;
/* If possible, reclaim a page directly. */
- if (direct_reclaim && z->free_pages < z->pages_min + 8)
+ if (direct_reclaim)
page = reclaim_page(z);
/* If that fails, fall back to rmqueue. */
if (!page)
@@ -298,21 +298,6 @@
if (order == 0 && (gfp_mask & __GFP_WAIT))
direct_reclaim = 1;
- /*
-* If we are about to get low on free pages and we also have
-* an inactive page shortage, wake up kswapd.
-*/
- if (inactive_shortage() > inactive_target / 2 && free_shortage())
- wakeup_kswapd();
- /*
-* If we are about to get low on free pages and cleaning
-* the inactive_dirty pages would fix the situation,
-* wake up bdflush.
-*/
- else if (free_shortage() && nr_inactive_dirty_pages > free_shortage()
- && nr_inactive_dirty_pages >= freepages.high)
- wakeup_bdflush(0);
-
try_again:
/*
* First, see if we have any zones with lots of free memory.
@@ -328,7 +313,7 @@
if (!z->size)
BUG();
- if (z->free_pages >= z->pages_low) {
+ if (z->free_pages >= z->pages_min + 8) {
page = rmqueue(z, order);
if (page)
return page;
@@ -396,7 +381,7 @@
page = __alloc_pages_limit(zonelist, order, PAGES_MIN, direct_reclaim);
if (page)
return page;
-
+
/*
* Damn, we didn't succeed.
*
@@ -442,18 +427,20 @@
}
/*
* When we arrive here, we are really tight on memory.
+* Since kswapd didn't succeed in freeing pages for us,
+* we try to help it.
*
-* We try to free pages ourselves by:
-* - shrinking the i/d caches.
-* - reclaiming unused memory from the slab caches.
-* - swapping/syncing pages to disk (done by page_launder)
-* - moving clean pages from the inactive dirty list to
-*the inactive clean list. (done by page_launder)
+* Single page allocs loop until the allocation succeeds.
+* Multi-page allocs can fail due to memory fragmentation;
+* in that case we bail out to prevent infinite loops and
+* hanging device drivers ...
*/
if (gfp_mask & __GFP_WAIT) {
memory_pressure++;
- try_to_free_pages(gfp_mask);
- goto try_again;
+ if (!order || free_shortage()) {
+ try_to_free_pages(gfp_mask);
+
kmem_cache_init ()
Hi,
I was unable to understand the logic of the following sanity checks in
slab.c/kmem_cache_init ().
if (kmem_cache_diff(c_firstp,c_magic) != kmem_slab_diff(s_nextp,s_magic) ||
kmem_cache_diff(c_firstp,c_inuse) != kmem_slab_diff(s_nextp,s_inuse) ||
kmem_cache_offset(c_lastp) - ((unsigned long) kmem_slab_end((kmem_cache_t
*)NULL)) != kmem_slab_offset(s_prevp) || kmem_cache_diff(c_lastp,c_firstp) !=
kmem_slab_diff(s_prevp,s_nextp)) {
/** offsets to the magic are incorrect **/
}
can someone throw some light behind the above logic
Thanks
Amol
-
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: Getting FS access events
On Sun, 13 May 2001, Richard Gooch wrote: > > Think about it:-) You need to generate prefetch accesses in ascending > device bnum order. I seriously doubt it is worth it. Th ekernel will do the ordering for you anyway: that's what the elevator is, and that's why you have a "prefetch" system call (to avoid the synchronization that kills the elevator). And you'll end up wanting to pre-fetch on virtual addresses, which implies that you have to open the files: I doubt you want to have tons of files open and try to get a "global" order. But sure, you can use bmap if you want. It would be interesting to hear whether it makes much of a difference.. > > Why not just "path,pagenr" instead? You make your instrumentation save > > away the whole pathname, by just using the dentry pointer. Many > > filesystems don't even _have_ a "inum", so anything less doesn't work > > anyway. > > Sure, this would work too. I'm a bit worried about the increased > amount of traffic this will generate. No increased traffic. "path" is a pointer (to a dentry), ie 32 bits. "ino" is at least 128 bits on some filesystems. You make for _less_ data to save. > So on every page fault or read(2) call, we have to generate the full > path from the dentry? Isn't that going to add a fair bit of overhead? You just save the dentry pointer. You do the path _later_, when somebody reads it away from the /proc file. > I don't see the advantage of the prefetch(2) system call. It seems to > me I can get the same effect by just making read(2) calls in another > task. Of course, I'd need to use bmap() to generate the sort key, but > I don't see why that's a bad thing. Try it. You won't be able to. "read()" is an inherently synchronizing operation, and you cannot get _any_ overlap with multiple reads, except for the pre-fetching that the kernel will do for you anyway. And when it comes to IO and the elevator, overlap is where it matters. Sending out several tagged commands to the disk in one go. You'd have to have multiple processes doing the reads to get the same kind of performance. Much easier to do "prefetch()", when that's really what you want anyway. Remember, you'r enot interested in the data. You're just populating the cache. Linus - 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.4 kernel freeze for unknown reason
On 13 May 2001, Christoph Rohland wrote: > Hi Mike, > > On Sat, 12 May 2001, Mike Galbraith wrote: > > Why do I not see this behavior with a heavy swap throughput test > > load? It seems decidedly odd to me that swapspace should remain > > allocated on other folks lightly loaded boxen given that my heavily > > loaded box does release swapspace quite regularly. What am I > > missing? > > Are you using a database or something other which mostly uses shared > mem/tmpfs? This does reclaim swap space on swap in. No, just doing parallel kernel builds. -Mike - 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: Getting FS access events
Rik van Riel writes: > On Sun, 13 May 2001, Richard Gooch wrote: > > Larry McVoy writes: > > > > Ha. For once you're both wrong but not where you are thinking. One > > > of the few places that I actually hacked Linux was for exactly this > > > - it was in the 0.99 days I think. I saved the list of I/O's in a > > > file and filled the buffer cache with them at next boot. It > > > actually didn't help at all. > > > > Maybe you did something wrong :-) > > How about "the data loads got instrumented, but the metadata > loads which caused over half of the disk seeks didn't" ? > > (just a wild guess ... if it turns out to be true we may want > to look into doing agressive readahead on inode blocks ;)) Caching metadata is definately part of my cunning plan. I'd like to think that once Al's metadata-in-page-cache patches go in, we'll get that for free. However, that will still leave indirect blocks unordered. I don't see a clean way of fixing that. Which is why doing things at the block device layer has it's attractions (except it doesn't work). Hm. Is there a reason why the page cache can't see if a a block is in the block cache, and read it from there first? Regards, Richard Permanent: [EMAIL PROTECTED] Current: [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/
Minor nit to pick
Hi, I'd like to fix a minor nit I've had with linux for a while, however I need a bit more information, and would like to know if a patch would be accepted. After running make menuconfig (and it's friends) you get told to type "make bzImage" which is only right for i386, and IMHO should be changed to be arch dependant. Has anyone done this, does anyone have a recommendation as to how, or failing both those two, can I get a complete list of the correct "make blah" lines for each arch? Thanks Nick - 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] out_of_memory() fix
Hi Linus,
instead of walking the whole swap bitmap, out_of_memory()
might just as well check the nr_swap_pages variable which
is used by __get_swap_page() ...
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
--- linux-2.4.5-pre1/mm/oom_kill.c.orig Mon May 14 01:03:33 2001
+++ linux-2.4.5-pre1/mm/oom_kill.c Mon May 14 01:06:56 2001
@@ -191,7 +191,6 @@
*/
int out_of_memory(void)
{
- struct sysinfo swp_info;
/* Enough free memory? Not OOM. */
if (nr_free_pages() > freepages.min)
@@ -201,8 +200,7 @@
return 0;
/* Enough swap space left? Not OOM. */
- si_swapinfo(_info);
- if (swp_info.freeswap > 0)
+ if (nr_swap_pages > 0)
return 0;
/* Else... */
-
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] filemap.c fixes
Hi Linus,
here are a filemap.c fix and a slight addition:
1) __find_page_nolock should only set the referenced bit
on an active page, otherwise a number of subsequent
reads from the same page within one page scan interval
can SEVERELY mess up page aging to the disadvantage of
the other pages in the system ...
just setting the referenced bit on the page makes the
aging a lot fairer
2) in drop_behind() we first increase the page age and
will then proceed to deactivate the page again; better
have a simpler help function for this ... note that this
help function could also be used for eg. ->writepage()
write clustering code
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
--- linux-2.4.5-pre1/mm/filemap.c.orig Mon May 14 00:55:53 2001
+++ linux-2.4.5-pre1/mm/filemap.c Mon May 14 00:56:03 2001
@@ -299,13 +299,14 @@
break;
}
/*
-* Touching the page may move it to the active list.
-* If we end up with too few inactive pages, we wake
-* up kswapd.
+* Mark the page referenced, moving inactive pages to the
+* active list.
*/
- age_page_up(page);
- if (inactive_shortage() > inactive_target / 2 && free_shortage())
- wakeup_kswapd();
+ if (!PageActive(page))
+ activate_page(page);
+ else
+ SetPageReferenced(page);
+
not_found:
return page;
}
@@ -783,8 +784,7 @@
*/
spin_lock(_lock);
while (--index >= start) {
- hash = page_hash(mapping, index);
- page = __find_page_nolock(mapping, index, *hash);
+ page = __find_page_simple(mapping, index);
if (!page)
break;
deactivate_page(page);
-
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] balance_dirty_state() fix
Hi Linus,
The following patch fixes a problem where bdflush eats too
much cpu time without getting work done; the problem is that
calls to page_launder() don't achieve anything in the short
term and may not even achieve anything long-term because we
may just be short on inactive pages.
In both of these cases it's better to just let bdflush stop
eating CPU and have the system do something useful instead.
Please apply.
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
--- linux-2.4.4/fs/buffer.c.origMon May 14 00:36:15 2001
+++ linux-2.4.4/fs/buffer.c Mon May 14 00:36:28 2001
@@ -1034,7 +1034,6 @@
int balance_dirty_state(kdev_t dev)
{
unsigned long dirty, tot, hard_dirty_limit, soft_dirty_limit;
- int shortage;
dirty = size_buffers_type[BUF_DIRTY] >> PAGE_SHIFT;
tot = nr_free_buffer_pages();
@@ -1049,16 +1048,6 @@
return 1;
return 0;
}
-
- /*
-* If we are about to get low on free pages and
-* cleaning the inactive_dirty pages would help
-* fix this, wake up bdflush.
-*/
- shortage = free_shortage();
- if (shortage && nr_inactive_dirty_pages > shortage &&
- nr_inactive_dirty_pages > freepages.high)
- return 0;
return -1;
}
-
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: skb->truesize > sk->rcvbuf == Dropped packets
[EMAIL PROTECTED] writes: > > > Any suggestions on heuristics for this ? > > Not to set rcvbuf to ridiculously low values. The best variant is not > to touch SO_*BUF options at all. Hmmm... I don't see how not touching buffer values can solve his problem at all. His MTU is really HUGE, and in this case 300 byte packet eats 10k or so space in receive buffer. I doubt our buffer size tuning algorithms can cope with this. Really, copy threshold in driver just must be choosen carefully. Later, David S. Miller [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: Getting FS access events
On Sun, 13 May 2001, Richard Gooch wrote: > Larry McVoy writes: > > Ha. For once you're both wrong but not where you are thinking. One > > of the few places that I actually hacked Linux was for exactly this > > - it was in the 0.99 days I think. I saved the list of I/O's in a > > file and filled the buffer cache with them at next boot. It > > actually didn't help at all. > > Maybe you did something wrong :-) How about "the data loads got instrumented, but the metadata loads which caused over half of the disk seeks didn't" ? (just a wild guess ... if it turns out to be true we may want to look into doing agressive readahead on inode blocks ;)) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - 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: Enable IP PNP for 2.4.4-ac8
Eric W. Biederman writes: > Mostly I like the situation where I can compile it in and turn it on > when I need it, instead of having to do thing differently if it is > compiled in or not. > > ip=on is all it really takes. This is the main reason I like the current 2.4.x behavior. I hate config options that change how the core of the kernel boot makes decisions. Things like "where is root", "what is my network address or where do I get that information" have no reasonable default. This is why the command line args are there. If you want a kernel which automatically does "foo", you have several options already by which to do this: 1) Many platforms allow you to store a boot comand line in the firmware (Sparc, several MIPS, PPC, etc.) 2) Failing #1, you can add a default prefix/postfix to the kernel command line at build time if you wish, just add some simple variable to the toplevel Makefile and have init/main.c frob this thing onto the kernel command line string after initially fetching it. Really, H. J., you are asking for a static command line feature. That's cool, so add it :-) Later, David S. Miller [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: Not a typewriter
On 05/13/2001 at 08:03:30 PM Horst von Brand <[EMAIL PROTECTED]> wrote: >The old C compiler/old Unix linker guaranteed 6 chars in an external symbol >name only, and C functions got an underscore prepended: _creat. I guess >this is the reason for this wart. As to why 6 chars only, I'd guess some >data structure in the linker was laid out that way. Machines had a few >dozen Kbs of RAM then, space was precious. I've always thought it was just an arbitrary decision, based on the general Unix custom of shortnening names by removing vowels, especially since Ken Thompson later said he'd spell it "create" if he had it to do over again. But your explanation sounds more likely. I really should have thought of this, since I used to run into problems with non-unique names under the Minix linker (which, IIRC, had the same 6 char limit). - 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: Enable IP PNP for 2.4.4-ac8
H . J . Lu writes: > Have you tried ramdisk on diskless ... sparc .. booting > over network? I know that sparc works fine, what is your point though? All platforms ought to work with ramdisks just fine, in fact. Later, David S. Miller [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: 2.4.5-pre1, iproute2 - IPv6
Piotr Wysocki writes: > ll_proto.c:36: `ETH_P_ECHO' undeclared here (not in a function) > ll_proto.c:36: initializer element is not constant > ll_proto.c:36: (near initialization for `llproto_names[1].id') Just simply remove references to these (bogus, that's why they were removed from the kernel headers) ETH_* constants in the iproute sources. Alexey should be making a new release sometime soon now that he is back. Later, David S. Miller [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: IPv6: the same address can be added multiple times
Pekka Savola writes: > But it still looks dirty. Also, it's easier to add it many times by > mistake; IPv4 addresses do not allow this. And as you have to remove them > N times too, this may create even more confusion. There is this growing (think growing as in "fungus") set of thinking that just because something can be misused, this is an argument against it even existing. I think this is wrong. I'm seeing it a lot, especially on this list, and it's becomming a real concern at least to me. Most of the time the argument goes like: 1: "Well, we allow this because you can do usefull things X Y and Z as a result." 2: "Yeah, but this also lets you do stupid things like A B and C." translation: "It hurts when I do A B or C" Most people know the appropriate response for the translation of #2 ;-) Later, David S. Miller [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: Getting FS access events
Larry McVoy writes: > On Sun, May 13, 2001 at 06:32:02PM -0700, Linus Torvalds wrote: > > > Hi, Linus. I've been thinking more about trying to warm the page > > > cache with blocks needed by the bootup process. What is currently > > > missing is (AFAIK) a mechanism to find out what inodes and blocks have > > > been accessed. Sure, you can use bmap() to convert from file block to > > > device block, but first you need to figure out the file blocks > > > accessed. I'd like to find out what kind of patch you'd accept to > > > provide the missing functionality. > > > > Why would you use bmap() anyway? You CANNOT warm up the page cache with > > the physical map nr as discussed. So there's no real point in using > > bmap() at any time. > > Ha. For once you're both wrong but not where you are thinking. One > of the few places that I actually hacked Linux was for exactly this > - it was in the 0.99 days I think. I saved the list of I/O's in a > file and filled the buffer cache with them at next boot. It > actually didn't help at all. Maybe you did something wrong :-) Seriously, maybe you're right, and maybe not. I'd like to find out, and having the infrastructure to get FS access events will help in that (as well as your preferred approach: see below). If I am digging into a rathole, I'll do it with my eyese open ;-) > I don't remember why, maybe it was back so long ago that I didn't > have the memory, but I think it was more subtle than that. It's > basically a queuing problem and my instincts were wrong, I thought > if I could get all the data in there then things would go faster. > If you think through all the stuff going on during a boot it doesn't > really work that way. Well, on my machines anyway, the discs rattle an awful lot during bootup. Not just little adjacent seeks, but big, partition crossing seeks. > Anyway, a _much_ better thing to do would be to have all this data > laid out contig, then slurp in all the blocks in on I/O and then let > them get turned into files. This has been true for the last 30 > years and people still don't do it. We're actually moving in this > direction with BitKeeper, in the future, large numbers of small > files will be stored in one big file and extracted on demand. Then > we do one I/O to get all the related stuff. Yeah, we need a decent unfragmenter. We can do that now with bmap(). But to speed up boots, for example, we need to lay all the inodes that are accessed during boot in one contiguous chunk on the disc. Again, we need to know which files are being accessed to know that. /proc/fsaccess would tell us that. The down side of just relying on contiguous files is that some files (especially bloated C libraries) are not fully used. I would not be at all surprised if more than 75% of glibc is not (or rarely) used. There's a lot of stuff in there that isn't used very often. However, a *refragmenter* might be interesting. Find out which blocks in which files are actually used during boot, and lay just those out in a contiguous section. *That* would smoke! Regards, Richard Permanent: [EMAIL PROTECTED] Current: [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: Getting FS access events
Linus Torvalds writes: > > On Sun, 13 May 2001, Richard Gooch wrote: > > > > Hi, Linus. I've been thinking more about trying to warm the page > > cache with blocks needed by the bootup process. What is currently > > missing is (AFAIK) a mechanism to find out what inodes and blocks have > > been accessed. Sure, you can use bmap() to convert from file block to > > device block, but first you need to figure out the file blocks > > accessed. I'd like to find out what kind of patch you'd accept to > > provide the missing functionality. > > Why would you use bmap() anyway? You CANNOT warm up the page cache > with the physical map nr as discussed. So there's no real point in > using bmap() at any time. Think about it:-) You need to generate prefetch accesses in ascending device bnum order. So the bmap() is there to tell you those device bnums. You'd still prefetch using file bnums, the the *ordering* is done based on device bnum. In fact, once the list is sorted, you can chuck out the device bnums. You only need to store inum/path and file bnum in the database. > > One approach would be to create a new ioctl(2) for a FS that would > > read out inum,bnum pairs. > > Why not just "path,pagenr" instead? You make your instrumentation save > away the whole pathname, by just using the dentry pointer. Many > filesystems don't even _have_ a "inum", so anything less doesn't work > anyway. Sure, this would work too. I'm a bit worried about the increased amount of traffic this will generate. > Example acceptable approach: > > - save away full dentry and page number. Don't make it an ioctl. Think >"profiling" - this is _exactly_ the same thing, and profiling uses a > (a) command line argument to turn it on > (b) /proc/profile >(and because you have the full pathname, you should just make the dang >/proc/fsaccess file be ASCII) So on every page fault or read(2) call, we have to generate the full path from the dentry? Isn't that going to add a fair bit of overhead? Remember, we want to do this on every boot (to keep the database as up-to-date as possible). > - add a "prefetch()" system call that does all the same things >"read()" does, but doesn't actually wait for (or transfer) the >data. Basically just a read-ahead thing. So you'd basically end up >doing > > foreach (filename in /proc/fsaccess) > fd = open(filename); > foreach (sorted pagenr for filename in /proc/fsaccess) > prefetch(fd, pagenr); > end > end I don't see the advantage of the prefetch(2) system call. It seems to me I can get the same effect by just making read(2) calls in another task. Of course, I'd need to use bmap() to generate the sort key, but I don't see why that's a bad thing. > Forget about all these crappy "ioctl" ideas. Basic rule of thumb: if > you think an ioctl is a good idea, you're (a) being stupid and (b) > thinking wrong and (c) on the wrong track. Don't hold back now. Tell us what you really think :-) > And notice how there's not a single bmap anywhere, and not a single > "raw device open" anywhere. I don't mind the /proc/fsaccess approach, I'm just worried about the overhead of doing the denty->pathname conversions on each fault/read. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [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: Getting FS access events
On Sun, May 13, 2001 at 06:32:02PM -0700, Linus Torvalds wrote: > > Hi, Linus. I've been thinking more about trying to warm the page > > cache with blocks needed by the bootup process. What is currently > > missing is (AFAIK) a mechanism to find out what inodes and blocks have > > been accessed. Sure, you can use bmap() to convert from file block to > > device block, but first you need to figure out the file blocks > > accessed. I'd like to find out what kind of patch you'd accept to > > provide the missing functionality. > > Why would you use bmap() anyway? You CANNOT warm up the page cache with > the physical map nr as discussed. So there's no real point in using > bmap() at any time. Ha. For once you're both wrong but not where you are thinking. One of the few places that I actually hacked Linux was for exactly this - it was in the 0.99 days I think. I saved the list of I/O's in a file and filled the buffer cache with them at next boot. It actually didn't help at all. I don't remember why, maybe it was back so long ago that I didn't have the memory, but I think it was more subtle than that. It's basically a queuing problem and my instincts were wrong, I thought if I could get all the data in there then things would go faster. If you think through all the stuff going on during a boot it doesn't really work that way. Anyway, a _much_ better thing to do would be to have all this data laid out contig, then slurp in all the blocks in on I/O and then let them get turned into files. This has been true for the last 30 years and people still don't do it. We're actually moving in this direction with BitKeeper, in the future, large numbers of small files will be stored in one big file and extracted on demand. Then we do one I/O to get all the related stuff. Dave Hitz at NetApp is about the only guy I know who really gets this, Daniel Phillips may also get it, he's certainly thinking about it. Lots of little I/O's == bad, one big I/O == good. Work through the numbers and it starts to look like you'd never want to do less than a 1MB I/O, probably not less than a 4MB I/O. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - 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: Enable IP PNP for 2.4.4-ac8
On Sun, May 13, 2001 at 07:24:31PM -0600, Eric W. Biederman wrote: > > I agree it isn't intuitive, and if nfsroot=xxx is specified it should > probably turn on if there is missing information. > > But if you have to select the command line anyway > > Mostly I like the situation where I can compile it in and turn it on > when I need it, instead of having to do thing differently if it is > compiled in or not. > In fact, I like the idea. But passing nfsroot=xxx to kernel doesn't imply "ip=on" is very annoying. My setup worked fine with 2.4.4. It took me a while to figure out why it didn't work with 2.4.4-ac8. > > Have you tried > > ramdisk on diskless alpha, arm, m68k, mips, ppc, sh, sparc, booting > > over network? > > First the booting situation on linux with respect to multiple platform > sucks. We pass parameters in weird ways on every platform. The command > line is the only thing that stays mostly the same. I'm looking at what > it takes to clean that up, so we can have multiplatform bootloaders. I don't think we have total control over how to boot over network on all platforms. On some platforms, you may only load kernel over the network and run from it. > > I have implemented what it takes to attach a ramdisk, and if you can > boot an arbitrary kernel it isn't hard to have a program that attaches > a ramdisk. > > Now although I believe this is the right direction to go, you will > notice I ported the dhcp IP auto configuration from 2.2.19 to to 2.4.x > Buying a little more time to get this working. Thanks. I appreciate it. H.J. - 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: Not a typewriter
>why creat doesn't end in an "e;" and so forth. I tell the Some time back, Ken Thompson was asked, if he had it to do over again, what changes he would make to Unix. The only thing he could think of: spell it "create()". -- /Jonathan Lundell. - 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: Getting FS access events
On Sun, 13 May 2001, Richard Gooch wrote: > > Hi, Linus. I've been thinking more about trying to warm the page > cache with blocks needed by the bootup process. What is currently > missing is (AFAIK) a mechanism to find out what inodes and blocks have > been accessed. Sure, you can use bmap() to convert from file block to > device block, but first you need to figure out the file blocks > accessed. I'd like to find out what kind of patch you'd accept to > provide the missing functionality. Why would you use bmap() anyway? You CANNOT warm up the page cache with the physical map nr as discussed. So there's no real point in using bmap() at any time. > One approach would be to create a new ioctl(2) for a FS that would > read out inum,bnum pairs. Why not just "path,pagenr" instead? You make your instrumentation save away the whole pathname, by just using the dentry pointer. Many filesystems don't even _have_ a "inum", so anything less doesn't work anyway. Example acceptable approach: - save away full dentry and page number. Don't make it an ioctl. Think "profiling" - this is _exactly_ the same thing, and profiling uses a (a) command line argument to turn it on (b) /proc/profile (and because you have the full pathname, you should just make the dang /proc/fsaccess file be ASCII) - add a "prefetch()" system call that does all the same things "read()" does, but doesn't actually wait for (or transfer) the data. Basically just a read-ahead thing. So you'd basically end up doing foreach (filename in /proc/fsaccess) fd = open(filename); foreach (sorted pagenr for filename in /proc/fsaccess) prefetch(fd, pagenr); end end Forget about all these crappy "ioctl" ideas. Basic rule of thumb: if you think an ioctl is a good idea, you're (a) being stupid and (b) thinking wrong and (c) on the wrong track. And notice how there's not a single bmap anywhere, and not a single "raw device open" anywhere. Linus - 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: Enable IP PNP for 2.4.4-ac8
"H . J . Lu" <[EMAIL PROTECTED]> writes: > On Sun, May 13, 2001 at 01:24:18PM -0600, Eric W. Biederman wrote: > > "H . J . Lu" <[EMAIL PROTECTED]> writes: > > > > > It doesn't make any senses. When I specify CONFIG_IP_PNP and > > > BOOTP/DHCP, I want a kernel with IP config using BOOTP/DHCP. I would > > > expect IP config is turned for BOOTP/DHCP by default. You can turn > > > it off by passing "ip=off" to kernel. Did I miss something? > > > > Since you have to set the command line anyway ip=dhcp is no extra > > burden and it lets you use the same kernel to boot of the harddrive etc. > > Why do I have to set "ip=dhcp"? If I have selected CONFIG_IP_PNP and > DHCP in my kernel configuration, should it be on by default? I agree it isn't intuitive, and if nfsroot=xxx is specified it should probably turn on if there is missing information. But if you have to select the command line anyway Mostly I like the situation where I can compile it in and turn it on when I need it, instead of having to do thing differently if it is compiled in or not. ip=on is all it really takes. > > > > This same situation exists for 2.2.18 & 2.2.19 as well. > > > > > > > > The only way to get long term stability out of this is to write > > > > a user space client, you can put in a ramdisk. One of these days... > > > > > > It doesn't work with diskless machines which don't support ramdisk > > > during boot. > > > > I don't believe that is a real world situation. > > > > I boot diskless all of time and supporting a ramdisk is trivial. You > > just a have a program that slaps a kernel a ramdisk, and some command > > line arguments into a single image, along with a touch of adapter code > > to set the kernel parameters correctly and then boot that. > > Let me guess. Your diskless machines are mostly x86. Mostly, but not exclusively. > Have you tried > ramdisk on diskless alpha, arm, m68k, mips, ppc, sh, sparc, booting > over network? First the booting situation on linux with respect to multiple platform sucks. We pass parameters in weird ways on every platform. The command line is the only thing that stays mostly the same. I'm looking at what it takes to clean that up, so we can have multiplatform bootloaders. I have implemented what it takes to attach a ramdisk, and if you can boot an arbitrary kernel it isn't hard to have a program that attaches a ramdisk. Now although I believe this is the right direction to go, you will notice I ported the dhcp IP auto configuration from 2.2.19 to to 2.4.x Buying a little more time to get this working. Eric - 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/
Minor numbers
To the best of my knowledge, dev_t number is still 16 bits with 8 most significant bits being the major number and the other 8 bits being the minor number; which of course means that minor numbers can only go up to 255. Has this limitation been some how addressed with 2.4? 256 devices per module, sometimes is not enough, especially if you are in the SAN environment; or when the 256 minors numbers are broken down to several ranges of numbers to address different types of special files. I don't see how this problem can be solved with dev_fs either. Anyone out there with a work-around or is proposing a solution? I believe that minor and major numbers for SUN and AIX are both 16 bits each (32 bits dev_t). Thanks in advance for your input. Thanks! Sincerely, Alex Chen IBM SSD Device Driver Development Office: 9000 S. Rita Rd 9032/2262 Email: [EMAIL PROTECTED] Phone: (external) 520-799-5212 (Tie Line) (321)-5212 - 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: Enable IP PNP for 2.4.4-ac8
On Sun, May 13, 2001 at 01:24:18PM -0600, Eric W. Biederman wrote: > "H . J . Lu" <[EMAIL PROTECTED]> writes: > > > It doesn't make any senses. When I specify CONFIG_IP_PNP and > > BOOTP/DHCP, I want a kernel with IP config using BOOTP/DHCP. I would > > expect IP config is turned for BOOTP/DHCP by default. You can turn > > it off by passing "ip=off" to kernel. Did I miss something? > > Since you have to set the command line anyway ip=dhcp is no extra > burden and it lets you use the same kernel to boot of the harddrive etc. Why do I have to set "ip=dhcp"? If I have selected CONFIG_IP_PNP and DHCP in my kernel configuration, should it be on by default? > > > > This same situation exists for 2.2.18 & 2.2.19 as well. > > > > > > The only way to get long term stability out of this is to write > > > a user space client, you can put in a ramdisk. One of these days... > > > > It doesn't work with diskless machines which don't support ramdisk > > during boot. > > I don't believe that is a real world situation. > > I boot diskless all of time and supporting a ramdisk is trivial. You > just a have a program that slaps a kernel a ramdisk, and some command > line arguments into a single image, along with a touch of adapter code > to set the kernel parameters correctly and then boot that. Let me guess. Your diskless machines are mostly x86. Have you tried ramdisk on diskless alpha, arm, m68k, mips, ppc, sh, sparc, booting over network? H.J. - 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: Adaptec RAID SCSI 2100S
> I'm trying to make this card work under 2.4.4, but I couldn't find a patch > anywhere to get it working under 2.4.x nor on 2.2.x. I tried with the I2O > kernel support, but it didn't work, it only reported errors after a pretty > long waiting :) You need to 2.4.4ac8 or higher for dpt i2o_scsi and 2.4.4ac5 or so or higher for dpt i2o_block - 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: Not a typewriter
"Mike A. Harris" <[EMAIL PROTECTED]> said: > On Fri, 11 May 2001 [EMAIL PROTECTED] wrote: [...] > >why creat doesn't end in an "e;" and so forth. I tell the The old C compiler/old Unix linker guaranteed 6 chars in an external symbol name only, and C functions got an underscore prepended: _creat. I guess this is the reason for this wart. As to why 6 chars only, I'd guess some data structure in the linker was laid out that way. Machines had a few dozen Kbs of RAM then, space was precious. > What is the reason for that? Also wondered why it is resolv.conf > and not resolve.conf or resolver.conf... Old FS handled only 14 chars in names, but that clearly isn't the reason here (11 chars). Some other operating system perhaps? > Were they afraid that "e" being the most widely used letter in > the English language was going to war out thir xpnsiv kyboards if > thy usd it all th tim? Funny conspiracy suscpicion, that... ;-) -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
[EMAIL PROTECTED] said:
> If I am not mistaken, Richard Hirst has also done work on this thing.
> The Panther/lp486e/PWS/... has on-board ethernet (82596) and this now
> works under both 2.2 and 2.4. It also has on-board SCSI (NCR
> 53c700-66), maybe memory mapped, I forget. Maybe nobody knows the
> addresses. It would be somewhat interesting to get that thing to work
> as well.
You're likely to trip across the part of the driver I skimped on: The clock divider
section. Usually you want the async core to run just under 25Mhz and the sync core to
run just under 50Mhz. Therefore, you ususally clock the 700-66 chip at 50Mhz and put
1 into the sync and 2 into the async divider (which is all I do---although you
probably clock a non -66 chip at 25Mhz). However, a combo card may have a rather
different clock speed. I can work on this some more if you want to try to get the
card running. Do you know what the clock speed is?
[EMAIL PROTECTED] said:
> According to http://www.murphy.nl/~ard/systems/pws/pws/node18.html the
> NCR 53c700/66 is mapped at 0xCC0-0xCFF.
That would be io mapped? then the 53c700.c chip driver should plug almost straight in.
[EMAIL PROTECTED] said:
> Yes. But long ago he wrote:
> ---
> You need quite a different driver from the 53c710 drivers that exist,
> because 53c700 doesn't have DSA register. I've attached a diff for
> 2.4.0-test9 which adds sim700.{c,h,scr}. That driver is supposed to
> handle 53c700 and 53c710 and be a replacement for sim710.c.
There are several other differences, although the lack of DSA register is the most
annoying:
- They can't manipulate the chip registers in the script.
- Their SCSI-DMA fifo core is only 32 bits (you need to compute the datapath residue
differently)
- The selection model is completely different. You can put the 710 into 700
compatibility mode and run the same selection model, but that's probably not what you
want: the 700 needs two interrupts to resume after a reselection, one to see the
selection and the other to collect the lun and tag. The 710 can wait for the
reselection grab the lun and tag and then interrupt. You can also dispense with the
elaborate selection interrupt section I have to have. I thought of doing a
probabalistic selection for the 700: given the PUN, you guess the lun and tag
(probably use the oldest) and set the script up for these. You take a "wrong guess"
interrupt if you got it incorrect. However, with 8 tags outstanding per device, you'd
probably only see a 13% correct guess, which didn't seem worth it.
I thought, based on these differences, that it made more sense to keep the 700 driver
separate from the 710 one.
The next chip core I'm considering is the 720/770 (I have a nice microchannel card
with 4 of these and 2MB of onboard memory), unless you know of someone who has already
done the extra work (the 53c7xx and 53c7,8xx don't do the wide/ultra features).
James
-
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/
Adaptec RAID SCSI 2100S
hi, I'm trying to make this card work under 2.4.4, but I couldn't find a patch anywhere to get it working under 2.4.x nor on 2.2.x. I tried with the I2O kernel support, but it didn't work, it only reported errors after a pretty long waiting :) The CDROM the card comes with brings a precompiled module (dpt_i2o) which works fine (only?) with 2.2.14. Adaptec web site says next to nothing about current linux drivers for this card. I don't understand why they don't just provide a patch against current 2.2.x and 2.4.x ... The best I've found is http://people.redhat.com/tcallawa/dpt/, where they provide a rpm packaged 2.2.19 kernel already with support for adaptec 2100S, and works :-) ... (where did they get the driver??? mistery...) So, is it possible to make it work under 2.4.4? :-) ps: has anyone the patch againt 2.2.x? (it would be nice to have the patch, although I already have 2.2.19 with support) Thanks. - 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-ac9
ftp://ftp.linux.org.uk/pub/linux/alan/2.4-ac/ Intermediate diffs are available from http://www.bzimage.org Ok we are back on kernel.org 2.4.4-ac9 o Clean up x86isms from the UML code (Chris Emerson) o Remove un-needed UML flag,fix hang under load (Jeff Dike) o Fix attach race in UML (Jeff Dike) o Fix warnings, clean up cpp abuses in UML(Roman Zippel) o Remove -D__KERNEL__ from user space of UML (Roman Zippel) o Add NCR53c700 and 53c700/66 driver (James Bottomley) |For NCR Dual 700 microchannel card o Alpha semaphore updates (Ivan Kokshaysky) p Fix ibmtr build a bit (Andrzej Krzysztofowicz) o Tidy sysrq-t output (Russell King) o Fix miata halt to SRM (Tom Vier) o Fix aging on buffer cache pages (Marcelo Tosatti) o Fix looping behaviour on failing memory (Marcelo Tosatti) allocations o Handle the PIIX4 on the new intel 82801BAM (Tim Raymond) o Fix user visible -ENOIOCTLCMD returns (Shane Wegner) o Fix startech uart detection problem (Val Henson) o Further tulip updates (Jeff Garzik) o Revert hpt366 patch 2.4.4-ac8 o Prefetch constant copy_to_user data (Arjan van de Ven) o Update cpqarray driver - use pci dma api(Charles White) o Update cciss driver - use pci dma api (Charles White) o Enable compiled in synclink driver (Paul Fulghum) o Fix plip section conflict (Keith Owens) o Tulip driver updates(Jeff Garzik) o Frame buffer logo updates (Geert Uytterhoeven) o Update __initdata documentation (Ingo Oeser) o Linearize sunrpc buffers using GFP_KERNEL (Trond Myklebust) o C Scott Ananian has moved (C Scott Ananian) o Update get_unaligned docs (John Levon) o Fix pci pool handling on boxes that have non(Pete Zaitcev) irq safe map create/destroy o Update m68k semaphores (Geert Uytterhoeven) o Update NLS Configure.help (Nerijus Baliunas) o Clean up cyclom driver (Arnaldo Carvalho de Melo) o Further serial driver update(Jeff Garzik) o Fix typo in sched.c (Jim Freeman) o Do prefetches on wake_up_common walk(Arjan van de Ven) o Fix bootmem init problems (Andrea Arcangeli) o Fix pops on cs46xx power management (Thomas Woller) o Fix reference of freed memory in cs46xx (Christopher Kanaan) o Hopefully fix i2o scsi reset crash (me) 2.4.4-ac7 o Fix dasd off by one found by Al Viro(me) o Fix copy under cli in moxa,mxser,pcxx,riscom8 o Cleaned up serial167 formatting (no code(me) changes this patch set) o Fix missing length check in AGPgart (me) | Found by Al Viro o Fix wrong kmalloc sizes in ixj/emu10k1 (David Chan) o Fix make distclean on ramfs/tmpfs (Ingo Oeser) o Update checkconfig, Changes (Niels Jensen) o NFS mmap consistency on close fix (Andrea Arcangeli) o Fix 10 bit decode causing APM hang on a laptop (Pete Zaitcev) when using ymfpci o Reserve failure on vesa video ram is not fatal (Jordan Crouse) o Update athlon mmx copier to not prefetch off(Arjan van de Ven) the end o Fix scsi.c procfs zero termination checks (Al Viro) o And fix -EFAULT returns from it (me) o Update ibm token ring driver(Mike Phillips) o Fix sockfilter maths overflow (Al Viro) o Make dev name lookup robust to nonterminated(Al Viro) buffers o Update config.h use (Niels Jensen) o Fix xircom cardbus ethernet/modem support (Bill Nottingham) o Fix off by one buffer checks in atm_poa and (Al Viro) dasd o Clean up printks in zr36067.c (me) 2.4.4-ac6 o Revert dead swap patch pending fixes(Dave Miller) o Allow arch specific writeproc/DMA for IDE (Bjorn Wesen) o Move to aic7xxx 6.1.13 (Justin Gibbs) o Use pci_set_master on eni.c (Jeff Garzik) o Update wireless drivers, add airport(Jean Tourrihles, Benjamin
Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
>> If I am not mistaken, Richard Hirst has also done work on this thing.
> He did 53c710+. The 700 and 700/66 are much less capable devices.
Yes. But long ago he wrote:
---
You need quite a different driver from the 53c710 drivers that
exist, because 53c700 doesn't have DSA register. I've attached
a diff for 2.4.0-test9 which adds sim700.{c,h,scr}. That driver
is supposed to handle 53c700 and 53c710 and be a replacement for
sim710.c.
---
> the NCR 53c700/66 is mapped at 0xCC0-0xCFF.
Good! You are well-organized. I also had that someplace.
> system board id ... mac address
I am not quite sure what you mean by System Board Id.
The EISA ID of this thing is INT3061.
Andries
-
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: Not a typewriter
On Fri, 11 May 2001, Hacksaw wrote: >Well, I can't disagree. Unix's biggest turn off was the stupid command names. I agree partially with that, but as someone who's used DCL in VMS, I can say meaningful names are no better. People don't want to type SHOW DIRECTORY or CREATE /DIRECTORY /PERMISSIONS=blah blah.. and when given DCL, once people understand how to create logical names (the equiv of aliases in unix) they alias the above verbose garbage down to 2-4 letter cryptic looking names. I don't know anyone who has used VMS for more than 3 months who hasn't done the above. Problem is that everyone chooses their own cryptic shortcuts from everyone else. At least in UNIX, the short cryptic names are the same everywhere, and you can alias them to larger names if you like. Signature poll: I'm planning on getting a 12 or 16 port autosensing 10/100 ethernet switch soon for home use, and am interested in hearing others recommendations on what to buy. Cost isn't as important as is functionality and quality. Any suggestions appreciated. - 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: Not a typewriter
On Fri, 11 May 2001 [EMAIL PROTECTED] wrote: >>Heaven help us when tradition is more important than clarity. >> > >If clarity is the most important consideration, then other things should be >changed as well. For instance, the command we use to search for text strings in >files should be called "textsearch." That's a lot more clear than "grep." gnuregularexpressionparser? >why creat doesn't end in an "e;" and so forth. I tell the What is the reason for that? Also wondered why it is resolv.conf and not resolve.conf or resolver.conf... Were they afraid that "e" being the most widely used letter in the English language was going to war out thir xpnsiv kyboards if thy usd it all th tim? ;o) >I guess what I'm trying to say is that "Life With Unix" should be required >reading for anyone who goes near a Unix (or Linux) system. I agree. ;o) Signature poll: I'm planning on getting a 12 or 16 port autosensing 10/100 ethernet switch soon for home use, and am interested in hearing others recommendations on what to buy. Cost isn't as important as is functionality and quality. Any suggestions appreciated. - 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: Nasty Requirements for non-GPL Linux Kernel Modules?
[EMAIL PROTECTED] (Mike Galbraith) wrote on 13.05.01 in <[EMAIL PROTECTED]>: > On 13 May 2001, Kai Henningsen wrote: > > > [EMAIL PROTECTED] (Alan Cox) wrote on 09.05.01 in > > <[EMAIL PROTECTED]>: > > > > > > you stand, it'll cost you around $15K and that, in my opinion, is > > > > fine. If it isn't worth $15K to protect your code then it is worth so > > > > little to you that there really is no good reason not to just GPL it > > > > from the start. > > > > > > Smart advice. > > > > Problem is, the people making that decision are not always the people > > wanting to distribute the work in question, in which case the argument > > doesn't work. > > if (!cost_analysis) goto darwinism; Thank you for completely missing the point. MfG Kai - 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.5-pre1, iproute2 - IPv6
Hi, I have an unusual problem with compiling iproute2 on 2.4.5-pre1, this problem didn't occur on my previous kernel - 2.4.2-ac3.. root@tower:~/progs/server/iproute2# uname -a Linux tower 2.4.5-pre1-xfs #5 Sat May 12 12:55:39 CEST 2001 i686 unknown root@tower:~/progs/server/iproute2# make ... make[1]: Entering directory `/root/progs/server/iproute2/lib' gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g -I../include-glibc -include ../include-glibc/glibc-bugs.h -I/usr/src/linux/include -I../include -DRESOLVE_HOSTNAMES -c -o ll_proto.o ll_proto.c ll_proto.c:36: `ETH_P_ECHO' undeclared here (not in a function) ll_proto.c:36: initializer element is not constant ll_proto.c:36: (near initialization for `llproto_names[1].id') make[1]: *** [ll_proto.o] Error 1 make[1]: Leaving directory `/root/progs/server/iproute2/lib' make: *** [all] Error 2 root@tower:~/progs/server/iproute2# grep "ETH_P_ECHO" /usr/src/linux/include/linux/if_ether.h somebody@somewhere:somewhere$ grep "ETH_P_ECHO" /usr/src/linux-2.2.19/include/linux/if_ether.h #define ETH_P_ECHO 0x0200 /* Ethernet Echo packet */ <-- or sth like this..(not me was executing it..) but root@tower:~/progs/server/iproute2# grep "0x0200" /usr/src/linux/include/linux/if_ether.h #define ETH_P_PUP 0x0200 /* Xerox PUP packet */ Maybe I have mailed to much output..I'm lame:) I tried the compilation of 2 version of iproute2: current, and 2.2.4-now-ss001007. The error is the same..Why is it so? Do I do sth bad? Or maybe there is a bug in the kernel.. -- *"Being alive, you matter much more."* | Piotr Wysocki ([EMAIL PROTECTED]) [wysek/elk] | | telephone +48605 15 | http://wysek.braxis.co.uk | | BLUG reg. member #0012 | Linux reg. member #207707 | - 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: Another VM race? (was: page_launder() bug)
On Sun, 13 May 2001, Mikulas Patocka wrote: > CPU 0 CPU 1 > is executing the code marked is executing try_to_free_buffers on > above with ^^^: the same page (it can be, because CPU 0 > did not lock the page) > > (page->buffers && > > page->buffers = NULL > > MAJOR(page->buffers->b_dev) == > RAMDISK_MAJOR)) ===> Oops, NULL pointer dereference! > > > > Maybe compiler CSE optimization will eliminate the double load of > page->buffers, but we must not rely on it. If the compiler doesn't > optimize it, it can produce random oopses. You're right, this should be fixed. Do you happen to have a patch ? ;) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - 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/
CMD64x - full DMA support?
Hi all. First time writing to the kernel list, so let me know if I break
any conventions. This is long, so I thank you all for your help now :o)
Paul Dorman.
I have two CMD648 PCI ATA66 controllers - one generic and one by
Leadtek. At the moment the Leadtek is installed. I have a dual PII 450
machine on a Gigabyte BXD motherboard. My current kernel is 2.4.4-ac4. I
understand that there may be hardware flaws with the CMD640 chipset. If
this is the case, is there any chance of a work-around? If not, how can
I get the best performance out of this card?
If I use hdparm to set DMA=1 on a drive attached to the controller I get
all kinds of errors when I attempt to access its filesystem:
...
...
ide_dmaproc: chipset supported ide_dma_lostirq func only: 13
hde: lost interrupt
*or*
...
...
/dev/ide/host2/bus0/target0/lun0: p1
/dev/ide/host2/bus0/target0/lun0: p1
reiserfs: checking transaction log (device 21:01) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hde: DMA disabled
ide2: reset: success
*or*
...
...
hde: dma_intr: status=0xff { Busy }
hde: DMA disabled
ide2: reset timed-out, status=0xff
hde: status timeout: status=0xff { Busy }
hde: drive not ready for command
ide2: reset timed-out, status=0xff
hde: status timeout: status=0xff { Busy }
end_request: I/O error, dev 21:01 (hde), sector 95948856
hde: drive not ready for command
hde: status timeout: status=0xff { Busy }
hde: drive not ready for command
ide2: reset timed-out, status=0xff
hde: status timeout: status=0xff { Busy }
hde: drive not ready for command
ide2: reset timed-out, status=0xff
hde: status timeout: status=0xff { Busy }
end_request: I/O error, dev 21:01 (hde), sector 95949360
hde: drive not ready for command
hde: status timeout: status=0xff { Busy }
hde: drive not ready for command
ide2: reset timed-out, status=0xff
hde: status timeout: status=0xff { Busy }
hde: drive not ready for command
ide2: reset timed-out, status=0xff
hde: status timeout: status=0xff { Busy }
end_request: I/O error, dev 21:01 (hde), sector 95949368
...
I have:-
* Shifted cards around,
* Tried different interrupts,
* Tried THREE different 80 wire cables.
I hope this is the pertinent information...
=[DMESG output]
CMD648: IDE controller on PCI bus 00 dev 50
CMD648: chipset revision 1
CMD648: not 100% native mode: will probe irqs later
CMD648: ROM enabled at 0xee00
ide2: BM-DMA at 0xe800-0xe807, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xe808-0xe80f, BIOS settings: hdg:pio, hdh:pio
A little further down is:
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
I have tried to force DMA using boot parameters, but without success.
===[/proc/interrupts]==
CPU0 CPU1
0:18348581823909IO-APIC-edge timer
1: 5073 5179IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
7: 0 0IO-APIC-edge parport0
8: 1 0IO-APIC-edge rtc
9: 0 0IO-APIC-edge acpi
10: 4 4IO-APIC-edge advansys
12: 97363 103087IO-APIC-edge PS/2 Mouse
14: 181732 211754IO-APIC-edge ide0
15: 2 10IO-APIC-edge ide1
16:14312141528254 IO-APIC-level bttv, Ensoniq AudioPCI,
nvidia
17: 55827 56939 IO-APIC-level eth0
19: 0 0 IO-APIC-level usb-uhci
NMI: 0 0
LOC:36676303667650
ERR: 0
MIS: 21
===[/proc/ide/cmd64x]==
CMD648 Chipset.
--- Primary Channel Secondary Channel
-
enabled enabled
--- drive0 - drive1 drive0 --
drive1 --
DMA enabled:yes no nono
DMA Mode: UDMA(4) PIO(?) PIO(?)
PIO(?)
PIO Mode: ?? ? ?
polling polling
clearclear
enabled enabled
CFR = 0x40, HI = 0x04, LOW =
Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
> If I am not mistaken, Richard Hirst has also done work on this thing. He did 53c710+. The 700 and 700/66 are much less capable devices. According to http://www.murphy.nl/~ard/systems/pws/pws/node18.html the NCR 53c700/66 is mapped at 0xCC0-0xCFF. The system board id looks interesting too. I wonder if its related to the mac address.. Sadly my box is dead so I cant poke - 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][CFT] (updated) ext2 directories in pagecache
On Thursday 10 May 2001 09:21, Andreas Dilger wrote: > I previously wrote: > > I was looking at the new patch, and I saw something that puzzles > > me. Why do you set the EXT2_INDEX_FL on a new (empty) directory, > > rather than only setting it when the dx_root index is created? > > > > Setting the flag earlier than that makes it mostly useless, since > > it will be set on basically every directory. Not setting it would > > also make your is_dx() check simply a check for the EXT2_INDEX_FL > > bit (no need to also check size). > > > > Also no need to set EXT2_COMPAT_DIR_INDEX until such a time that we > > have a (real) directory with an index, to avoid gratuitous > > incompatibility with e2fsck. This is fixed in today's patch. > I have changed the code to do the following: > - If the COMPAT_DIR_INDEX flag is set at mount/remount time, set the > INDEX mount option (the same as "mount -o index"). This removes > the need to specify the "-o index" option each time for filesystems > which already have indexed directories. This applied fine. The semantics are a little loose though: after mounting -o index, the first directory that overflows its first block will turn on 'sticky indexing' for that partition. I was originally thinking we should give the admin the ability to create a nonindexed directory if desired, and that's how it used to be before we changed the setting of INDEX_FL from directory creation time to later, when the first directory block overflows. You are probably right on both counts, but it's something to think about. > - New directories NEVER have the INDEX flag set on them. > - If the INDEX mount option is set, then when directories grow past 1 > block (and have the index added) they will get the directory INDEX > flag set and turn on the superblock COMPAT_DIR_INDEX flag (if off). It works this way now. > This means that you can have common code for indexed and non-indexed > ext2 filesystems, and the admin either needs to explicitly set > COMPAT_DIR_INDEX in the superblock or mount with "-o index" (and > create a directory > 1 block). Actually, I've had common code for indexed and non-indexed right from the first prototype, I hope there isn't any misunderstanding there. > I have also added some tricks to ext2_inc_count() and > ext2_dec_count() so that indexed directories are not subject to the > EXT2_LINK_MAX. I've done the same as reiserfs, and set i_nlink = 1 > if we overflow EXT2_LINK_MAX (which has been increased to 65500 for > indexed directories). Apparently i_nlink = 1 is the right think to do > w.r.t. find and other user tools. > > Patches need some light testing before being posted. Today's Patch --- The main change in today's patch is the simplified handling of the index creation. Besides that there are quite a few incremental improvements and most, but not all of your recent patch set is in. I broke out 'ext2_add_compat_feature' as a trial balloon. It's not really very satisfying - it's annoying to have a great piece of machinery that's used in exactly one place. I'd prefer to have 'ext2_add_feature' that takes the kind of compatibility as a parameter. We can do this by treating the three ext2_super_block compatibility fields as an array, what do you think? Then we'd get to use it in two places :-] I wrote ext2_append as a wrapper on ext2_bread, mainly to bury the i_size handling. Its function is to append a single block to a file. I pass back the block number of the appended block via a pointer, which is clumsy but the only other choice is to calculate the block number every time outside the function, which just leaves more things to get out of sync. I found a real bug in the continued-hash handling - instead of advancing to the next index block the same block would be reread. Nobody hit this because even with a million file directory the error condition would exist for less than 1 in 250 million entries. Still, correct is correct. Having to deal with such rare conditions is the price we have to pay for the benefits of hashed keys. The max link count logic in your previous patch didn't seem to be complete so I didn't put it in. I'll wait for more from you on that. I followed the ReseirFS thread on this but I'm not sure exactly what form you want this to take in ext2. I followed your recommendation and simplified the index creation and INDEX_FL flag interpretation. Now the index is created for any directory that grows over a block, whereas before the condition was 'any new directory created with indexing enabled that later grows over one block'. The index create code has been moved out of the non-indexed code path and into the scope of the indexed path. This is with a view to cutting ext2_add_entry into pieces at some point, for aesthetic reasons. The one place where I'm relying on a newly-created block to be contain zeros got a comment. I was unable to apply your patch all at once, and of course, I'd hacked on the
Re: PROBLEM: IDE dma_intr error on VIA chipset
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
read the fine faq.
-
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: "clock timer configuration lost" error?
Interesting. This is a KA7 with all power management turned off in the latest Abit BIOS. > The kernel puts the timer back and life appears happy again Ahhh. The kernel *is* god. Alan Cox wrote: > > > Feb 26 00:19:52 abit kernel: probable hardware bug: clock timer > > configuration lost - probably a VIA686a. > > Feb 26 00:19:52 abit kernel: probable hardware bug: restoring chip > > configuration. > > Feb 26 00:26:53 abit xntpd[886]: synchronized to 132.239.254.5, > > stratum=2 > > ... > > Small number of VIA 686 boxes randomly jump from 100Hz back to the DOS 18Hz > timeout. We dont know if its hardware or maybe APM bios bugs. The kernel puts > the timer back and life appears happy again Well, I have a pentium 66 (o/c @ 100) with a probably very old HP bios, and I have the problem... and I don't think my Computer have a VIA686a... Fun... -- V Gab - 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: PROBLEM: IDE dma_intr error on VIA chipset
> Whenever a hard disk access is attempted, I get the following messages:
>
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
That is a cable problem
> This error did not appear under previous versions of the kernel (2.2.x).
2.2.x doesnt attempt UDMA
> The hard disk does not show any sign of hardware failure under other
> operating systems.
and windows fails down to lower speeds without telling you
-
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: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
> New SCSI driver for 53c700 chip Good! If I am not mistaken, Richard Hirst has also done work on this thing. The Panther/lp486e/PWS/... has on-board ethernet (82596) and this now works under both 2.2 and 2.4. It also has on-board SCSI (NCR 53c700-66), maybe memory mapped, I forget. Maybe nobody knows the addresses. It would be somewhat interesting to get that thing to work as well. Andries - 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/
PROBLEM: IDE dma_intr error on VIA chipset
Description of the problem:
---
Whenever a hard disk access is attempted, I get the following messages:
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
This error did not appear under previous versions of the kernel (2.2.x).
No material modification has been made between 2.2.x and 2.4.x kernel update.
The hard disk does not show any sign of hardware failure under other
operating systems.
Kernel version: both 2.4.2 (standard and Mandrake) and 2.4.4 (standard)
Environment/OS: Linux Mandrake 8.0
Processor info: AMD Athlon 600 Mhz.
Chipset: VIA82C686A (UDMA 66)
Included with this e-mail is a dmesg trace and a copy of the /proc directory.
If you send an answer, please send it to [EMAIL PROTECTED]
dmesg, kernel config and part of /proc directory
[PATCH] missing return value from pci_xircom_fn() in drivers/char/serial.c
Hi,
I'm using the 2.4.4-ac8 kernel and found that the pci_xircom_fn()
function in drivers/char/serial.c does not return a value even though it
is defined as returning int. I took a look at the other initializer
functions and they all return 0 (zero) on success, so I assumed that the
correct return value for the pci_xircom_fn() function would also be 0. I
don't know anything specific about what goes on in serial.c, so I may be
wrong on this, but I do know that the function should either return some
value or be declared as returning void, and since declaring it void
would mess up the way it is used I guess it should return a value.
I have made a patch against 2.4.4-ac8 that makes the change, it is
below. I guess someone more knowledgeable than me can probably see if
this is correct. If this is completely bogus, then please just disregard
this email.
--- linux-2.4.4-ac8/drivers/char/serial.c.orig Sun May 13 23:13:02 2001
+++ linux-2.4.4-ac8/drivers/char/serial.c Sun May 13 23:13:24 2001
@@ -4190,6 +4190,7 @@
{
__set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(HZ/10);
+ return(0);
}
/*
Best regards,
Jesper Juhl - [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] ES978 docking support for Maestro 2E - advice requested
Hi. I have an Compaq Armada M700 laptop and an ArmadaStation II
laptop. The laptop has a Maestro 2E sound chipset in it, and the
docking station has the matching ES978 chip which controls
speakers and handles volume up/down/mute buttons on the side of
the docking station. The maestro.c driver in 2.4.4 doesn't have
support for these, so I wrote some code to do it. The following
patch adds support. It does the following:
* Turns on the docking station speakers and sets the
playback volume on them to the max. (Their volume is
still scaled based on the Maestro's master volume.)
* Adds basic support for the hardware volume control
buttons: the up button increases volume by 10%, the
down button decreases volume by 10%, the mute button
toggles the master volume on and off.
It doesn't do any of the following:
* Add the docking station volumes to the mixer--it just
hard-wires them to the max values. Should I do this?
* Make the buttons from the hardware volume control
available to software. Should I do this (I assume that
hard-wiring +/- 10% isn't really acceptable)? What's
the best way to do it--create a /dev/es978buttons and a
daemon, or what?
* Add any support for the recording features of the
docking station--just playback.
All comments appreciated.
--- /root/linux-2.4.4.clean/drivers/sound/maestro.c Fri Mar 2 14:12:11 2001
+++ linux-2.4.5pre1/drivers/sound/maestro.c Sun May 13 17:14:07 2001
@@ -115,6 +115,8 @@
* themselves, but we'll see.
*
* History
+ * (still kind of v0.14) May 13 2001 - Ben Pfaff <[EMAIL PROTECTED]>
+ * Add support for 978 docking and basic hardware volume control
* (still kind of v0.14) Nov 23 - Alan Cox <[EMAIL PROTECTED]>
* Add clocking= for people with seriously warped hardware
* (still v0.14) Nov 10 2000 - Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
@@ -189,7 +191,7 @@
* fix bob frequency
* endianness
* do smart things with ac97 2.0 bits.
- * docking and dual codecs and 978?
+ * dual codecs
* leave 54->61 open
*
* it also would be fun to have a mode that would not use pci dma at all
@@ -483,8 +485,12 @@
int bob_freq;
char dsps_open;
+
+ int dock_mute_vol;
};
+static void set_mixer(struct ess_card *card,unsigned int mixer, unsigned int val );
+
static unsigned
ld2(unsigned int x)
{
@@ -983,6 +989,17 @@
outw(inw(ioaddr+0x68) | 0x600, ioaddr + 0x68);
outw(0x0209, ioaddr + 0x60);
}
+
+ /* Turn on the 978 docking chip.
+ First frob the "master output enable" bit,
+ then set most of the playback volume control registers to max. */
+ outb(inb(ioaddr+0xc0)|(1<<5), ioaddr+0xc0);
+ outb(0xff, ioaddr+0xc3);
+ outb(0xff, ioaddr+0xc4);
+ outb(0xff, ioaddr+0xc6);
+ outb(0xff, ioaddr+0xc8);
+ outb(0x3f, ioaddr+0xcf);
+ outb(0x3f, ioaddr+0xd0);
}
/*
* Indirect register access. Not all registers are readable so we
@@ -1895,19 +1912,52 @@
outw(inw(c->iobase+4)&1, c->iobase+4);
/* M_printk("maestro int: %x\n",event);*/
-
if(event&(1<<6))
{
- /* XXX if we have a hw volume control int enable
- all the ints? doesn't make sense.. */
- event = inw(c->iobase+0x18);
- outb(0xFF, c->iobase+0x1A);
- }
- else
- {
- /* else ack 'em all, i imagine */
- outb(0xFF, c->iobase+0x1A);
+ int x;
+ enum {UP_EVT, DOWN_EVT, MUTE_EVT} vol_evt;
+ int volume;
+
+ /* Figure out which volume control button was pushed,
+ based on differences from the default register
+ values. */
+ x = inb(c->iobase+0x1c);
+ if (x&1) vol_evt = MUTE_EVT;
+ else if (((x>>1)&7) > 4) vol_evt = UP_EVT;
+ else vol_evt = DOWN_EVT;
+
+ /* Reset the volume control registers. */
+ outb(0x88, c->iobase+0x1c);
+ outb(0x88, c->iobase+0x1d);
+ outb(0x88, c->iobase+0x1e);
+ outb(0x88, c->iobase+0x1f);
+
+ /* Deal with the button press in a hammer-handed
+ manner by adjusting the master mixer volume. */
+ volume = c->mix.mixer_state[0] & 0xff;
+ if (vol_evt == UP_EVT) {
+ volume += 10;
+ if (volume > 100)
+ volume = 100;
+ }
+ else if (vol_evt == DOWN_EVT) {
+ volume -= 10;
+ if (volume < 0)
+ volume = 0;
+ } else {
+ /* vol_evt == MUTE_EVT */
+
Kernel freezes after "freeing unused kernel memory"
Hi folks, I just installed RedHat 7.1 on a dual P3-733 system with 1 GB RAM. The installation went fine, but, after rebooting, the system fails to come up. The kernel loads but then eventually halts at the "freeing unused kernel memory" message. Does anyone have any ideas on what this means and how to resolve it? Here's the system configuration: Dual P3-733s 1 GB ECC PC133 SDRAM SuperMicro 370DL3 motherboard Symbios Ultra Wide SCSI (64-bit PCI card) Diamond Stealth II S220 PCI video (only card I could get to work in the system) On board SCSI and NIC are disabled (this did not help). Thanks for any feedback. -Jeff -- Jeff Golds [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/
Another VM race? (was: page_launder() bug)
> > > + if (!dead_swap_page &&
> > > + (PageTestandClearReferenced(page) || page->age > 0 ||
> > > + (!page->buffers && page_count(page) > 1) ||
> > > + page_ramdisk(page))) {
> > ^^
> > > del_page_from_inactive_dirty_list(page);
> > > add_page_to_active_list(page);
> > > continue;
> >
> > #define page_ramdisk(page) \
> > (page->buffers && (MAJOR(page->buffers->b_dev) == RAMDISK_MAJOR))
> >
> > Are you sure that no one will release buffers under your hands?
>
> Two things can happen:
>
> 1) the page gets ramdisk buffers _after_ we look at it first,
>in this case the page isn't freeable and will be moved to
>the active list on the next page_launder() loop
>
> 2) the page loses its ramdisk buffers after we look at it,
>now the page is freeable, but we won't see it again until
>it is moved from the active list to the inactive_dirty
>list again
>
> Any side effects harmful enough to warrant complicating this
> test ?
I mean this: Let's have a page with buffers. It does not care whether the
buffers are on ramdisk or not.
CPU 0 CPU 1
is executing the code markedis executing try_to_free_buffers on
above with ^^^: the same page (it can be, because CPU 0
did not lock the page)
(page->buffers &&
page->buffers = NULL
MAJOR(page->buffers->b_dev) ==
RAMDISK_MAJOR)) ===> Oops, NULL pointer dereference!
Maybe compiler CSE optimization will eliminate the double load of
page->buffers, but we must not rely on it. If the compiler doesn't
optimize it, it can produce random oopses.
Mikulas
-
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: Linux TCP impotency
On Sun, May 13, 2001 at 09:38:53PM +0200, [EMAIL PROTECTED] wrote: > Using 2.2.19 I discovered that running two simultaneous scp's (uses up whole > capacity in TCP traffic) on a 115200bps full duplex serial port nullmodem cable > causes the earlier started one to survive and the later to starve. Running bcp > instead of the second (which uses UDP) at 11000 bytes per second caused the > utilization in both directions to go up nearly to 100%. > > Is this a normal TCP stack behaviour? Might very well be. Read about different forms of (class based) queuing which try (and succeed) to improve IP in this respect. TCP is not fair and IP has no intrinsic features to help you. http://ds9a.nl/2.4Routing contains some explanations and links. SFQ sounds like it might fit your bill. Regards, bert -- http://www.PowerDNS.com Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - 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-ac8 boot lockup
Hi: Just tried to boot 2.4.4-ac8 on my thinkpad: I have an eepro100 ethernet card, which works fine under 2.4.3-ac14 and 2.4.4 - when I tried 2.4.4-ac8 things got as far as pump trying to bring up the eth0 interface, and the machine locked up - this happened a few times [I have not enabled CONFIG_EEPRO100_PM, and have set CONFIG_EEPRO100=m], so I did a make mrproper and recompiled and reinstalled the 2.4.4-ac8 kernel, which resulted in a panic and lockup even earlier in the boot sequence: something about not being able to handle a device with more than 16 heads. Not a problem for me or anything, but if anyome wants me to try stuff out or investigate further, I'd be happy to. -- "Aren't you ashamed of yourself?" "No, I have people to do that for me." - 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/
Unable to compile cvs kernel on Sparc
Hi I have a SparcStation 10 with dual SuperSparc processors (_not_ sparc64), and I am unable to compile the latest kernel from vger.samba.org CVS. Standard Linus kernels neither work, but I figure they aren't supposed to... The reason seems to be that the functions pmd_alloc_one_fast, pmd_alloc_one, and pgd_populate needed for memory.c are not declared in include/asm-sparc/ System information: Distribution: Debian testing/woody GCC:2.95.4 (standard debian package) Running kernel: 2.2.19 Trying to compile: 2.4.5-pre1 from cvs I would be most happy to provide other specific info on request. Oystein -- This message was generated by a flock of happy penguins. - 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: IPv6: the same address can be added multiple times
On Sun, 13 May 2001 [EMAIL PROTECTED] wrote: > Hello! > > > It appears you can add _exactly_ same IPv6 address on an interface many > > times: > > Yes. BTW, look here: > > kuznet@dust:~ # ip -6 a ls sit0 > 7: sit0@NONE: mtu 1480 qdisc noqueue > inet6 ::127.0.0.1/96 scope host > inet6 ::193.233.7.100/96 scope global > inet6 ::193.233.7.100/96 scope global > > I have two equal addresses inherited from one IPv4 address > on two interfaces. Nothing illegal. Heh, I doubt there's an RFC that says "you MUST not be able to add the same address twice to an interface". I think it's kind of taken for granted. ;-) But it still looks dirty. Also, it's easier to add it many times by mistake; IPv4 addresses do not allow this. And as you have to remove them N times too, this may create even more confusion. > > It looks like a check or two in kernel is missing, or is there some > > reasoning to this behaviour? > > Well, it is one of well defined approaches (unlike KAME's one). > Alternative is to implement full set of options NLM_F_* like used > in IPv4 routing to block undefined cases. In IPv6 flags are hardwired > to NLM_F_CREATE|NLM_F_APPEND both for addresses and routes. Well, I can't really formulate an expert opinion as I'm not intimate how this works on Linux, but I think KAME adds addresses to a structure where duplicates aren't possible. Also, what would be the other well defined approaches? Quickly I can think of only two, if "only one same address" isn't possible: 1) never allow any address to be added at all 2) no significant restrictions (==this) I don't think the former is what people want either ;-) Please Cc:. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords - 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] eliminate a truckload of context switches
On 05.13 Rik van Riel wrote: > On Tue, 8 May 2001, Mike Galbraith wrote: > > > While running a ktrace enabled kernel (IKD), I noticed many useless > > context switches. The problem is that we continually pester kswapd/ > > kflushd at times when they can't do anything other than go back to > > sleep. As you'll see below, we do this quite a bit under heavy load. > > I agree, both with your analysis that the context switches > aren't needed and with the patch you sent to fix it. > > Linus, if it isn't in the kernel yet, please put it in... > If it matters, I have been running it on 2.4.4-ac8 and works fine... -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.4-ac8 #1 SMP Sat May 12 01:16:37 CEST 2001 i686 - 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: Linux TCP impotency
> causes the earlier started one to survive and the later to starve. Running bcp > instead of the second (which uses UDP) at 11000 bytes per second caused the > utilization in both directions to go up nearly to 100%. > > Is this a normal TCP stack behaviour? Yes. TCP is not fair. Look up 'capture effect' if you want to know more. - 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 TCP impotency
Using 2.2.19 I discovered that running two simultaneous scp's (uses up whole capacity in TCP traffic) on a 115200bps full duplex serial port nullmodem cable causes the earlier started one to survive and the later to starve. Running bcp instead of the second (which uses UDP) at 11000 bytes per second caused the utilization in both directions to go up nearly to 100%. Is this a normal TCP stack behaviour? -- Karel Kulhavy http://atrey.karlin.mff.cuni.cz/~clock - 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: page_launder() bug
On Sun, 13 May 2001, Linus Torvalds wrote: > On Sun, 13 May 2001, Rik van Riel wrote: > > > > Why the hell would we want this ? > You've missed about half the discussion, it seems.. True, I was away at a conference ;) > > If the page is referenced, it should be moved back to the > > active list and should never be a candidate for writeout. > > Wrong. > > There are > (a) dead swap pages, where it doesn't matter one _whit_ whether it is > referenced or not, because we know with 100% certainty that nobody > will ever reference it again. This _may_ be true in other cases too, > but we know it is true for swap pages that have lost all references. > (b) filesystems and memory allocators that might want to get feedback on > the fact that we're even _looking_ at their pages, and that we're > aging them down. They might easily use these things for starting > background activity like deciding to close the logs.. > > The high-level VM layer simply doesn't have that kind of information. Agreed. I'd like to make sure, however, that we keep the high-level VM cleanly separated from the lower layers so we can keep the VM maintainable and predictable... regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - 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: page_launder() bug
On Sun, 13 May 2001, Rik van Riel wrote: > > This means that the swapin path (and the same path for > other pagecache pages) doesn't take the page lock and > the page lock doesn't protect us from other people using > the page while we have it locked. You can test for swap cache deadness without holding the page cache lock: if the swap count is 1, then we know that nobody else has this swap entry in its page tables, and thus there can not be any concurrent lookups either. Now, it may well be that we need to make sure that there is some proper ordering (nobody must decrement the swap count before they increment the page count or something). I think that is the case anyway (and I _think_ that everybody that mucks with the swap count always hold the page count - this might be a good thing to check). So while you're right in general, there are some things we can do with less global locking. Just holding the page lock will guarantee that at least nobody changes the index etc from under us, so that the things we test are at least fairly well-defined. Linus - 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: LVM 1.0 release decision
On Sun, May 13, 2001 at 06:36:11PM +0100, David Woodhouse wrote: > IMHO, no 64-bit architecture code should provide translation functions for > ioctls from 32-bit binaries. > > This is now a sufficiently common requirement that it shouldn't be repeated > by all architectures that require it - it should be somewhere common. > Like linux/abi/ioctl32/ Better linux/abi/linux32 and have other 32/64-bit stuff there too. At least the binfmt_elf32 stuff should be made MI, IMHO. Christoph -- Of course it doesn't work. We've performed a software upgrade. - 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: Enable IP PNP for 2.4.4-ac8
"H . J . Lu" <[EMAIL PROTECTED]> writes: > It doesn't make any senses. When I specify CONFIG_IP_PNP and > BOOTP/DHCP, I want a kernel with IP config using BOOTP/DHCP. I would > expect IP config is turned for BOOTP/DHCP by default. You can turn > it off by passing "ip=off" to kernel. Did I miss something? Since you have to set the command line anyway ip=dhcp is no extra burden and it lets you use the same kernel to boot of the harddrive etc. > > This same situation exists for 2.2.18 & 2.2.19 as well. > > > > The only way to get long term stability out of this is to write > > a user space client, you can put in a ramdisk. One of these days... > > It doesn't work with diskless machines which don't support ramdisk > during boot. I don't believe that is a real world situation. I boot diskless all of time and supporting a ramdisk is trivial. You just a have a program that slaps a kernel a ramdisk, and some command line arguments into a single image, along with a touch of adapter code to set the kernel parameters correctly and then boot that. Eric - 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 2.4.5.1: Fix Via interrupt routing issues
> > I disagree. The IO-APIC is the chipset APIC. It is distinct from the APIC > > on the processors. > > Disagree with which part? The fix, or likely needing a better ifdef? Needing a better ifdef > >From the point of view of the Via southbridge chip, IO-APIC is > external... The comment above the ifdef was more along the lines of, > "Via on PPC (OpenPIC?) might need this too, not just io-apic" That will be an architecture specific quirk. I don't actually think you can better. Somehow I always assumed ppc people had better taste in bridges 8) - 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 2.4.5.1: Fix Via interrupt routing issues
Alan Cox wrote: > > > +/* we will likely need a better ifdef, something like > > + * ifdef CONFIG_EXTERNAL_APIC > > + */ > > +#ifdef CONFIG_X86_IO_APIC > > I disagree. The IO-APIC is the chipset APIC. It is distinct from the APIC > on the processors. Disagree with which part? The fix, or likely needing a better ifdef? >From the point of view of the Via southbridge chip, IO-APIC is external... The comment above the ifdef was more along the lines of, "Via on PPC (OpenPIC?) might need this too, not just io-apic" -- Jeff Garzik | Game called on account of naked chick Building 1024| MandrakeSoft | - 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] drivers/telephony/phonedev.c (brings this code up to date with Quicknet CVS)
> Alrighty. That eliminates the patch. I'll rewrite the ixj.c according > to this. ixj.c will be a large patch due to the numerous revisions, I Im much less worried about having 2.2/2.4 version code in the ixj driver itself. Quicknet have to maintain that for 2.2/2.4 and I dont want to make their life that needlessly painful > don't know how well it can be broken up into small pieces. Do you want > small pieces still? The ChangeLog shows all the fixes for the > revisions. There have been 68 revisions since the version listed in the > kernel's tree. See what you can do - if its too hard we may just have to do it the hard way - 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 2.4.5.1: Fix Via interrupt routing issues
> +/* we will likely need a better ifdef, something like > + * ifdef CONFIG_EXTERNAL_APIC > + */ > +#ifdef CONFIG_X86_IO_APIC I disagree. The IO-APIC is the chipset APIC. It is distinct from the APIC on the processors. - 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: Linux support for Microsoft dynamic disks?
At 19:15 13/05/2001, Art Boulatov wrote: >On Sunday 13 May 2001 02:46 pm, Guest section DW wrote: > > On Sat, May 12, 2001 at 08:34:45PM -0600, Jeff V. Merkey wrote: > > > What is your specific question? > > > > Well, my specific question would be: enough information to support > > mounting filesystems that live on a dynamic disk. > >Understanding the layout of a dynamic disk is just a part of the problem >as far as I can see it. >What if I have two (three,four) dynamic disks with volumes organized into a >software stripe (raid0) under Windows? >There must be an implementation of MS' software raid in the linux kernel in >order to access that "striped filesystem" under linux, I'm I right? That is a completely separate issue since NT4 software raid also exists but doesn't use dynamic disks at all. The existing md driver in Linux can be modified to make this work. No need for a full rewrite. There are problems with it at the moment which make it not work for ntfs software raid but they can be solved. It's just not on anyones high priority list at the moment... Anton -- Anton Altaparmakov (replace at with @) Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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: skb->truesize > sk->rcvbuf == Dropped packets
Hello! > > Any suggestions on heuristics for this ? Not to set rcvbuf to ridiculously low values. The best variant is not to touch SO_*BUF options at all. Alexey - 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.4 kernel freeze for unknown reason
Hi Mike, On Sat, 12 May 2001, Mike Galbraith wrote: > Why do I not see this behavior with a heavy swap throughput test > load? It seems decidedly odd to me that swapspace should remain > allocated on other folks lightly loaded boxen given that my heavily > loaded box does release swapspace quite regularly. What am I > missing? Are you using a database or something other which mostly uses shared mem/tmpfs? This does reclaim swap space on swap in. Greetings Christoph - 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: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified
Hello! > I believe these events get sent to the cardmgr daemon and it does > all the ifconf magic to change the device state. Compare this also to the situation with netif_present(). After Linus said that it is called from thread context, I prepared corresponding code for netif_present (and for carrier detection in assumption it is called from thread context or softirq) BUT... this happened to be not true. So, these macros still do not assume anything on context. As result netif_carrier* is unreliable, netif_present is still straight bug. Should be fixed, of course. BTW what did happen with Andrew's netdev registration patch? By some strange reason I believed it is already applied... Grrr. Alexey - 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: Linux support for Microsoft dynamic disks?
On Sunday 13 May 2001 02:46 pm, Guest section DW wrote: > On Sat, May 12, 2001 at 08:34:45PM -0600, Jeff V. Merkey wrote: > > What is your specific question? > > Well, my specific question would be: enough information to support > mounting filesystems that live on a dynamic disk. > > Andries Understanding the layout of a dynamic disk is just a part of the problem as far as I can see it. What if I have two (three,four) dynamic disks with volumes organized into a software stripe (raid0) under Windows? There must be an implementation of MS' software raid in the linux kernel in order to access that "striped filesystem" under linux, I'm I right? Art. - 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] Patches for unchecked pointers in various drivers
[EMAIL PROTECTED] said: > We've identified several unchecked pointers using the Stanford checker > and have produced patches for them: > FTL (a memory card driver) Patch applied to the master CVS, along with a cleanup on the immediately subsequent malloc check too. It'll be in my next merge to Linus, which should be quite soon - thanks. -- dwmw2 - 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: page_launder() bug
Rik van Riel writes: > Then I'd rather check this in a visible place in page_launder() > itself. Granted, this is a special case, but I don't think this > one is worth obfuscating the code for... I think Linus's scheme is just fine, controlling the new 'priority' argument to writepage() using the referenced bit as an input. Later, David S. Miller [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: IPv6: the same address can be added multiple times
Hello! > It appears you can add _exactly_ same IPv6 address on an interface many > times: Yes. BTW, look here: kuznet@dust:~ # ip -6 a ls sit0 7: sit0@NONE: mtu 1480 qdisc noqueue inet6 ::127.0.0.1/96 scope host inet6 ::193.233.7.100/96 scope global inet6 ::193.233.7.100/96 scope global I have two equal addresses inherited from one IPv4 address on two interfaces. Nothing illegal. > FWIW, KAME stack adds the address only once(, but BSD ifconfig(8) > doesn't show errors when you try to do it again; just doesn't add the > second one). 8) > It looks like a check or two in kernel is missing, or is there some > reasoning to this behaviour? Well, it is one of well defined approaches (unlike KAME's one). Alternative is to implement full set of options NLM_F_* like used in IPv4 routing to block undefined cases. In IPv6 flags are hardwired to NLM_F_CREATE|NLM_F_APPEND both for addresses and routes. Alexey - 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: page_launder() bug
On Sun, 13 May 2001, David S. Miller wrote: > Rik van Riel writes: > > On Tue, 8 May 2001, David S. Miller wrote: > > > Nice. Now the only bit left is moving the referenced bit > > > checking and/or state into writepage as well. This is still > > > part of the plan right? > > > > Why the hell would we want this ? > > Because if it's a dead swap page the referenced bit is meaningless > and we should just kill off the page immediately. Then I'd rather check this in a visible place in page_launder() itself. Granted, this is a special case, but I don't think this one is worth obfuscating the code for... regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - 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: page_launder() bug
Rik van Riel writes: > On Tue, 8 May 2001, David S. Miller wrote: > > Nice. Now the only bit left is moving the referenced bit > > checking and/or state into writepage as well. This is still > > part of the plan right? > > Why the hell would we want this ? Because if it's a dead swap page the referenced bit is meaningless and we should just kill off the page immediately. Later, David S. Miller [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: ENOIOCTLCMD?
At 5:45 PM +0100 2001-05-13, Alan Cox wrote: > > What I was arguing (conceptually) is that something like >> #define ENOIOCTLCMD ENOTTY >> or preferably but more invasively s/ENOIOCTLCMD/ENOTTY/ (mutatis mutandis) >> >> would result in no loss of function. I assert that ENOIOCTLCMD is >> redundant, pending a specific counterexample. > >On the contrary. I can now no longer force an unsupported response when there >is a generic routine I dont wish to use That makes sense. Thanks. -- /Jonathan Lundell. - 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: LVM 1.0 release decision
[EMAIL PROTECTED] said: > Andrea Arcangeli writes: > > Related side note: for the x86-64 kernel we won't support the emulation > > of the lvm ioctl from the 32bit executables to avoid the pointer > > conversion an mainteinance pain enterely, at least in the early stage > > the x86-64 lvmtools will have to be compiled elf64. > I think that's a bad decision, but it is your's. > To me, either you support fully the 32-bit execution environment or > you do not. After all the work that myself and others have done for > other platforms, there really is no need to cut corners in this area. IMHO, no 64-bit architecture code should provide translation functions for ioctls from 32-bit binaries. This is now a sufficiently common requirement that it shouldn't be repeated by all architectures that require it - it should be somewhere common. Like linux/abi/ioctl32/ -- dwmw2 - 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: Timers
On Sun, May 13, 2001 at 05:45:13PM +0100, Matt wrote: > I'm having some major headaches trying to get a timer working in my > driver. > > The timer is started when the device node is opened, and deleted when it's > closed. The timer code itself calls mod_timer to add itself back in > again. At the moment, it runs every second and does nothing more than > issue a debug printk to say it's working okay. > > The problem comes when I try and wrap the timer code inside some down() > and up() calls to make sure it's not fiddling with the hardware at the > same time as some other calls. When I do this, I get a huge oops which > goes right off my screen and I get the "Aieee..." message afterwards and I > have to push the reset button :(. You're trying to sleep in an interrupt, which is not allowed. > > Should I be using spin_(un)lock_irqsave() calls anywhere instead of just a > semaphore? Or is there anything else I should be doing? Yes you should. The only way to use a semaphore from interrupt context (=timers) is to use down_trylock() and retry when it was locked, e.g. by resetting the timer. That is normally awkward and irqsafe spinlocks are probably better. Of course they cannot be held schedules or anything that may sleep. -Andi - 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 2.4.5.1: Fix Via interrupt routing issues
For those of you with Via interrupting routing issues (or
interrupt-not-being-delivered issues, etc), please try out this patch
and let me know if it fixes things. It originates from a tip from
Adrian Cox... thanks Adrian!
--
Jeff Garzik | Game called on account of naked chick
Building 1024|
MandrakeSoft |
Index: drivers/pci/quirks.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/pci/quirks.c,v
retrieving revision 1.1.1.35
diff -u -r1.1.1.35 quirks.c
--- drivers/pci/quirks.c2001/05/02 09:26:23 1.1.1.35
+++ drivers/pci/quirks.c2001/05/13 17:22:18
@@ -12,6 +12,7 @@
* use the PowerTweak utility (see http://powertweak.sourceforge.net).
*/
+#include
#include
#include
#include
@@ -238,7 +239,34 @@
quirk_io_region(dev, smb, 16, PCI_BRIDGE_RESOURCES + 2);
}
+
+/* we will likely need a better ifdef, something like
+ * ifdef CONFIG_EXTERNAL_APIC
+ */
+#ifdef CONFIG_X86_IO_APIC
+extern int nr_ioapics;
+
/*
+ * VIA 686A/B: If an IO-APIC is active, we need to route all on-chip
+ * devices to the external APIC.
+ */
+static void __init quirk_via_ioapic(struct pci_dev *dev)
+{
+ u8 tmp;
+
+ if (nr_ioapics < 1)
+ tmp = 0;/* nothing routed to external APIC */
+ else
+ tmp = 0x1f; /* all known bits (4-0) routed to external APIC */
+
+ /* Offset 0x58: External APIC IRQ output control */
+ pci_write_config_byte (dev, 0x58, tmp);
+}
+
+#endif /* CONFIG_X86_IO_APIC */
+
+
+/*
* PIIX3 USB: We have to disable USB interrupts that are
* hardwired to PIRQD# and may be shared with an
* external device.
@@ -322,6 +350,14 @@
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82371SB_2,
quirk_piix3_usb },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82371AB_2,
quirk_piix3_usb },
{ PCI_FIXUP_FINAL, PCI_ANY_ID, PCI_ANY_ID,
quirk_cardbus_legacy },
+
+/* we will likely need a better ifdef, something like
+ * ifdef CONFIG_EXTERNAL_APIC
+ */
+#ifdef CONFIG_X86_IO_APIC
+ { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686,
+ quirk_via_ioapic },
+#endif
+
{ 0 }
};
Re: [reiserfs-dev] Re: reiserfs, xfs, ext2, ext3
"Albert D. Cahalan" wrote: > Hans Reiser writes: > > > Tell us what to code for, and so long as it doesn't involve looking > > up files by their 32 bit inode numbers we'll probably be happy to > > code to it. The Neil Brown stuff is already coded for though. > > Next time around, when you update the on-disk format, how about > allowing for such a thing? > > You could have a tree that maps from inode number to whatever > you need to find a file. This shouldn't affect much more than > file creation and deletion. Maybe it will allow for a more > robust fsck as well, helping to justify the cost. > > It would be really nice to be able to find all filenames that > refer to a given inode number. It would have a significant performance impact and use disk space. Hans - 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-dev] Re: reiserfs, xfs, ext2, ext3
On Friday, May 11, 2001 04:00:20 AM -0700 Hans Reiser <[EMAIL PROTECTED]> wrote: > Alan Cox wrote: > >> > Are you referring to Neil Brown's nfs operations patch as being as >> > ugly as hell, or something else? Just want to understand what you are >> > saying before arguing. >> >> Andi has sent me some stuff to look at. He listed four implementations >> and I've only seen two of them > > did you see an implementation which adds operations to VFS and is written > by Neil Brown (with reiserfs portions by Chris and Nikita)? I coded up a mixture of Andi's 2.2.x apis and Neil's 2.4.x stuff and sent it out for review a little while ago. It isn't as good as Neil's stuff, but it doesn't require changing the other filesystems. If it looked good to the NFS guys and the other FS guys don't hate it, I'll push it around for testing/inclusion. This would be my preferred solution right now, since it could also work for AFS. -chris - 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] drivers/telephony/phonedev.c (brings this code up to date with Quicknet CVS)
Alrighty. That eliminates the patch. I'll rewrite the ixj.c according
to this. ixj.c will be a large patch due to the numerous revisions, I
don't know how well it can be broken up into small pieces. Do you want
small pieces still? The ChangeLog shows all the fixes for the
revisions. There have been 68 revisions since the version listed in the
kernel's tree.
David
Alan Cox wrote:
>>phonedev.diff is against 2.4.4 and brings the file phonedev.c up to date
>>with respect to the Quicknet CVS. Changes are very minor, mostly #if
>>LINUX_VERSION_CODE matching and structure updates. Small off by one
>>fixes and file operation semantics updates.
>>
>
>I intentionally dont keep back compat glue in the mainstream kernel
>
>>@@ -101,20 +134,25 @@
>>
>> if (unit != PHONE_UNIT_ANY) {
>> base = unit;
>>- end = unit + 1; /* enter the loop at least one time */
>>+ end = unit;
>>
>
>This unfixes a bug too.
>
>All rejected
>
-
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/
Timers
I'm having some major headaches trying to get a timer working in my driver. The timer is started when the device node is opened, and deleted when it's closed. The timer code itself calls mod_timer to add itself back in again. At the moment, it runs every second and does nothing more than issue a debug printk to say it's working okay. The problem comes when I try and wrap the timer code inside some down() and up() calls to make sure it's not fiddling with the hardware at the same time as some other calls. When I do this, I get a huge oops which goes right off my screen and I get the "Aieee..." message afterwards and I have to push the reset button :(. Should I be using spin_(un)lock_irqsave() calls anywhere instead of just a semaphore? Or is there anything else I should be doing? Cheers Matt - 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: ENOIOCTLCMD?
> What I was arguing (conceptually) is that something like > #define ENOIOCTLCMD ENOTTY > or preferably but more invasively s/ENOIOCTLCMD/ENOTTY/ (mutatis mutandis) > > would result in no loss of function. I assert that ENOIOCTLCMD is > redundant, pending a specific counterexample. On the contrary. I can now no longer force an unsupported response when there is a generic routine I dont wish to use - 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: CML2 design philosophy heads-up
Eric S. Raymond wrote: > Reasoned objections can change my behavior. Grunting territorial > challenges at me will not. You have two options: (1) persuade Linus > that the whole CML2 thing is a bad idea and should be dropped, or (2) > work with me to correct any errors I have made and improve the system. > Growling at me and hoping I go away won't work, not when I've invested > a year's effort in this project. Eric, you're trying to do too much too quickly. Wait until 2.5 to clean stuff up. That's what the rest of us have to do, even for some things which are real bugs rather than infelicities in the current design. You can't treat this as an all-or-nothing deal. Some of your ideas for CML2 are right, and some aren't. Get the non-controversial bits in, then fight over the ideas that're worth fighting for. Yes, CML2 enables a more task-based than hardware-based approach, and I think that's generally a good thing; but I do believe that this isn't going to be suitable for everyone. Let's work up to it gradually. -- One of the most insidious things the CIA Communists did when they took over Unistat was to change the Constitution. The original Constitution, having been written by a group of intellectual libertines and Freemasons in the eighteenth century, included an amendment which declared: A self-regulated sex life being necessary to the happiness of a citizen, the right of people to keep and enjoy pornography shall not be abridged. This amendment had been suggested by Thomas Jefferson, who had over nine hundred Black concubines, and Benjamin Franklin, a member of the Hell Fire Club, which had the largest collection of erotic books and art in the Western world at that time. The Communists changed the amendment to read: A well-regulated militia being necessary to the security of a free state, the right of the citizens to keep and bear arms shall not be abridged. All documents and textbooks were changed, so that nobody would be able to find out what the amendment had originally said. Then the Communists set up a front organisation, the National Rifle Association, to encourage the wide usage of guns of all sorts and to battle any attempt to control guns as "unconstitutional." Thus, they guaranteed that the murder rate in Unistat would always be the highest in the world. This kept the citizens in perpetual anxiety about their safety both on the streets and in their homes. The citizens then tolerated the rapid growth of the Police State, which controlled almost everything, except the sale of guns, the chief cause of crime. -- Robert Anson Wilson in the Schroedinger's Cat Trilogy - 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: Enable IP PNP for 2.4.4-ac8
"H . J . Lu" <[EMAIL PROTECTED]> writes: > On Fri, May 11, 2001 at 04:28:05PM -0700, David S. Miller wrote: > > > > H . J . Lu writes: > > > 2.4.4-ac8 disables IP auto config by default even if CONFIG_IP_PNP is > > > defined. Here is a patch. > > > > It doesn't make any sense to enable this unless parameters are > > given to the kernel via the kernel command line or from firmware > > settings. > > >From Configure.help: > > IP: kernel level autoconfiguration > CONFIG_IP_PNP > This enables automatic configuration of IP addresses of devices and > of the routing table during kernel boot, based on either information > supplied on the kernel command line or by BOOTP or RARP protocols. > You need to say Y only for diskless machines requiring network > access to boot (in which case you want to say Y to "Root file system > on NFS" as well), because all other machines configure the network > in their startup scripts. > > It works fine for 2.4.4. However, in 2.4.4-ac8, even if I select > CONFIG_IP_PNP, I have to pass ip= to kernel, in addition to > nfsroot=x.x.x.x:/foo/bar. With 2.4.4, I can just pass > nfsroot=x.x.x.x:/foo/bar to kernel. O.k. Configure.help needs to be updated. "ip=on" or "ip=bootp" or "ip=dhcp" work fine. I wonder if I forgot to forward port the docs? This same situation exists for 2.2.18 & 2.2.19 as well. The only way to get long term stability out of this is to write a user space client, you can put in a ramdisk. One of these days... Eric - 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: page_launder() bug
On Tue, 8 May 2001, David S. Miller wrote: > Marcelo Tosatti writes: > > Ok, this patch implements thet thing and also changes ext2+swap+shm > > writepage operations (so I could test the thing). > > > > The performance is better with the patch on my restricted swapping tests. > > Nice. Now the only bit left is moving the referenced bit > checking and/or state into writepage as well. This is still > part of the plan right? Why the hell would we want this ? If the page is referenced, it should be moved back to the active list and should never be a candidate for writeout. I'm very happy we got rid of the horribly intertwined VM code in 2.2 and went to a more separated design in 2.4... regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - 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] drivers/telephony/phonedev.c (brings this code up to date with Quicknet CVS)
> phonedev.diff is against 2.4.4 and brings the file phonedev.c up to date
> with respect to the Quicknet CVS. Changes are very minor, mostly #if
> LINUX_VERSION_CODE matching and structure updates. Small off by one
> fixes and file operation semantics updates.
I intentionally dont keep back compat glue in the mainstream kernel
> @@ -101,20 +134,25 @@
>
> if (unit != PHONE_UNIT_ANY) {
> base = unit;
> - end = unit + 1; /* enter the loop at least one time */
> + end = unit;
This unfixes a bug too.
All rejected
-
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: mount /dev/hdb2 /usr; swapon /dev/hdb2 keeps flooding
> Erm... Let me restate: what did you expect to achieve with that? > Swap on device means that all contents of that device is lost. > Mounting fs from device generally means that you don't want the > loss of contents. At least until you unmount the thing. Actually no. There is no swap magic so the swap fails. Unfortunately it appears to have hosed the mount in the meantime. Alan - 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: FastTrack100+2.4.4 panic
> I am having trouble with the 2.4.4 kernel using MSI 694D Pro AR dual > PIII processor motherboard with onboard Promise ATA100. Fixed in 2.4.5pre1/2.4.4-ac - 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: page_launder() bug
On Tue, 8 May 2001, Mikulas Patocka wrote:
> > + if (!dead_swap_page &&
> > + (PageTestandClearReferenced(page) || page->age > 0 ||
> > +(!page->buffers && page_count(page) > 1) ||
> > +page_ramdisk(page))) {
> ^^
> > del_page_from_inactive_dirty_list(page);
> > add_page_to_active_list(page);
> > continue;
>
> #define page_ramdisk(page) \
> (page->buffers && (MAJOR(page->buffers->b_dev) == RAMDISK_MAJOR))
>
> Are you sure that no one will release buffers under your hands?
Two things can happen:
1) the page gets ramdisk buffers _after_ we look at it first,
in this case the page isn't freeable and will be moved to
the active list on the next page_launder() loop
2) the page loses its ramdisk buffers after we look at it,
now the page is freeable, but we won't see it again until
it is moved from the active list to the inactive_dirty
list again
Any side effects harmful enough to warrant complicating this
test ?
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
-
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] eliminate a truckload of context switches
On Tue, 8 May 2001, Mike Galbraith wrote:
> While running a ktrace enabled kernel (IKD), I noticed many useless
> context switches. The problem is that we continually pester kswapd/
> kflushd at times when they can't do anything other than go back to
> sleep. As you'll see below, we do this quite a bit under heavy load.
I agree, both with your analysis that the context switches
aren't needed and with the patch you sent to fix it.
Linus, if it isn't in the kernel yet, please put it in...
thanks,
Rik
> --- linux-2.4.4.ikd/mm/vmscan.c.org Tue May 8 10:54:33 2001
> +++ linux-2.4.4.ikd/mm/vmscan.c Tue May 8 11:16:17 2001
> @@ -964,7 +964,7 @@
>
> void wakeup_kswapd(void)
> {
> - if (current != kswapd_task)
> + if (waitqueue_active(_wait))
> wake_up_process(kswapd_task);
> }
>
> --- linux-2.4.4.ikd/fs/buffer.c.org Tue May 8 10:55:33 2001
> +++ linux-2.4.4.ikd/fs/buffer.c Tue May 8 11:15:22 2001
> @@ -2578,16 +2578,16 @@
> return flushed;
> }
>
> +DECLARE_WAIT_QUEUE_HEAD(kflushd_wait);
> struct task_struct *bdflush_tsk = 0;
>
> void wakeup_bdflush(int block)
> {
> - if (current != bdflush_tsk) {
> + if (waitqueue_active(_wait))
> wake_up_process(bdflush_tsk);
>
> - if (block)
> - flush_dirty_buffers(0);
> - }
> + if (block)
> + flush_dirty_buffers(0);
> }
>
> /*
> @@ -2711,14 +2711,10 @@
>* skip the sleep and flush some more. Otherwise, we
>* go to sleep waiting a wakeup.
>*/
> - set_current_state(TASK_INTERRUPTIBLE);
> if (!flushed || balance_dirty_state(NODEV) < 0) {
> run_task_queue(_disk);
> - schedule();
> + interruptible_sleep_on(_wait);
> }
> - /* Remember to mark us as running otherwise
> -the next schedule will block. */
> - __set_current_state(TASK_RUNNING);
> }
> }
>
>
> -
> 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/
>
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
-
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: page_launder() bug
On Mon, 7 May 2001, Linus Torvalds wrote: > Which you MUST NOT do without holding the page lock. > > Hint: it needs "page->index", and without holding the page lock you > don't know what it could be. Wouldn't that be the pagecache_lock ? Remember that the semantics for find_swap_page() and friends got changed recently to first test PageUptodate and only try to lock the page if that didn't work out. This means that the swapin path (and the same path for other pagecache pages) doesn't take the page lock and the page lock doesn't protect us from other people using the page while we have it locked. What _does_ protect us, however, is the fact that reclaim_page() grabs the pagecache_lock... [OTOH, I could be out to lunch here since I was away for almost a week and haven't checked if the discussed changes really were integrated into the kernel] regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - 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: Possible PCI subsystem bug in 2.4
"Maciej W. Rozycki" <[EMAIL PROTECTED]> writes: > On 4 May 2001, Eric W. Biederman wrote: > > > The example that sticks out in my head is we rely on the MP table to > > tell us if the local apic is in pic_mode or in virtual wire mode. > > When all we really have to do is ask it. > > You can't. IMCR is write-only and may involve chipset-specific > side-effects. Then even if IMCR exists, a system's firmware might have > chosen the virtual wire mode for whatever reason (e.g. broken hardware). Admittedly you can't detect directly detect IMCR state. But triggering an interrupt on the bootstrap processor local apic, and failing to receive it should be proof the IMCR is at work. Alternatively if I'm wrong about the wiring disabling all interrupts at the apic level and receiving one is a second proof that IMCR is at work. Further I don't think a processor with an onboard apic, works with an IMCR register. What I was thinking of earlier is that you can detect an apic or ioapic in virtual wire mode, which the current code and the intel MP spec treats as the opposite possibility. Eric - 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: [Question] Explanation of zero-copy networking
Jamie Lokier <[EMAIL PROTECTED]> writes: > Richard B. Johnson wrote: > > However, PCI to memory copying runs at about 300 megabytes per > > second on modern PCs and memory to memory copying runs at over 1,000 > > megabytes per second. In the future, these speeds will increase. > > That would be "big expensive modern PCs" then. Our clusters of 700MHz > boxes are strictly limited to 132 megabytes per second over PCI... 300 Megabytes per second is definitely an odd number for a PCI bus. But 132 Megabytes per second is actually high, the continuous burst speeds are: 32bit 33Mhz: 33*1000*1000*32/(1024*1024*8) = 125.8 Megabytes/second 64bit 33Mhz: 33*1000*1000*64/(1024*1024*8) = 251.7 Megabytes/second 32bit 66Mhz: 66*1000*1000*32/(1024*1024*8) = 251.7 Megabytes/second 64bit 66Mhz: 66*1000*1000*64/(1024*1024*8) = 503.4 Megabytes/second The possibility of getting a continuous bursts is actually low, if nothing else you have an interrupt acknowledgement 100 times per second. But if you are pushing the bus it should deliver close to it's burst potential. But the ISA traffic doing subtractive decode can be nasty because you get 4 PCI cycles before you even get acknowledgement from the PCI/ISA bridge that you there is something to transfer to. Eric - 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/
Can't read the CDRW disc created in Windows.
Can't read the CDRW disc created in Windows. If I use: mount -t udf /dev/scd1 /mnt/cdrw It will report: mount: wrong fs type, bad option, bad superblock on /dev/scd1, or too many mounted file systems If I use: mount -t auto /dev/scd1 /mnt/cdrw Then I can success mount with type iso9660, but the display file is not correct, because it is not iso9660: [root@desktop cdrw]# ls autorun.inf* udfrinst.exe* I suppose the file system of CDRW in UDF, as state in kernel doc. Why I can't mount it?? P.S.: I have try to put a Data CD in that CDRW driver to test, it can show the correct files in it, so I think the problem is UDF in linux, do anyone have any idea about this issue? -- Carfield Yim, visit my homepage at http://www.carfield.com.hk - 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: CML2 design philosophy heads-up
Jes Sorensen <[EMAIL PROTECTED]>: > Not all cards have all features, not all users wants to enable all > features. Yes, I understand that. You're not reading the derivations correctly. Let's take an example: derive MVME147_SCSI from MVME147 & SCSI This doesn't turn on MVME147_SCSI on every MVME147 board. It turns on MVME147_SCSI when both MVME147 *and SCCI* are on. So to suppress MVME147_SCSI, one just leaves SCCI off. All these derived symbols will still be controllable. The difference is that instead of being controlled by a low-level hardware-oriented question they're controlled by a capability or subsystem symbol like SCSI, NET_ETHERNET, or SERIAL. > Eric> # These were separate questions in CML1 derive MAC_SCC from MAC > Eric> & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from > Eric> (SUN3 | SUN3X) & SCSI > > As Alan already pointed out thats assumption is invalid. I'm in touch with Ray Knight directly and will fix this as he requests. > Yes I have objections. I thought I had made this clear a long time > ago: Go play with another port and leave the m68k port alone. Does this mean you'll take over maintaining the CML2 rules files for the m68k port, so I don't have to? That would be wonderful. Reasoned objections can change my behavior. Grunting territorial challenges at me will not. You have two options: (1) persuade Linus that the whole CML2 thing is a bad idea and should be dropped, or (2) work with me to correct any errors I have made and improve the system. Growling at me and hoping I go away won't work, not when I've invested a year's effort in this project. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond As with the Christian religion, the worst advertisement for Socialism is its adherents. -- George Orwell - 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: ENOIOCTLCMD?
At 5:43 PM +0100 2001-05-12, Alan Cox wrote: > > That's what's confusing me: why the distinction? It's true that the >> current scheme allows the dev->ioctlfunc() call below to force ENOTTY >> to be returned, bypassing the switch, but presumably that's not what >> one wants. > >It allows driver specific code to override generic code, including >by reporting >that a given feature is not available/appropriate. > >Alan What I was arguing (conceptually) is that something like #define ENOIOCTLCMD ENOTTY or preferably but more invasively s/ENOIOCTLCMD/ENOTTY/ (mutatis mutandis) would result in no loss of function. I assert that ENOIOCTLCMD is redundant, pending a specific counterexample. -- /Jonathan Lundell. - 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: ENOIOCTLCMD?
At 3:27 PM -0700 2001-05-12, Shane Wegner wrote: > >int err = dev->ioctlfunc(dev, op, arg); >> if( err != -ENOIOCTLCMD) >> return err; >> >> /* Driver specific code does not support this ioctl */ > >I noticed this return coming out of the watchdog driver a >while ago when I was playing with it. I have taken a quick >look and it seems a few drivers do return this directly to >userspace. I'm not sure if this is complete but ... Can't this be handled in sys_ioctl()? At the very end, replace out: return error; with out: return (error == -ENOIOCTLCMD) ? -ENOTTY : error; >diff -ur linux-2.4.4-ac8/drivers/block/swim3.c linux/drivers/block/swim3.c >--- linux-2.4.4-ac8/drivers/block/swim3.c Sat May 12 14:59:44 2001 >+++ linux/drivers/block/swim3.cSat May 12 15:22:30 2001 >@@ -848,7 +848,7 @@ > sizeof(struct floppy_struct)); > return err; > } >- return -ENOIOCTLCMD; >+ return -ENOTTY; > } -- /Jonathan Lundell. - 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: FastTrack100+2.4.4 panic
Thanks both Christian Ehrhardt and Axel Thimm! The two-line patch to drivers/ide/ide-pci.c (including comment) worked perfectly. --Eric - 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/
