date:20010525

On Sat, 26 May 2001, Rik van Riel wrote:

> 1) normal user allocation
> 2) buffer allocation (bounce buffer + bufferhead)
> 3) allocation from interrupt (for device driver)

H, now that I think of it, we always need to be able
to guarantee _both_ 2) and 3).  For different allocators
and interrupts.  I guess the only long-term solution is
to have real memory reservation strategies, like the one
in Ben's patch.

That might be a 2.5 thing, though ... Ben?

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: Linux-2.4.5

On Sat, 26 May 2001, Andrea Arcangeli wrote:
> On Fri, May 25, 2001 at 10:49:38PM -0400, Ben LaHaise wrote:
> > Highmem.  0 free pages in ZONE_NORMAL.  Now try to allocate a buffer_head.
> 
> That's a longstanding deadlock, it was there the first time I read
> fs/buffer.c, nothing related to highmem, we have it in 2.2 too. Also
> getblk is deadlock prone in a smiliar manner.

Not only this, but the fix is _surprisingly_ simple...
All we need to make sure of is that the following order
of allocations is possible and that we back out instead
of deadlock when we don't succeed at any step.

1) normal user allocation
2) buffer allocation (bounce buffer + bufferhead)
3) allocation from interrupt (for device driver)

This is fixed by the patch I sent because:

1) user allocations stop when we reach zone->pages_min and
   keep looping until we freed some memory ... well, these
   don't just loop because we can guarantee that freeing
   memory with GFP_USER or GFP_KERNEL is possible

2) GFP_BUFFER allocations can allocate down to the point
   where free pages go to zone->pages_min * 3 / 4, so we
   can continue to swapout highmem pages when userland
   allocations have stopped ... this is needed because
   otherwise we cannot always make progress on highmem
   pages and we could have the effective amount of RAM
   in the system reduced to less than 1GB, in really bad
   cases not having this could even cause a deadlock

3) If the device driver needs to allocate something, it
   has from zone->pages_min*3/4 down to zone->pages_min/4
   space to allocate stuff, this should be very useful
   for swap or mmap() over the network, or to encrypted
   block devices, etc...

> Can you try to simply change NR_RESERVED to say 200*MAX_BUF_PER_PAGE
> and see if it makes a difference?

No Comment(tm)   *grin*

cheers,

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: Linux-2.4.5

On Fri, 25 May 2001, Linus Torvalds wrote:

> This is why we always leave a few pages free, exactly to allow nested
> page allocators to steal the reserved pages that we keep around. If
> that deadlocks, then that's a separate issue altogether.
> 
> If people are able to trigger the "we run out of reserved pages"
> behaviour under any load, that indicates that we either have too few
> reserved pages per zone, or that we have a real thinko somewhere that
> allows eating up the reserves we're supposed to have.

This is exactly what gets fixed in the patch I sent you.
Feel free to reimplement it in a complex way if you want ;)

> But sometimes the right solution is just to have more reserves.

Won't work if the ethernet card is allocating memory
at gigabit speed. And no, my patch won't protect against
this thing either, only memory reservations can.

All my patch does is give us a 2.4 kernel now which
doesn't hang immediately as soon as you run on highmem
machines with a heavy swapping load.

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: [kbuild-devel] Configure.help entries wanted

2001-05-25 Thread Greg Banks

Eric S. Raymond wrote:
> 
> CONFIG_SH_SCI
> CONFIG_SH_STANDARD_BIOS
> CONFIG_DEBUG_KERNEL_WITH_GDB_STUB

  From the LinuxSH CVS (I can write new ones if these are inadequate):

SuperH SCI (serial) support
CONFIG_SH_SCI
  Selecting this option will allow the Linux kernel to transfer
  data over SCI (Serial Communication Interface) and/or SCIF
  which are built into the Hitachi SuperH processor.

  If in doubt, press "y".

Use LinuxSH standard BIOS
CONFIG_SH_STANDARD_BIOS
  Say Y here if your target has the gdb-sh-stub package from
  www.m17n.org (or any conforming standard LinuxSH BIOS) in FLASH
  or EPROM.  The kernel will use standard BIOS calls during boot
  for various housekeeping tasks.  Note this does not work with
  WindowsCE machines.  If unsure, say N.

GDB Stub kernel debug
CONFIG_DEBUG_KERNEL_WITH_GDB_STUB
  If you say Y here, it will be possible to remotely debug the SuperH
  kernel using gdb, if you have the gdb-sh-stub package from
  www.m17n.org (or any conforming standard LinuxSH BIOS) in FLASH or
  EPROM.  This enlarges your kernel image disk size by several megabytes
  but allows you to load, run and debug the kernel image remotely using
  gdb.  This is only useful for kernel hackers.  If unsure, say N.

Greg.
-- 
These are my opinions not PPIs.
-
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-2.4.5

On Sat, 26 May 2001, Andrea Arcangeli wrote:
>
> On Fri, May 25, 2001 at 10:49:38PM -0400, Ben LaHaise wrote:
> > Highmem.  0 free pages in ZONE_NORMAL.  Now try to allocate a buffer_head.
> 
> That's a longstanding deadlock, it was there the first time I read
> fs/buffer.c, nothing related to highmem, we have it in 2.2 too. Also
> getblk is deadlock prone in a smiliar manner.

Indeed. 

This is why we always leave a few pages free, exactly to allow nested page
allocators to steal the reserved pages that we keep around. If that
deadlocks, then that's a separate issue altogether.

If people are able to trigger the "we run out of reserved pages" behaviour
under any load, that indicates that we either have too few reserved pages
per zone, or that we have a real thinko somewhere that allows eating up
the reserves we're supposed to have.

And yes, things like spraying the box really hard with network packets can
temporarily eat up the reserves, but that's why kswapd and friends exist,
to get them back. But I could easily imagine that there are more schedule
points missing that could cause user mode to not get to run much. Andrea
fixed one, I think.

If there are more situations like this, please get a stack trace on the
deadlock (fairly easy these days with ctrl-scrolllock), and let's think
about what make for the nasty pattern in the first place instead of trying
to add more "reserved" pages.

For example, maybe we can use HIGHMEM pages more aggressively in some
places, to avoid the case where we're only freeing HIGHMEM pages and
making the non-HIGHMEM case just worse. 

For example, we used to have logic in swapout_process to _not_ swap out
zones that don't need it. We changed swapout to happen in
"page_launder()", but that logic got lost. It's entirely possible that we
should just say "don't bother writing out dirty pages that are in zones
that have no memory pressure", so that we don't use up pages from the
_precious_ zones to free pages in zones that don't need freeing.

So don't try to paper over this by making up new rules. We should think
about WHY the problem happens in the first place, not about trying to fix
it once it has happened (and see the above as an example of why it might
be happening).

But sometimes the right solution is just to have more reserves.

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: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

2001-05-25 Thread Edgar Toernig


Daniel Phillips wrote:
> 
> Oops, oh wait, there's already another open point: your breakage
> examples both rely on opening ".".  You're right, "." should always be
> a directory and I believe that's enforced by the VFS.  So we don't have
> an example of breakage yet.

That's just because I did a simple "ls".  But it doesn't make a
difference.  The magicdevs _are_ directories and

chdir("magicdev");
open(".", O_RDONLY);

shouldn't open the device.

Ciao, ET.

-
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: Alpha SMP Low Outbound Bandwidth

2001-05-25 Thread George France


Hello Andrea,

Jay, if the problem still exist in 2.4.5-pre6aa1 (please try the new kernel), 
then I will have tech op's check this on Tuesday (Monday is a US holiday).  
We should be able to duplicate this in the hardware lab and find the problem 
with a logic analyser.

Best Regards,


--George

On Friday 25 May 2001 20:51, Andrea Arcangeli wrote:
> On Fri, May 25, 2001 at 05:25:03PM -0700, Jay Thorne wrote:
> > But Wu-ftpd is an easy to set up test bench, and is ubiquitous enough
> > that anyone with an alpha running SMP can test it. Note that this
>
> My smp alpha box drives a single tulip over 12MB/sec in full duplex
> using tcp without any problem at all. So I definitely cannot reproduce.
> You may want to try to reproduce with 2.4.5pre6aa1 btw. If you've not
> tried it yet you can consider also using egcs 1.1.2 as compiler just in
> case.
>
> You may also want to keep an eye on the VM, on alpha I see very weird
> things happening.
>
> Andrea
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Adam J. Richter

Larry McVoy wrote:
>On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote:
>>  Contracts for slavery are specifically not enforceable due to
>> the 13th Amendment, and there is also a stronger question of formation

>Completely misses the point.  THe point isn't about slavery, come on, Adam,
>it's about putting unenforceable things into contracts.

The point is you have to agree to the contract that is the
GPL to get the right to make a copy of a GPL'ed work.  You raised
the ridiculous example of slavery apparently as an analogy to the
requirements of permissions on copying conditions that go beyond
restrictions one is subject to anyway by copyright.  The point
is that you can make require someone to agree to conditions that
go beyond the restrictions already imposed by copyright in exchange
for permission to, for example, make a copy, so your argument about
the boundaries of copyright is inapplicable.  The GPL is enforceable.

>It's also about the concept of boundaries - if you think that that 
>concept is not a legal one then why aren't all programs which are run
>on top of a GPLed kernel then GPLed?

Apparently Linus felt that that was a sufficiently
plausible gray area that he addressed it explicitly in
/usr/src/linux/COPYING:

|   NOTE! This copyright does *not* cover user programs that use kernel
| services by normal system calls - this is merely considered normal use
| of the kernel, and does *not* fall under the heading of "derived work".
| Also note that the GPL below is copyrighted by the Free Software
| Foundation, but the instance of code that it refers to (the Linux
| kernel) is copyrighted by me and others who actually wrote it.

I believe you could enforce copying conditions on a kernel
where, in order to have the right to make a copy of the kernel, you
agree only to run certain types of programs.  I believe Windows CE
has historically been "licensed" this way.

I did not say that you cannot define boundaries and I also
think you can even make inferences that a judge is likely to agree
with.  What I am saying is that in order to have the right to make
a copy of the of the GPL'ed code in the keyspan_usa drivers, you
must agree to everything the GPL requires, and those requirements
do not have to be limited to the boundaries of the author's existing
copyright.  The GPL is a contract.  If you don't agree to it, don't
do anything with GPL'ed material that the copyright monopoly restricts.

I am not a lawyer, so please do not rely on this as legal advice.

Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."
-
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-2.4.5


On Fri, May 25, 2001 at 10:49:38PM -0400, Ben LaHaise wrote:
> Highmem.  0 free pages in ZONE_NORMAL.  Now try to allocate a buffer_head.

That's a longstanding deadlock, it was there the first time I read
fs/buffer.c, nothing related to highmem, we have it in 2.2 too. Also
getblk is deadlock prone in a smiliar manner.

Can you try to simply change NR_RESERVED to say 200*MAX_BUF_PER_PAGE and
see if it makes a difference? The unused_list logic doesn't give a
guarantee either and it's one of the "hiding" logics, but it was working
pretty well usually, maybe something changed that needs more than 2
pages (16 bh) reserved?

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Larry McVoy


On Fri, May 25, 2001 at 07:34:57PM -0700, Adam J. Richter wrote:
>   Contracts for slavery are specifically not enforceable due to
> the 13th Amendment, and there is also a stronger question of formation

Completely misses the point.  THe point isn't about slavery, come on, Adam,
it's about putting unenforceable things into contracts.

It's also about the concept of boundaries - if you think that that 
concept is not a legal one then why aren't all programs which are run
on top of a GPLed kernel then GPLed?
-- 
---
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: [with-PATCH-really] highmem deadlock removal, balancing & cleanup

On Fri, May 25, 2001 at 10:01:37PM -0400, Ben LaHaise wrote:
> On Sat, 26 May 2001, Andrea Arcangeli wrote:
> 
> > On Fri, May 25, 2001 at 09:38:36PM -0400, Ben LaHaise wrote:
> > > You're missing a few subtle points:
> > >
> > >   1. reservations are against a specific zone
> >
> > A single zone is not used only for one thing, period. In my previous
> > email I enlighted the only conditions under which a reserved pool can
> > avoid a deadlock.
> 
> Well, until we come up with a better design for a zone allocator that
> doesn't involve walking lists and polluting the cache all over the place,
> it'll be against a single zone.

I meant each zone is used by more than one user, that definitely won't
change.

> > >   2. try_to_free_pages uses the swap reservation
> >
> > try_to_free_pages has an huge stacking under it, bounce
> > bufferes/loop/nbd/whatever being just some of them.
> 
> Fine, then add one to the bounce buffer allocation code, it's all of about
> 3 lines added.

Yes, you should add it to the bounce buffers to the loop to nbd to
whatever and then remove it from all other places that you put into it
right now. That's why I'm saying your patch won't fix anything (but
hide) as it was in its first revision.

> I never said you didn't.  But Ingo's patch DOES NOT PROTECT AGAINST
> DEADLOCKS CAUSED BY INTERRUPT ALLOCATIONS.  Heck, it doesn't even fix the

It does, but only for the create_bounces. As said if you want to "fix",
not to "hide" you need to address every single case, a generic reserved
pool is just useless. Now try to get a dealdock in 2.4.5 with tasks
locked up in create_bounces() if you say it does not protect against
irqs. see?

> That said, the reservation concept is generic code, which the bounce
> buffer patch most certainly isn't.  It can even be improved to overlap

What I said is that instead of handling the pool by hand in every single
place one could write an API to generalize it, but very often a simple
API hooked into the page allocator may not be flexible enough to
guarantee the kind of allocations we need, highmem is just one example
where we need more flexibility not just for the pages but also for the
bh (but ok that's mostly an implementation issue, if you do the math
right, it's harder but you can still use a generic API).

> with the page cache pages in the zone, so it isn't even really "free" ram
> as currently implemented.

yes that would be a very nice property, again I'm not against a generic
interface for creating reserved pool of memory (I mentioned that
possibilty before reading your patch after all). It's just the
implemetation (mainly the per-task hook overwritten) that didn't
convinced me and the usage that was at least apparently obviously wrong
to my eyes.

> Re-read the above and reconsider.  The reservation doesn't need to be
> permitted until after page_alloc has blocked.  Heck, do a schedule before

I don't see what you mean here, could you elaborate?

> Atomicity isn't what I care about.  It's about being able to keep memory
> around so that certain allocations can proceed, and those pools cannot be
> eaten into by other tasks.  [..]

Those pools needs to be gloabl unless
you want to allocate them at fork() for every single task like you did
for some the kernel threads, and if you make them global per-zone or
per-whatever not every single case it will deadlock.  Or better it will
works by luck, it proceeds until you don't have a case where you didn't
only needed 32 pages reserved, but where you needed 33 pages reserved to
avoid the deadlock, it's on the same lines of the pci_map_* brokeness in
some sense.

Allocating those pools per-task is just a total waste, those are
"security" pools, in the 99% of cases you won't need them and you will
allocate the memory dynamically, they just needs to be there for
correctness and to avoid the dealdock very seldom.

Andrea
-
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-2.4.5

On Fri, May 25, 2001 at 09:39:36PM -0400, Ben LaHaise wrote:
> Sorry, this doesn't fix the problem.  It still hangs on highmem machines.
> Try running cerberus on a PAE kernel sometime.

There can be more bugs of course, two patches I posted are only meant to
fix deadlocks in the allocation fail path of alloc_bounces() and the
second patch in getblk() allocation fail path, nothing more. Those are
strictly necessary fixes as far I can tell, and their implementation was
quite obviously right to my eyes.

Now if you send some debugging info with deadlocks you gets with 2.4.5
vanilla I will be certainly interested to found their source. Also Rik
just said to have a fix for other bugs in that area, I didn't checked
that part.

What I can say is that with my tree I didn't reproduced deadlocks
highmem related with cerberus but I'm using highmem emulation not real
highmem.

Andrea
-
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: [with-PATCH-really] highmem deadlock removal, balancing & cleanup

On Fri, May 25, 2001 at 09:38:36PM -0400, Ben LaHaise wrote:
> You're missing a few subtle points:
> 
>   1. reservations are against a specific zone

A single zone is not used only for one thing, period. In my previous
email I enlighted the only conditions under which a reserved pool can
avoid a deadlock.

>   2. try_to_free_pages uses the swap reservation

try_to_free_pages has an huge stacking under it, bounce
bufferes/loop/nbd/whatever being just some of them.

>   3. irqs can no longer eat memory allocations that are needed for
>  swap

you don't even need irq to still deadlock.

> Note that with this patch the current garbage in the zone structure with
> pages_min (which doesn't work reliably) becomes obsolete.

The "garbage" is just an heuristic to allow atomic allocation to work in
the common case dynamically. Anything deadlock related cannot rely on
pages_min.

I am talking about fixing the thing, of course I perfectly know you can
hide it pretty well, but I definitely hate those kind of hiding patches.

> > The only case where a reserved pool make sense is when you know that
> > waiting (i.e. running a task queue, scheduling and trying again to
> > allocate later) you will succeed the allocation for sure eventually
> > (possibly with a FIFO policy to make also starvation impossible, not
> > only deadlocks). If you don't have that guarantee those pools
> > atuomatically become only a sourcecode and runtime waste, possibly they
> > could hide core bugs in the allocator or stuff like that.
> 
> You're completely wrong here.

I don't think so.

Andrea
-
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: [with-PATCH-really] highmem deadlock removal, balancing & cleanup

On Sat, 26 May 2001, Andrea Arcangeli wrote:

> Please merge this one in 2.4 for now (originally from Ingo, I only
> improved it), this is a real definitive fix

With the only minor detail being that it DOESN'T WORK.

You're not solving the problems of GFP_BUFFER allocators
looping forever in __alloc_pages(), the deadlock can still
happen.

You've only solved the 1 specific case of highmem.c getting
a page for bounce buffers, but you'll happily let the thing
deadlock while trying to get buffer heads for a normal low
memory 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)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Larry McVoy


On Fri, May 25, 2001 at 03:30:20PM -0700, Aaron Lehmann wrote:
> On Fri, May 25, 2001 at 11:30:38AM -0700, Larry McVoy wrote:
> > By running the software covered by this license, you agree to 
> > become my personal slave and you will be obligated to bring
> > me coffee each morning for the rest of my life, greating
> > me with a "Good morning, master, here is your coffee oh
> > most magnificent one".
> 
> Wow, when I read that I thought immediatelyly of the LMbench
> "licence"!

If that's true, I have two questions for you:

a) Where is my damn coffee?!?!
b) What about the "Oh master" part?

I've been ripped off.  Where are the license police :-)
-- 
---
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: Linux-2.4.5


On Fri, 25 May 2001, Linus Torvalds wrote:

> Ok, I applied Andrea's (nee Ingo's) version, as that one most clearly
> attacked the real deadlock cause. It's there as 2.4.5 now.

But only for highmem bounce buffers. Normal GFP_BUFFER
allocations can still headlock.

> I'm going to be gone in Japan for the next week

Oh well, I guess people can always run the -ac kernel ;)

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/

Linux-2.4.5



Ok, I applied Andrea's (nee Ingo's) version, as that one most clearly
attacked the real deadlock cause. It's there as 2.4.5 now.

I'm going to be gone in Japan for the next week (leaving tomorrow
morning), so please don't send me patches - I won't be able to react to
them anyway. Consider the -ac series and the kernel mailing list the
regular communications channels..

Thanks,

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: PROBLEM: Alpha SMP Low Outbound Bandwidth

2001-05-25 Thread Michal Jaegermann

On Fri, May 25, 2001 at 02:50:07PM -0700, Jay Thorne wrote:
> [1.] One line summary of the problem:
> Kernel 2.4.4 ac15

> Using a quad 400Mhz Dodge/Rawhide machine with Tulip or VIARhine cards,

[ description of a slowdown skipped ].

Well, it looks that you have at least something to slow down.  I could
not get a single packet through my tulip on Alpha from at least
2.4.4-ac11 and up.  You can consider that an ultimate slowdown.  I tried
also a driver from http://sourceforge.net/projects/tulip/ and results
are the same.  This NIC, Digital DS21143 Tulip rev 65, works just fine
with various earlier kernels, including assorted 2.4.3 variants.
It is on 10baseT netwok - which may, or may not, be relevant here.

  Michal
-
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/

X15 beta 1 - source release

2001-05-25 Thread Fabio Riccardi


Dear all,

I finally managed to package the X15 web accelerator for the first
source release.

The current release includes a CGI module, an Apache configuration
module and several salability improvements. It is a beta 1, quite stable
but it may/will still contain a few bugs. The README is a bit outdated
and the code could use more comments... :)

The code It is released under an Open Source license very much in the
spirit of Sun/Solaris, Apple/Darwin, etc., but less restrictive.

Basically (for what I have been explained by our lawyers :) the license
says that:

 1) you can peruse the code for your own use and/or research in any way
you like,

 2) you can use X15 for your own non commercial use (i.e., you can have
the fastest family reunion pictures website of the planet),

 3) if you want to use the software for any commercial exploitation you
have to buy a license from Chromium Communications,

 4) if you make changes they belong to you, but if you send them back to
us than you agree to not claim anything for them.

You can get the sources from:
http://www.chromium.com/cgi-bin/crosforum/YaBB.pl

or (when the DNS gets propagated) from: http://source.chromium.com/

Our source site sports one of those nifty sourceforge-like interfaces
for discussions, bug reports and whatever, I'd prefer you to use that
instead of sending email directly to me or to this list.

I'll build a proper "product" web page and add more documentation in the
next few days.

 - Fabio


-
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: Alpha SMP Low Outbound Bandwidth

On Fri, May 25, 2001 at 05:25:03PM -0700, Jay Thorne wrote:
> But Wu-ftpd is an easy to set up test bench, and is ubiquitous enough
> that anyone with an alpha running SMP can test it. Note that this

My smp alpha box drives a single tulip over 12MB/sec in full duplex
using tcp without any problem at all. So I definitely cannot reproduce.
You may want to try to reproduce with 2.4.5pre6aa1 btw. If you've not
tried it yet you can consider also using egcs 1.1.2 as compiler just in
case.

You may also want to keep an eye on the VM, on alpha I see very weird
things happening.

Andrea
-
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: [with-PATCH-really] highmem deadlock removal, balancing & cleanup


On Fri, May 25, 2001 at 08:29:38PM -0400, Ben LaHaise wrote:
> amount of bounce buffers to guarentee progress while submitting io.  The
> -ac kernels have a patch from Ingo that provides private pools for bounce
> buffers and buffer_heads.  I went a step further and have a memory
> reservation patch that provides for memory pools being reserved against a
> particular zone.  This is needed to prevent the starvation that irq
> allocations can cause.
> 
> Some of these cleanups are 2.5 fodder, but we really need something in 2.4
> right now, so...

Please merge this one in 2.4 for now (originally from Ingo, I only
improved it), this is a real definitive fix and there's no nicer way to
handle that unless you want to generalize an API for people to generate
private anti-deadlock ("make sure to always make a progress") memory
pools:

diff -urN 2.4.4/mm/highmem.c highmem-deadlock/mm/highmem.c
--- 2.4.4/mm/highmem.c  Sat Apr 28 05:24:48 2001
+++ highmem-deadlock/mm/highmem.c   Sat Apr 28 18:21:24 2001
@@ -159,6 +159,19 @@
spin_unlock(_lock);
 }
 
+#define POOL_SIZE 32
+
+/*
+ * This lock gets no contention at all, normally.
+ */
+static spinlock_t emergency_lock = SPIN_LOCK_UNLOCKED;
+
+int nr_emergency_pages;
+static LIST_HEAD(emergency_pages);
+
+int nr_emergency_bhs;
+static LIST_HEAD(emergency_bhs);
+
 /*
  * Simple bounce buffer support for highmem pages.
  * This will be moved to the block layer in 2.5.
@@ -203,17 +216,72 @@
 
 static inline void bounce_end_io (struct buffer_head *bh, int uptodate)
 {
+   struct page *page;
struct buffer_head *bh_orig = (struct buffer_head *)(bh->b_private);
+   unsigned long flags;
 
bh_orig->b_end_io(bh_orig, uptodate);
-   __free_page(bh->b_page);
+
+   page = bh->b_page;
+
+   spin_lock_irqsave(_lock, flags);
+   if (nr_emergency_pages >= POOL_SIZE)
+   __free_page(page);
+   else {
+   /*
+* We are abusing page->list to manage
+* the highmem emergency pool:
+*/
+   list_add(>list, _pages);
+   nr_emergency_pages++;
+   }
+   
+   if (nr_emergency_bhs >= POOL_SIZE) {
 #ifdef HIGHMEM_DEBUG
-   /* Don't clobber the constructed slab cache */
-   init_waitqueue_head(>b_wait);
+   /* Don't clobber the constructed slab cache */
+   init_waitqueue_head(>b_wait);
 #endif
-   kmem_cache_free(bh_cachep, bh);
+   kmem_cache_free(bh_cachep, bh);
+   } else {
+   /*
+* Ditto in the bh case, here we abuse b_inode_buffers:
+*/
+   list_add(>b_inode_buffers, _bhs);
+   nr_emergency_bhs++;
+   }
+   spin_unlock_irqrestore(_lock, flags);
 }
 
+static __init int init_emergency_pool(void)
+{
+   spin_lock_irq(_lock);
+   while (nr_emergency_pages < POOL_SIZE) {
+   struct page * page = alloc_page(GFP_ATOMIC);
+   if (!page) {
+   printk("couldn't refill highmem emergency pages");
+   break;
+   }
+   list_add(>list, _pages);
+   nr_emergency_pages++;
+   }
+   while (nr_emergency_bhs < POOL_SIZE) {
+   struct buffer_head * bh = kmem_cache_alloc(bh_cachep, SLAB_ATOMIC);
+   if (!bh) {
+   printk("couldn't refill highmem emergency bhs");
+   break;
+   }
+   list_add(>b_inode_buffers, _bhs);
+   nr_emergency_bhs++;
+   }
+   spin_unlock_irq(_lock);
+   printk("allocated %d pages and %d bhs reserved for the highmem bounces\n",
+  nr_emergency_pages, nr_emergency_bhs);
+
+   return 0;
+}
+
+__initcall(init_emergency_pool);
+
 static void bounce_end_io_write (struct buffer_head *bh, int uptodate)
 {
bounce_end_io(bh, uptodate);
@@ -228,6 +296,82 @@
bounce_end_io(bh, uptodate);
 }
 
+struct page *alloc_bounce_page (void)
+{
+   struct list_head *tmp;
+   struct page *page;
+
+repeat_alloc:
+   page = alloc_page(GFP_BUFFER);
+   if (page)
+   return page;
+   /*
+* No luck. First, kick the VM so it doesnt idle around while
+* we are using up our emergency rations.
+*/
+   wakeup_bdflush(0);
+
+   /*
+* Try to allocate from the emergency pool.
+*/
+   tmp = _pages;
+   spin_lock_irq(_lock);
+   if (!list_empty(tmp)) {
+   page = list_entry(tmp->next, struct page, list);
+   list_del(tmp->next);
+   nr_emergency_pages--;
+   }
+   spin_unlock_irq(_lock);
+   if (page)
+   return page;
+
+   /* we need to wait I/O completion */
+   run_task_queue(_disk);
+
+   current->policy |= SCHED_YIELD;
+   __set_current_state(TASK_RUNNING);
+   schedule();
+   goto repeat_alloc;
+}
+
+struct

Re: [Linux-NTFS-Dev] Re: ANN: NTFS new release available (1.1.15)

2001-05-25 Thread Anton Altaparmakov

At 00:59 26/05/2001, Jeff Garzik wrote:
>Anton Altaparmakov wrote:
> > NTFS 1.1.15 - ChangeLog
> > ===
> > - Support for more than 128kiB sized runlists (using vmalloc_32() instead
> > of kmalloc()).
>
>If you are running into kmalloc size limit, please consider some 
>alternative method of allocation.

Why? I was told that's what vmalloc is for. And anyway, Windows NT/2k 
operate on a 256kB sized memory allocation basis and NTFS has been designed 
with this in mind. Breaking away from that is a PITA. I was very happy to 
learn about vmalloc as it solved a lot of my headaches with regards to 
structures being >128kb.

btw. Maybe you, or someone else, can explain me whether vmalloc() will 
always work or whether vmalloc_32() is required? I am thinking of highmem 
pages which vmalloc could return. Would I have to make sure the pages were 
accessible by calling some function or is this done transparently?

>Can you map it into the page cache, as Al Viro has done in recent patches?

If someone would document how the page cache actually works from a kernel 
point of view, perhaps... Sorry, but I haven't had the time to 
go through all the related source to understand it properly. I have an idea 
of how it works conceptually (well, kind of...) but not a deep enough 
understanding to start implementing anything that goes anywhere near the 
page cache.

I would love to move inode metadata to the page cache. That would simplify 
so much in the NTFS driver and would result in an incredible speed boost 
due to getting rid of all the silly copying of data back and forth inside 
the driver as we could just pass pointers around instead (to locked pages 
or other form of internal locking).

>Can you break your allocation into an array of pages, obtained via 
>get_free_page?

No thank you. I would rather have it contiguous or at least logically 
contiguous. I don't care if the pages are physically contiguous as long as 
I can see them as one piece... I mean, ok, I could break up run lists, as 
they are arrays of fixed size structs and the boundary cases would be 
predictable (but still would slow down the code with boundary checks) but 
this doesn't solve the generic problem later on as more things get 
implemented where we encounter variable width structures. It is much 
cleaner and easier to implement using a logically contiguous memory 
allocation IMHO. It's a shame Linux kernel doesn't support this kind of 
stuff (last time I read somewhere about this it said it doesn't anyway. I 
would be happy to be told wrong here).

>If runlists are on-disk structures, can you look at bh->b_data instead of 
>keeping them in memory?

They are not. They are derived from compressed on-disk structures (which 
are re-compressed when updating the inode). Runlists of such large size are 
only needed for A) huge files/directories, B) extremely fragmented 
files/directories, or C) a combination of A and B. (Remembering that 
metadata is stored as files, so the same applies for the metadata itself.)

Best regards,

Anton

-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sf.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: [with-PATCH-really] highmem deadlock removal, balancing & cleanup

On Fri, 25 May 2001, Ben LaHaise wrote:
>
> Highmem systems currently manage to hang themselves quite completely upon
> running out of memory in the normal zone.  One of the failure modes is
> looping in __alloc_pages from get_unused_buffer_head to map a dirty page.
> Another results in looping on allocation of a bounce page for writing a
> dirty highmem page back to disk.

That's not the part of the patch I object to - fixing that is fine.

What I object to it that it special-cases the zone names, even though that
doesn't necessarily make any sense at all.

What about architectures that have other zones? THAT is the kind of
fundmanental design mistake that special-casing DMA and NORMAL is horrible
for.

alloc_pages() doesn't have that kind of problem. To alloc_pages(),
GFP_BUFFER is not "oh, DMA or NORMAL". There, it is simply "oh, use the
zonelist pointed to by GFP_BUFFER". No special casing, no stupid #ifdef
CONFIG_HIGHMEM.

THAT is what I object to.

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: [with-PATCH-really] highmem deadlock removal, balancing & cleanup

On Fri, 25 May 2001, Rik van Riel wrote:
>
> The function do_try_to_free_pages() also gets called when we're
> only short on inactive pages, but we still have TONS of free
> memory. In that case, I don't think we'd actually want to steal
> free memory from anyone.

Well, kmem_cache_reap() doesn't even steal memory from anybody: it just
makes this "tagged for xxx" memory be available to "non-xxx" users too.

And the fact that we're calling do_try_to_free_pages() at all obviously
implies that even if we have memory free, it isn't in the right hands..

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: [with-PATCH-really] highmem deadlock removal, balancing & cleanup

On Fri, 25 May 2001, Linus Torvalds wrote:

> Oh, also: the logic behind the change of the kmem_cache_reap() - instead
> of making it conditional on the _reverse_ test of what it has historically
> been, why isn't it just completely unconditional? You've basically
> dismissed the only valid reason for it to have been (illogically)
> conditional, so I'd have expected that just _removing_ the test is better
> than reversing it like your patch does..
>
> No?

The function do_try_to_free_pages() also gets called when we're
only short on inactive pages, but we still have TONS of free
memory. In that case, I don't think we'd actually want to steal
free memory from anyone.

Moving it into the same if() conditional the other memory
freeers are in would make sense, though ...

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/

-
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: Alpha SMP Low Outbound Bandwidth

2001-05-25 Thread Jay Thorne

On 25 May 2001 19:31:21 -0400, George France wrote:
> On Friday 25 May 2001 19:05, Jay Thorne wrote:
> > On 25 May 2001 18:52:33 -0400, George France wrote:
> > > Hello Jay,
> > >
> > > I see that you are using the tulip driver.  Could you try the de4x5
> > > driver??
> >
> > Its worse: reports 3.1 MBs and 1.6 MBs
> 
> wuftp is not exactly a performance benchmark, have you tried 'netperf'?
> 
> --George

While I agree with you completely that wuftpd is not exactly a
performance leader, this is the simplest way to recreate a problem I was
having with a much more complex setup involving apache and SMP and a
whole bunch of things. 

I posted 2 weeks ago and got no response, I assume because everyone
thought it was my software. After reducing the problem to eliminate the
possibility that my code is the real problem, I'm left with a quite
repeatable state. I have two nearly identical machines, one with 466 mhz
cpus the other with 400mhz, and they both do the same thing. The
via-rhine performs similarly to the de4x5.

Netperf is a pretty good idea. Should not be a cpu bottleneck. Thats a
good thing. So pretty much the same results as wu-ftpd: Note that I used
the 466 mhz quad with a via-rhine, since the 400 locked up and was still
fscking when I started this test.

 Recv   SendSend  
 Socket Socket  Message  Elapsed  
 Size   SizeSize Time Throughput  
 bytes  bytes   bytessecs.10^6bits/sec  

To alpha 87380  16384  1638410.02  39.25   
x86 local87380  16384  163849.99  559.46
alpha local  87380  16384  1638410.01 547.27   
alp to x86   87380  16384  1638410.01  25.77   
another x86  87380  16384  163849.99  553.67   
to same x86  87380  16384  1638410.00  82.79   
and back 87380  16384  1638410.00  93.89   

But Wu-ftpd is an easy to set up test bench, and is ubiquitous enough
that anyone with an alpha running SMP can test it. Note that this
software and the server in question were tested to run at 10+ megabytes
per second with x86 boxes. The server is a PIII500 running 2.4.4, so its
not like I'm comparing apples to oranges. The second x86 is an athlon
600.

So even factoring out wuftp is not helping much here. I'm fairly
convinced that something is strange because after the de4x5 test, the
box locked up. So either a> I have two identically boned 4 cpu boxen
or b> the interprocessor/locking/resource management has some kind of
problem. Note that under uniprocessor I get near identical to x86
performance, clock for clock and no lock ups.

-- 
--
Jay Thorne Manager, Systems & Technology, UserFriendly Media, Inc.

-
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/

AT keyboard optional on i386?

2001-05-25 Thread Pavel Roskin


Hello!

I'm trying to run Linux on a broken motherboard that is constantly
producing random noice on the AT keyboard port. I'm going to use a USB
keyboard, but I cannot get Linux to ignore the AT keyboard port.

Is there any way to disable the AT keyboard? I think the best solution
would be to make it optional, just like almost everything in the kernel,
e.g. PS/2 mouse. Some embedded i386 systems could save a few kilobytes of
RAM by disabling the AT keyboard.

It looks like that other architectures (arm and mips) already have an
option CONFIG_PC_KEYB exactly for that. However, it's a dependent variable
- it's set based on the machine type.

Does anybody have a patch for making AT keyboard optional on i386 or
should I make it myself?

-- 
Regards,
Pavel Roskin

-
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] spin[un]locks revision on new cmpci driver (5.64)

2001-05-25 Thread Alan Cox


> The following patch fixes SMP hangs w/ cmpci v5.64 ( k244-ac17 ).

Let me suggest a different approach

> - -   spin_lock_irqsave(>lock, flags);
>   set_spdifout(s, rate);
> + spin_lock_irqsave(>lock, flags);

Split the various locked versions stuff stuff like set_adc_rate out as
__set_adc_rate which doesnt take the lock, and set_adc_rate which takes the
lock and calls the other one.

That is how several other drivers were done and avoids messy lock/unlocks
some of which in your changes I think introduce races

Ditto for enable_dac as the old code and a newer __enable_dac, as well
I suspect as __set_spdifout (although is that ever called by anyone not
holding the lock ???)

>   init_timer(>midi.timer);
>   s->midi.timer.expires =3D jiffies+1;
>   s->midi.timer.data =3D (unsigned long)s;
> +
> + spin_unlock_irqrestore(>lock, flags);
>   s->midi.timer.function =3D cm_midi_timer;
> + spin_lock_irqsave(>lock, flags);
> +

That one doesnt seem to be needed


-
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] spin[un]locks revision on new cmpci driver (5.64)

2001-05-25 Thread Carlos E Gorges


-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160


HI all,

Finally I discovered my problem :-)

The following patch fixes SMP hangs w/ cmpci v5.64 ( k244-ac17 ).

- --- linux-244ac/drivers/sound/cmpci.c Fri May 25 05:26:27 2001
+++ linux/drivers/sound/cmpci.c Fri May 25 20:14:49 2001
@@ -1,5 +1,4 @@
 /
*/
- -
 /*
  *  cmpci.c  --  C-Media PCI audio driver.
  *
@@ -76,6 +75,10 @@
  *was calling prog_dmabuf with s->lock held, call missing
  *unlock_kernel in cm_midi_release
  *
+ *Fri May 25 2001 - Carlos Eduardo Gorges <[EMAIL PROTECTED]>
+ *- some drivers cleanups
+ *- spin[un]locks revision ( fix SMP support )
+ *
  */
 
 /
*/
@@ -226,10 +229,6 @@
 
 #define SND_DEV_DSP16   5 
 
- -#define  set_dac1_rate   set_adc_rate
- -#define  stop_dac1   stop_adc
- -#define  get_dmadac1 get_dmaadc
- -
 /* - */
 
 struct cm_state {
@@ -342,7 +341,6 @@
 /* - */
 
 static struct cm_state *devs;
- -static struct cm_state *devaudio;
 static unsigned long wavetable_mem;
 
 /* - */
@@ -577,8 +575,8 @@
 {
unsigned long flags;
 
- - spin_lock_irqsave(>lock, flags);
set_spdifout(s, rate);
+   spin_lock_irqsave(>lock, flags);
/* enable AC3 */
if (rate == 48000 || rate == 44100) {
// mute DAC
@@ -697,7 +695,7 @@
if (s->curr_channels <=  2)
set_spdifout(s, rate);
if (s->status & DO_DUAL_DAC)
- - set_dac1_rate(s, rate);
+   set_adc_rate(s, rate);
 }
 
 /* - */
@@ -759,12 +757,16 @@
 
 extern inline void enable_dac(struct cm_state *s)
 {
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
if (!(s->enable & CM_ENABLE_CH1)) {
/* enable channel */
s->enable |= CM_ENABLE_CH1;
outb(s->enable, s->iobase + CODEC_CMI_FUNCTRL0 + 2);
}
maskb(s->iobase + CODEC_CMI_FUNCTRL0, ~8, 0);
+   spin_unlock_irqrestore(>lock, flags);
if (s->status & DO_DUAL_DAC)
enable_adc(s);
 }
@@ -794,7 +796,7 @@
}
spin_unlock_irqrestore(>lock, flags);
if (s->status & DO_DUAL_DAC)
- - stop_dac1(s);
+   stop_adc(s);
 }
 
 static void start_adc(struct cm_state *s)
@@ -819,7 +821,9 @@
if ((s->dma_adc.mapped || s->dma_adc.count > 0) && s->dma_adc.ready) {
/* enable interrupt */
 // maskb(s->iobase + CODEC_CMI_INT_HLDCLR + 2, ~0, 1);
- - enable_dac(s);
+   spin_unlock_irqrestore(>lock, flags);
+   enable_dac(s);
+   spin_lock_irqsave(>lock, flags);
}
spin_unlock_irqrestore(>lock, flags);
 }  
@@ -832,7 +836,9 @@
if ((s->dma_dac.mapped || s->dma_dac.count > 0) && s->dma_dac.ready) {
/* enable interrupt */
maskb(s->iobase + CODEC_CMI_INT_HLDCLR + 2, ~0, 2);
+   spin_unlock_irqrestore(>lock, flags);
enable_dac(s);
+   spin_lock_irqsave(>lock, flags);
}
spin_unlock_irqrestore(>lock, flags);
if (s->status & DO_DUAL_DAC)
@@ -848,7 +854,11 @@
spin_lock_irqsave(>lock, flags);
if ((channels > 2) && (channels <= s->max_channels)
 && (((s->fmt >> CM_CFMT_DACSHIFT) & CM_CFMT_MASK) == (CM_CFMT_STEREO | 
CM_CFMT_16BIT))) {
+
+   spin_unlock_irqrestore(>lock, flags);
set_spdifout(s, 0);
+   spin_lock_irqsave(>lock, flags);
+
if (s->capability & CAN_MULTI_CH_HW) {
// NXCHG
maskb(s->iobase + CODEC_CMI_LEGACY_CTRL + 3, ~0, 0x80);
@@ -880,8 +890,11 @@
fmts |= CM_CFMT_16BIT << CM_CFMT_ADCSHIFT;
fmts |= CM_CFMT_STEREO << CM_CFMT_DACSHIFT;
fmts |= CM_CFMT_STEREO << CM_CFMT_ADCSHIFT;
+
+   spin_unlock_irqrestore(>lock, flags);
set_fmt(s, fmtm, fmts);
- - set_dac1_rate(s, s->ratedac);
+   set_adc_rate(s, s->ratedac);
+   spin_lock_irqsave(>lock, flags);
}
// N4SPK3D, disable 4 speaker mode (analog duplicate)
if (s->speakers > 2)
@@ -925,7 +938,6 @@
db->mapped = db->ready = 0;
 }
 
- -
 /* Ch1 is used for playback, Ch0 is used for recording */
 
 static int prog_dmabuf(struct cm_state *s, unsigned rec)
@@ -939,7 +951,6 @@
unsigned char fmt;
unsigned long flags;
 
- - spin_lock_irqsave(>lock, flags);
fmt = s->fmt;
if (rec) {

Re: [with-PATCH-really] highmem deadlock removal, balancing & cleanup

On Sat, 26 May 2001, Alan Cox wrote:
>
> But Linus is right I think - VM changes often prove 'interesting'. Test it in
> -ac , gets some figures for real world use then plan further

.. on the other hand, thinking more about this, I'd rather be called
"stupid" than "stodgy".

So I think I'll buy some experimentation. That HIGHMEM change is too ugly
to live, though, I'd really like to hear more about why something that
ugly is necessary.

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: ANN: NTFS new release available (1.1.15)

2001-05-25 Thread Jeff Garzik

Anton Altaparmakov wrote:
> NTFS 1.1.15 - ChangeLog
> ===
> - Support for more than 128kiB sized runlists (using vmalloc_32() instead
> of kmalloc()).

If you are running into kmalloc size limit, please consider some
alternative method of allocation.
Can you map it into the page cache, as Al Viro has done in recent
patches?
Can you break your allocation into an array of pages, obtained via
get_free_page?
If runlists are on-disk structures, can you look at bh->b_data instead
of keeping them in memory?

-- 
Jeff Garzik  | Disbelief, that's why you fail.
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/

ANN: NTFS new release available (1.1.15)

2001-05-25 Thread Anton Altaparmakov


Announcing a new NTFS patch (1.1.15). It is generated against kernel 
2.4.4-ac16 but also applies cleanly to -ac17. Quite probably it will apply 
fine to any 2.4.4 kernel (at least 2.4.4-pre5 I think).

How to get the patch


- Wait for one of the next -ac series kernel patches (patch is submitted to 
Alan Cox).
- For the impatient: patch is available (for a while only, for some value 
of while) for download as bzip2 or gzip compressed file from:
 http://www-stu.christs.cam.ac.uk/~aia21/ntfs/
(To apply patch, uncompress it, cd into your kernel directory and type:
 patch -p1 < 
/path/to/patch/ntfs-kernel-2.4.4-ac16-to-ntfs-1.1.15.diff.gz
Then you will need to recompile your kernel and reboot into it.)

NTFS 1.1.15 - ChangeLog
===

- New mount option show_sys_files= to show all system files as normal 
files.
- Support for files and in general any attributes up to the full 2TiB size 
supported by the NTFS filesystem. Note we only support up to 32-bits worth 
of inodes/clusters at this point.
- Support for more than 128kiB sized runlists (using vmalloc_32() instead 
of kmalloc()).
- Fixed races in allocation of clusters and mft records.
- Fixed major bugs in attribute handling / searching / collation.
- Fixed major bugs in compressing a run list into a mapping pairs array.
- Fixed major bugs in inode allocation. Especially file create and mkdir.
- Fixed memory leaks.
- Fixed major bug in inode layout assignment of sequence numbers.
- Lots of other bug fixes I can't think of right now...
- Fixed NULL bug found by the Stanford checker in ntfs_dupuni2map().
- Convert large stack variable to dynamically allocated one in 
ntfs_get_free_cluster_count() (found by Stanford checker).
- New versioning scheme as I was too confused by the date based one... 
(versions prior to this are internal only, never been released to public, 
so you haven't missed the numbers before 1.1.15).

Known bugs and (mis-)features
=

- Do not use the driver for writing as it corrupts the file system. If you 
do use it, get the Linux-NTFS tools and use the ntfsfix utility after 
dismounting a partition you wrote to.

- Use "ls -l" instead of just "ls", otherwise the last entry in the 
directory is not displayed for some directories. (?!?)

- Use the show_sys_files mount option which should make things work 
generally better. (It results in both the short and long file names being 
shown as well as the sytem files.)

- Special characters are not treated correctly. For example if the file 
name contains an apostrophe you will not be able to open it.

- Writing of extension records is not supported properly.

Please send bug reports/comments/feed back/abuse to the Linux-NTFS 
development list at sourceforge: [EMAIL PROTECTED]

For daring people, write support now works ok for simple files and 
directories. For example it is relatively safe to create a directory inside 
a not too big directory, and create a few relatively small files in it. 
umount, run ntfsfix, reboot in Windows, chkdsk will run and (hopefully) not 
detect any problems at all!

Thank you for your attention.

Best regards,

 Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sf.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/

2.4.4-ac17 - missing in exports simple_strtol symbol

2001-05-25 Thread Michal Jaegermann


Patches to drivers/scsi/sg.c included in 2.4.4-ac17 require for
'sg.o' module to use 'simple_strtol' which is not exported in
kernel/ksyms.c.  Is this is an oversight or 'sg.o' should be actually
using something like 'simple_strtoul' - which is already exported?
In either case patches are obvious.

BTW - is tulip supposed to already work in this version?  Because
it does not.

  Michal
  [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: PROBLEM: Alpha SMP Low Outbound Bandwidth

2001-05-25 Thread George France


On Friday 25 May 2001 19:05, Jay Thorne wrote:
> On 25 May 2001 18:52:33 -0400, George France wrote:
> > Hello Jay,
> >
> > I see that you are using the tulip driver.  Could you try the de4x5
> > driver??
>
> Its worse: reports 3.1 MBs and 1.6 MBs

wuftp is not exactly a performance benchmark, have you tried 'netperf'?

--George
-
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: [with-PATCH-really] highmem deadlock removal, balancing & cleanup

On Sat, 26 May 2001, Alan Cox wrote:

> But Linus is right I think - VM changes often prove
> 'interesting'. Test it in -ac , gets some figures for real world
> use then plan further

Oh well. As long as he takes the patch to page_alloc.c, otherwise
everybody _will_ have to "experiment" with the -ac kernels just
to have a system with highmem which doesn't deadlock ;)

cheers,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/

-
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: [with-PATCH-really] highmem deadlock removal, balancing & cleanup




On Fri, 25 May 2001, Rik van Riel wrote:
>
> Without the patch my workstation (with ~180MB RAM) usually has
> between 50 and 80MB of inode/dentry cache and real usable stuff
> gets  swapped out.

All I want is more people giving feedback.

It's clear that neither my nor your machine is a good thing to base things
on.

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: The difference between Linus's kernel and Alan Cox's kernel

2001-05-25 Thread Alan Cox


> Why there are two different kernel trees? There is always the official 
> release, provided by Torvalds, and then Alan provides a patch merging Linus's 
> stuff, and adding (?) tons of bug fixes.

Well it started by accident but it turns out good to have a tree that changes
are merged into, tested by those who need the fixes and reviewed by third
parties before they go to Linus.

So the -ac tree is kind of a peer review, testing and distillation process for
patches.

-
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: Alpha SMP Low Outbound Bandwidth

2001-05-25 Thread Jay Thorne


On 25 May 2001 18:52:33 -0400, George France wrote:
> Hello Jay, 
> 
> I see that you are using the tulip driver.  Could you try the de4x5 driver??
> 
Its worse: reports 3.1 MBs and 1.6 MBs

-- 
--
Jay Thorne Manager, Systems & Technology, UserFriendly Media, Inc.

-
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: [with-PATCH-really] highmem deadlock removal, balancing & cleanup

On Fri, 25 May 2001, Rik van Riel wrote:
>
> Yeah, I guess the way Linux 2.2 balances things is way too
> experimental ;)

Ehh.. Take a look at the other differences between the VM's. Which may
make a 2.2.x approach completely bogus.

And take a look at how long the 2.2.x VM took to stabilize, and how
INCREDIBLY BAD some of those kernels were.

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: ac15 and 2.4.5-pre6, pwc format conversion

2001-05-25 Thread Alan Cox


> all at the same time). I will *not* have a crippled driver into the Lin=
> ux
> kernel. If this is going to be policy, fine. But then this policy will =
> apply
> to ALL drivers equally, not just mine because suddenly Alan realizes he=

I've had the others on the list for a while too, jus this one was very easy
to fix and mindbogglingly annoying

> been sleeping for the past 5 years and decides to implement a policy ha=
> rdly
> noone ever knew existed.

The policy has been there since day 1. This is a kernel not a library. You've
written some very nice conversion library routines and I do hope you contribute
those in userspace where they belong

-
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: Alpha SMP Low Outbound Bandwidth

2001-05-25 Thread George France


Hello Jay, 

I see that you are using the tulip driver.  Could you try the de4x5 driver??

Best Regards,


--George


On Friday 25 May 2001 17:50, Jay Thorne wrote:
> [1.] One line summary of the problem:
> Kernel 2.4.4 ac15
> Tested with several cards and pieces of software, the outbound bandwidth
> on a quad cpu alpha is 2 megabytes a second or less on a 100 mbit
> switched ethernet network. Other machines on same switch do 10 or more
> megabytes per second. Switch is DLink 3624, 24 port, only 12 ports in
> use.
>
> [2.] Full description of the problem/report:
> Using a quad 400Mhz Dodge/Rawhide machine with Tulip or VIARhine cards,
> on wuFTP, the outbound bandwidth tops out at 2 megabytes per second and
> the inbound at 6 megabytes per second.  Also noticeable are apparent
> slowdowns or console lockups/sluggishness during the transfer.
>
> [3.] Keywords (i.e., modules, networking, kernel):
> networking, alpha, tulip, via_rhine
>
> [4.] Kernel version (from /proc/version):
> Linux version 2.4.4-ac15 (root@lister) (gcc version 2.96 2731 (SuSE
> Linux 7.1/Alpha)) #1 SMP Thu May 24 18:41:13 PDT 2001
>
> [5.] Output of Oops.. message (if applicable) with symbolic information
>  resolved (see Documentation/oops-tracing.txt)
>
> [6.] A small shell script or example program which triggers the
>  problem (if possible)
>
> Problem machine:
> ncftp /tmp > put foo
> foo:34.38 MB5.16
> MB/s
> ncftp /tmp > get -z foo baz
> baz:34.38 MB1.16
> MB/s
>
> other machine on same switch to same ftp server.
> ncftp /home/jay > get foo
> foo:34.38 MB   10.12
> MB/s
> ncftp /home/jay > put -z foo baz
> foo:34.38 MB9.93
> MB/s
>
> [7.] Environment
> [7.1.] Software (add the output of the ver_linux script here)
>
> Linux lister 2.4.4-ac15 #1 SMP Thu May 24 18:41:13 PDT 2001 alpha
> unknown
>
> Gnu C  2.96
> Gnu make   3.79.1
> binutils   2.10.0.33
> util-linux 2.10q
> mount  2.10q
> modutils   2.4.2
> e2fsprogs  1.19
> pcmcia-cs  3.1.22
> PPP2.4.0
> isdn4k-utils   3.1pre1a
> Linux C Libraryso.6.1
> Dynamic linker (ldd)   2.2
> Procps 2.0.7
> Net-tools  1.57
> Kbd1.02
> Sh-utils   2.0
> Modules Loaded tulip via-rhine
>
> [7.2.] Processor information (from /proc/cpuinfo):
> lister:/usr/src/linux # cat /proc/cpuinfo
> cpu : Alpha
> cpu model   : EV56
> cpu variation   : 7
> cpu revision: 0
> cpu serial number   :
> system type : Rawhide
> system variation: Dodge
> system revision : 0
> system serial number: NI70904KB0
> cycle frequency [Hz]: 4
> timer frequency [Hz]: 1200.00
> page size [bytes]   : 8192
> phys. address bits  : 40
> max. addr. space #  : 127
> BogoMIPS: 738.12
> kernel unaligned acc: 1646246
> (pc=fc42a3d8,va=fc005d9b784e)
> user unaligned acc  : 0 (pc=0,va=0)
> platform string : AlphaServer 4100 5/400 4MB
> cpus detected   : 4
> cpus active : 4
> cpu active mask : 000f
>
> [7.3.] Module information (from /proc/modules):
> lister:/usr/src/linux # cat /proc/modules
> tulip  59296   1
> via-rhine  16464   0 (autoclean)
>
> [7.4.] Loaded driver and hardware information (/proc/ioports,
> /proc/iomem)
> lister:/usr/src/linux # cat /proc/ioports
> - : PCI IO bus 0
>   -001f : dma1
>   0020-003f : pic1
>   0040-005f : timer
>   0060-006f : keyboard
>   0070-0080 : rtc
> 0070-007f : rtc
>   00a0-00bf : pic2
>   00c0-00df : dma2
>   02f8-02ff : serial(auto)
>   03f8-03ff : serial(auto)
>   8000-80ff : VIA Technologies, Inc. Ethernet Controller
> 8000-80ff : via-rhine
>   8400-847f : Digital Equipment Corporation DECchip 21140
> [FasterNet]
> 8400-847f : tulip
> 2-2 : PCI IO bus 1
>   28000-280ff : Symbios Logic Inc. (formerly NCR) 53c810
> 28000-2807f : ncr53c8xx
>   29000-290fe : qlogicisp
> lister:/usr/src/linux # cat /proc/iomem
> - : PCI mem bus 0
>   -07ff : HAE0
> 0220-0223 : Digital Equipment Corporation DECchip 21140
> [FasterNet]
> 0224-0224 : S3 Inc. 86c764/765 [Trio32/64/64V+]
> 0225-0225 : VIA Technologies, Inc. Ethernet Controller
> 0226-022600ff : VIA Technologies, Inc. Ethernet Controller
>   0226-022600ff : via-rhine
> 02261000-0226107f : Digital Equipment Corporation DECchip 21140
>

Re: [PATCH] fbdev logo (fwd)

2001-05-25 Thread Disconnect


Ditto - I'd like at least an option of the "incorrect" logo.  I can
(sorta) see not having it as the default.  But perhaps under the
'experimental drivers' tag, have an option of "Politically incorrect
framebuffer logo".  (If there isn't a huge outcry against it, I may work
up a patch - been meaning to get into kernel stuff, and this seems
relatively harmless.)

On Fri, 25 May 2001, Dr. Kelsey Hudson did have cause to say:

> On Thu, 10 May 2001, Geert Uytterhoeven wrote:
> >   - Political fixes:
> >   o There were still some penguins left carrying a glass of beer or wine.
> > This problem is about 2 years old!
> 
> I still don't understand why the penguin holding beer/wine was wrong...
> 
>  Kelsey Hudson   [EMAIL PROTECTED]
>  Software Engineer
>  Compendium Technologies, Inc   (619) 725-0771
> ---
> 
> -
> 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/
---
   _.-==-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P- L+++>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE 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: [with-PATCH-really] highmem deadlock removal, balancing & cleanup

On Fri, 25 May 2001, Linus Torvalds wrote:
> On Fri, 25 May 2001, Rik van Riel wrote:
> >
> > OK, shoot me.  Here it is again, this time _with_ patch...
>
> I'm not going to apply this as long as it plays experimental
> games with "shrink_icache()" and friends. I haven't seen anybody
> comment on the performance on this, and I can well imagine that
> it would potentially shrink the dcache too aggressively when
> there are lots of inactive-dirty pages around, where
> page_launder is the right thing to do, and shrinking
> icache/dcache might not be.

Your analysis exactly describes what happens in your current
code, though I have to admit that my patch doesn't change it.

Without the patch my workstation (with ~180MB RAM) usually has
between 50 and 80MB of inode/dentry cache and real usable stuff
gets  swapped out.

Either you can go make Linux 2.4 usable again for normal people,
or you can go buy us all a gig of ram.

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Aaron Lehmann

On Fri, May 25, 2001 at 11:30:38AM -0700, Larry McVoy wrote:
>   By running the software covered by this license, you agree to 
>   become my personal slave and you will be obligated to bring
>   me coffee each morning for the rest of my life, greating
>   me with a "Good morning, master, here is your coffee oh
>   most magnificent one".

Wow, when I read that I thought immediatelyly of the LMbench
"licence"!
-
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: [with-PATCH-really] highmem deadlock removal, balancing & cleanup


On Fri, 25 May 2001, Linus Torvalds wrote:
> On Fri, 25 May 2001, Rik van Riel wrote:
> >
> > OK, shoot me.  Here it is again, this time _with_ patch...
>
> I'm not going to apply this as long as it plays experimental games with
> "shrink_icache()" and friends. I haven't seen anybody comment on the
> performance on this,

Yeah, I guess the way Linux 2.2 balances things is way too
experimental ;)


Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/

-
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: Disabling interrupts before block device request call

2001-05-25 Thread Jens Axboe


On Fri, May 25 2001, Alexandr Andreev wrote:
> Hi, list
> In ll_rw_block.c, before calling block device specific request function 
> ( i mean do_hd_request, do_ftl_request, ... ) the io_request_lock is 
> locking, and all interrupts are disabling. I know, that request handler 
> routine have to be atomic, but when we read data from a flash device ( 
> for example ) we use a timeouts. Where do we have to enable timer 
> interrupts, or should we disable all interrupts?

Even with dropping io_request_lock, it's not recommended to sleep inside
the request_fn. WIth plugging, you are basically preventing the other
plugged queues from being run until you return.

You could use a timer or similar to call you on a specified timeout
instead.

-- 
Jens Axboe

-
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: The difference between Linus's kernel and Alan Cox's kernel

2001-05-25 Thread Erik Mouw


On Sat, May 26, 2001 at 07:40:18AM +1000, CaT wrote:
> On Fri, May 25, 2001 at 11:32:18PM +0200, Erik Mouw wrote:
> > I just added this to the kernelnewbies FAQ:
> > 
> >   http://www.kernelnewbies.org/faq.php3
> 
> Typo: First para, last sentence: s/Linux/Linus/

Oops. Fixed, thanks.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
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: Alpha SMP Low Outbound Bandwidth

2001-05-25 Thread Jay Thorne


[1.] One line summary of the problem:
Kernel 2.4.4 ac15
Tested with several cards and pieces of software, the outbound bandwidth
on a quad cpu alpha is 2 megabytes a second or less on a 100 mbit
switched ethernet network. Other machines on same switch do 10 or more
megabytes per second. Switch is DLink 3624, 24 port, only 12 ports in
use.

[2.] Full description of the problem/report:
Using a quad 400Mhz Dodge/Rawhide machine with Tulip or VIARhine cards,
on wuFTP, the outbound bandwidth tops out at 2 megabytes per second and
the inbound at 6 megabytes per second.  Also noticeable are apparent
slowdowns or console lockups/sluggishness during the transfer.

[3.] Keywords (i.e., modules, networking, kernel):
networking, alpha, tulip, via_rhine

[4.] Kernel version (from /proc/version):
Linux version 2.4.4-ac15 (root@lister) (gcc version 2.96 2731 (SuSE
Linux 7.1/Alpha)) #1 SMP Thu May 24 18:41:13 PDT 2001

[5.] Output of Oops.. message (if applicable) with symbolic information
 resolved (see Documentation/oops-tracing.txt)

[6.] A small shell script or example program which triggers the
 problem (if possible)

Problem machine:
ncftp /tmp > put foo
foo:34.38 MB5.16
MB/s
ncftp /tmp > get -z foo baz
baz:34.38 MB1.16
MB/s

other machine on same switch to same ftp server.
ncftp /home/jay > get foo
foo:34.38 MB   10.12
MB/s
ncftp /home/jay > put -z foo baz
foo:34.38 MB9.93
MB/s

[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
 
Linux lister 2.4.4-ac15 #1 SMP Thu May 24 18:41:13 PDT 2001 alpha
unknown
 
Gnu C  2.96
Gnu make   3.79.1
binutils   2.10.0.33
util-linux 2.10q
mount  2.10q
modutils   2.4.2
e2fsprogs  1.19
pcmcia-cs  3.1.22
PPP2.4.0
isdn4k-utils   3.1pre1a
Linux C Libraryso.6.1
Dynamic linker (ldd)   2.2
Procps 2.0.7
Net-tools  1.57
Kbd1.02
Sh-utils   2.0
Modules Loaded tulip via-rhine

[7.2.] Processor information (from /proc/cpuinfo):
lister:/usr/src/linux # cat /proc/cpuinfo
cpu : Alpha
cpu model   : EV56
cpu variation   : 7
cpu revision: 0
cpu serial number   :
system type : Rawhide
system variation: Dodge
system revision : 0
system serial number: NI70904KB0
cycle frequency [Hz]: 4
timer frequency [Hz]: 1200.00
page size [bytes]   : 8192
phys. address bits  : 40
max. addr. space #  : 127
BogoMIPS: 738.12
kernel unaligned acc: 1646246
(pc=fc42a3d8,va=fc005d9b784e)
user unaligned acc  : 0 (pc=0,va=0)
platform string : AlphaServer 4100 5/400 4MB
cpus detected   : 4
cpus active : 4
cpu active mask : 000f

[7.3.] Module information (from /proc/modules):
lister:/usr/src/linux # cat /proc/modules
tulip  59296   1
via-rhine  16464   0 (autoclean)

[7.4.] Loaded driver and hardware information (/proc/ioports,
/proc/iomem)
lister:/usr/src/linux # cat /proc/ioports
- : PCI IO bus 0
  -001f : dma1
  0020-003f : pic1
  0040-005f : timer
  0060-006f : keyboard
  0070-0080 : rtc
0070-007f : rtc
  00a0-00bf : pic2
  00c0-00df : dma2
  02f8-02ff : serial(auto)
  03f8-03ff : serial(auto)
  8000-80ff : VIA Technologies, Inc. Ethernet Controller
8000-80ff : via-rhine
  8400-847f : Digital Equipment Corporation DECchip 21140
[FasterNet]
8400-847f : tulip
2-2 : PCI IO bus 1
  28000-280ff : Symbios Logic Inc. (formerly NCR) 53c810
28000-2807f : ncr53c8xx
  29000-290fe : qlogicisp
lister:/usr/src/linux # cat /proc/iomem
- : PCI mem bus 0
  -07ff : HAE0
0220-0223 : Digital Equipment Corporation DECchip 21140
[FasterNet]
0224-0224 : S3 Inc. 86c764/765 [Trio32/64/64V+]
0225-0225 : VIA Technologies, Inc. Ethernet Controller
0226-022600ff : VIA Technologies, Inc. Ethernet Controller
  0226-022600ff : via-rhine
02261000-0226107f : Digital Equipment Corporation DECchip 21140
[FasterNet]
  02261000-0226107f : tulip
2-2 : PCI mem bus 1
  2-207ff : HAE0
20220-2022000ff : Symbios Logic Inc. (formerly NCR) 53c810

[7.5.] PCI information ('lspci -vvv' as root)
lister:/usr/src/linux # lspci -vvv
00:01.0 Non-VGA unclassified device: Intel Corporation 82375EB (rev 05)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr-

Re: [timer] max timeout

2001-05-25 Thread Horst von Brand


Mark Frazer <[EMAIL PROTECTED]> said:

[...]

> The output of `find . -type f | xargs grep 'jiffies +'` would suggest
> that there are a few latent bugs as jiffies grows to values near the
> top of its range.  I guess this hasn't turned up as 0x7fff / (100 *
> 3600 * 24) = 248.55.

There were patches floating around a _long_ time ago (2.1-ish AFAIR) that
allowed you to start your system at any jiffy. Many people checked out what
happens on jiffie rollover then. Might be a good idea to do that again...
-- 
Dr. Horst H. von Brand   mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
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] winbond update

2001-05-25 Thread Manfred Spraul


I'll send the attached patch to Alan soon, please test it.

Main changes:
* powerpc support added. Tested with ppc 603e.
* memory leak in _close fixed.
* initial power management support
* ethtool support merged
* SMP synchronization updated.
* improved link detection. This change could cause problems, but it's
required for proper switching between nway and pre-nway link partners,
at least with my PHY.

Tested with -ac11, patch also applies against 2.4.4 and 2.4.4-ac17.

--
Manfred

--- 2.4/drivers/net/winbond-840.c   Fri May 25 22:36:10 2001
+++ build-2.4/drivers/net/winbond-840.c Fri May 25 23:23:07 2001
@@ -32,12 +32,22 @@
synchronize tx_q_bytes
software reset in tx_timeout
Copyright (C) 2000 Manfred Spraul
+   * further cleanups
+   power management.
+   support for big endian descriptors
+   ethtool ioctl merged from gkernel.
+   Copyright (c) 2001 Manfred Spraul
 
TODO:
-   * according to the documentation, the chip supports big endian
-   descriptors. Remove cpu_to_le32, enable BE descriptors.
+   * enable pci_power_off
+   * Wake-On-LAN
 */
 
+#define DRV_NAME   "winbond-840"
+#define DRV_VERSION"1.01-b"
+#define DRV_RELDATE"5/15/2000"
+
+
 /* Automatically extracted configuration info:
 probe-func: winbond840_probe
 config-in: tristate 'Winbond W89c840 Ethernet support' CONFIG_WINBOND_840
@@ -79,10 +89,13 @@
Making the Tx ring too large decreases the effectiveness of channel
bonding and packet priority.
There are no ill effects from too-large receive rings. */
-#define TX_RING_SIZE   16
+#define TX_RING_SIZE   16  
 #define TX_QUEUE_LEN   10  /* Limit ring entries actually used.  */
+#define TX_QUEUE_LEN_RESTART   5
 #define RX_RING_SIZE   32
 
+#define TX_BUFLIMIT(1024-128)
+
 /* The presumed FIFO size for working around the Tx-FIFO-overflow bug.
To avoid overflowing we don't queue again until we have room for a
full-size packet.
@@ -90,7 +103,6 @@
 #define TX_FIFO_SIZE (2048)
 #define TX_BUG_FIFO_LIMIT (TX_FIFO_SIZE-1514-16)
 
-#define TX_BUFLIMIT(1024-128)
 
 /* Operational parameters that usually are not changed. */
 /* Time in jiffies before concluding the transmitter is hung. */
@@ -122,13 +134,17 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include  /* Processor type for cache alignment. */
 #include 
 #include 
+#include 
 
 /* These identify the driver base version and may not be removed. */
 static char version[] __devinitdata =
-KERN_INFO "winbond-840.c:v1.01 (2.4 port) 5/15/2000  Donald Becker 
<[EMAIL PROTECTED]>\n"
+KERN_INFO DRV_NAME ".c:v" DRV_VERSION DRV_RELDATE "  Donald Becker 
+<[EMAIL PROTECTED]>\n"
 KERN_INFO "  http://www.scyld.com/network/drivers.html\n;;
 
 MODULE_AUTHOR("Donald Becker <[EMAIL PROTECTED]>");
@@ -183,6 +199,8 @@
 correctly detect a full FIFO, and queuing more than 2048 bytes may result in
 silent data corruption.
 
+Test with 'ping -s 1' on a fast computer.
+
 */
 
 
@@ -198,7 +216,7 @@
 PCI_ADDR_64BITS=0x100, PCI_NO_ACPI_WAKE=0x200, PCI_NO_MIN_LATENCY=0x400,
 };
 enum chip_capability_flags {
-   CanHaveMII=1, HasBrokenTx=2, AlwaysFDX=4, FDXOnNoMII=8,};
+   CanHaveMII=1, AlwaysFDX=2, FDXOnNoMII=4};
 #ifdef USE_IO_OPS
 #define W840_FLAGS (PCI_USES_IO | PCI_ADDR0 | PCI_USES_MASTER)
 #else
@@ -226,11 +244,11 @@
 static struct pci_id_info pci_id_tbl[] = {
{"Winbond W89c840", /* Sometime a Level-One switch card. */
 { 0x08401050, 0x, 0x8153, 0x },
-W840_FLAGS, 128, CanHaveMII | HasBrokenTx | FDXOnNoMII},
+W840_FLAGS, 128, CanHaveMII | FDXOnNoMII},
{"Winbond W89c840", { 0x08401050, 0x, },
-W840_FLAGS, 128, CanHaveMII | HasBrokenTx},
+W840_FLAGS, 128, CanHaveMII },
{"Compex RL100-ATX", { 0x20F6, 0x,},
-W840_FLAGS, 128, CanHaveMII | HasBrokenTx},
+W840_FLAGS, 128, CanHaveMII },
{0,},   /* 0 terminated list. */
 };
 
@@ -302,7 +320,7 @@
 struct w840_tx_desc {
s32 status;
s32 length;
-   u32 buffer1, buffer2;   /* We use only buffer 1.  */
+   u32 buffer1, buffer2;
 };
 
 /* Bits in network_desc.status */
@@ -335,30 +353,31 @@
unsigned int cur_rx, dirty_rx;  /* Producer/consumer ring indices */
unsigned int rx_buf_sz; /* Based on MTU+slack. */
unsigned int cur_tx, dirty_tx;
-   int tx_q_bytes;
-   unsigned int tx_full:1; /* The Tx queue is full. */
+   unsigned int tx_q_bytes;
+   unsigned int tx_full;   /* The Tx queue is full. */
/* These values are keep track of the transceiver/media in use. */
unsigned int full_duplex:1;

Re: The difference between Linus's kernel and Alan Cox's kernel

2001-05-25 Thread CaT


On Fri, May 25, 2001 at 11:32:18PM +0200, Erik Mouw wrote:
> On Fri, May 25, 2001 at 05:12:39PM -0300, Thiago Vinhas de Moraes wrote:
> > Why there are two different kernel trees? There is always the official 
> > release, provided by Torvalds, and then Alan provides a patch merging Linus's 
> > stuff, and adding (?) tons of bug fixes.
> 
> I just added this to the kernelnewbies FAQ:
> 
>   http://www.kernelnewbies.org/faq.php3

Typo: First para, last sentence: s/Linux/Linus/

-- 
CaT ([EMAIL PROTECTED])*** Jenna has joined the channel.
 speaking of mental giants..
 me, a giant, bullshit
 And i'm not mental
- An IRC session, 20/12/2000

-
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] kmalloc checks for drivers/ide/ide-probe.c (244ac16)

2001-05-25 Thread Andre Hedrick

On Fri, 25 May 2001, Rasmus Andersen wrote:

> On Fri, May 25, 2001 at 01:47:52PM -0700, Andre Hedrick wrote:
> > 
> > Not valid because the jump to that part of the code is protected.
> > If a polling response for a valid status and no timeout, is detected then
> > it attempts to the command for real only after success or a test.
> > 
> > Otherwise it would be valid.

/*
 * try_to_identify() sends an ATA(PI) IDENTIFY request to a drive
 * and waits for a response.  It also monitors irqs while this is
 * happening, in hope of automatically determining which one is
 * being used by the interface.
 *
 * Returns: 0  device was identified
 *  1  device timed-out (no response to identify request)
 *  2  device aborted the command (refused to identify itself)
 */
static int actual_try_to_identify (ide_drive_t *drive, byte cmd)
{

if (OK_STAT(GET_STAT(),DRQ_STAT,BAD_R_STAT)) {
unsigned long flags;
__save_flags(flags);/* local CPU only */
__cli();/* local CPU only; some systems need this */
do_identify(drive, cmd); /* drive returned ID */
rc = 0; /* drive responded with ID */
(void) GET_STAT();  /* clear drive IRQ */
__restore_flags(flags); /* local CPU only */
} else
rc = 2; /* drive refused ID */
return rc;
}

If you get_stat returns a bad status we do not go into the test loop.

> So the EXABYTE case should return normally, I take (otherwise you
> confused me good;))? The patch below drops this change and keeps
> the rest.

/*
 * probe_for_drive() tests for existence of a given drive using do_probe().
 *
 * Returns: 0  no device was found
 *  1  device was found (note: drive->present might still be 0)
 */
static inline byte probe_for_drive (ide_drive_t *drive)

This calls out for the poke in the ribbon, and if it fail anywhere we
never get to the top function for the kmallocs.

Does that help?

This is potentially valid for modules but if it built in and you are out
of memory before partition checkinggo buy some memory.  Also if you
are adding devices with a system under hard load eating/using memory to
that scale, you will have other issues to go KABOOM.

Will look at it for verification and run a gedanken process and get back
about it.

> 
> --- linux-244-ac16-clean/drivers/ide/ide-probe.c  Fri May 25 21:11:08 2001
> +++ linux-244-ac16/drivers/ide/ide-probe.cFri May 25 22:54:15 2001
> @@ -58,6 +58,11 @@
>   struct hd_driveid *id;
>  
>   id = drive->id = kmalloc (SECTOR_WORDS*4, GFP_ATOMIC);  /* called with 
>interrupts disabled! */
> +if (!id) {
> +printk(KERN_WARNING "(ide-probe::do_identify) Out of memory.\n");
> +goto err_kmalloc;
> +}
> +
>   ide_input_data(drive, id, SECTOR_WORDS);/* read 512 bytes of 
>id info */
>   ide__sti(); /* local CPU only */
>   ide_fix_driveid(id);
> @@ -76,8 +81,7 @@
>   if ((id->model[0] == 'P' && id->model[1] == 'M')
>|| (id->model[0] == 'S' && id->model[1] == 'K')) {
>   printk("%s: EATA SCSI HBA %.10s\n", drive->name, id->model);
> - drive->present = 0;
> - return;
> +goto err_misc;
>   }
>  #endif /* CONFIG_SCSI_EATA_DMA || CONFIG_SCSI_EATA_PIO */
>  
> @@ -111,8 +115,7 @@
>  #ifdef CONFIG_BLK_DEV_PDC4030
>   if (HWIF(drive)->channel == 1 && HWIF(drive)->chipset == ide_pdc4030) {
>   printk(" -- not supported on 2nd Promise port\n");
> - drive->present = 0;
> - return;
> +goto err_misc;
>   }
>  #endif /* CONFIG_BLK_DEV_PDC4030 */
>   switch (type) {
> @@ -174,6 +177,12 @@
>   printk("ATA DISK drive\n");
>   QUIRK_LIST(HWIF(drive),drive);
>   return;
> +
> +err_misc:
> +kfree(id);
> +err_kmalloc:
> +drive->present = 0;
> +return;
>  }
>  
>  /*
> @@ -759,11 +768,23 @@
>   }
>   minors= units * (1<   gd= kmalloc (sizeof(struct gendisk), GFP_KERNEL);
> - gd->sizes = kmalloc (minors * sizeof(int), GFP_KERNEL);
> - gd->part  = kmalloc (minors * sizeof(struct hd_struct), GFP_KERNEL);
> - bs= kmalloc (minors*sizeof(int), GFP_KERNEL);
> - max_sect  = kmalloc (minors*sizeof(int), GFP_KERNEL);
> - max_ra= kmalloc (minors*sizeof(int), GFP_KERNEL);
> +if (!gd)
> +goto err_kmalloc_gd;
> +gd->sizes = kmalloc (minors * sizeof(int), GFP_KERNEL);
> +if (!gd->sizes)
> +goto err_kmalloc_gd_sizes;
> +gd->part  = kmalloc (minors * sizeof(struct hd_struct), GFP_KERNEL);
> +if (!gd->part)
> +goto err_kmalloc_gd_part;
> +bs= kmalloc (minors*sizeof(int), GFP_KERNEL);
>

Re: DVD blockdevice buffers

On 25 May 2001, Eric W. Biederman wrote:
>
> I obviously picked a bad name, and a bad place to start.
> int data_uptodate(struct page *page, unsigned offset, unsigned len)
>
> This is really an extension to PG_uptodate, not readpage.

Ugh.

The above is just horrible.

It doesn't fix any problems, it is only an ugly work-around for a
situation that never happens in real life. An application that only
re-reads the data that it just wrote itself is a _stupid_ application, and
I'm absolutely not interested in having a new interface that is useless
for everything _but_ such a stupid application.

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: The difference between Linus's kernel and Alan Cox's kernel

2001-05-25 Thread Wayne . Brown




It really ought to be Linus and/or Alan who answers this, but from my own
observations, here's the way I think it goes:

Alan and Linus don't always agree on what should be in the kernel; and even when
they do, they sometimes disagree on when something is ready to be included.
Alan may think a particular set of patches are ready, while Linus thinks they
need to mature a bit more; or perhaps he thinks the whole approach is wrong and
should be scrapped.  So Alan puts it in his kernel, and Linus leaves it out of
his.  (Of course, sometimes it's Linus who adds something that Alan rejects.)
It sometimes happens that one of these new ideas turns out better than expected
(especially after going through a few bug report/new patch cycles), and the
person who rejected it changes his mind and includes it later; or maybe it
doesn't work out and gets dropped altogether.  Also, as you've already observed,
Alan regularly resyncs major parts of his tree with Linus' so they don't get too
far apart, and Linus occasionally does the same.

It used to bother me, too, to have to keep up with two different kernel trees.
But I've come to realize that this is a Good Thing.  It provides a way for
people with different viewpoints to approach an idea from more than one
direction.  If the two kernels are trying to solve a particular problem in
different ways, we get to see how each approach works in the real world, rather
than just in a theoretical discussion.  If the two kernels branch too far apart
it could be a problem, but Linus and Alan have been diligent about keeping that
from happening.  I think the interplay (is "competition" too strong a word?)
between the two branches has helped make the "official" kernel better than it
might have been otherwise.

Wayne


-
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] Add missing spin_unlock_irq to ide.c (244ac16)


On Fri, May 25, 2001 at 11:11:23PM +0200, Jens Axboe wrote:
[...] 
> This isn't right. Granted the locking isn't straight forward here, but
> take a look at ide_write_setting -> ide_spin_wait_hwgroup and the
> latters return value.
 
Yes, Andre set me straight here. My apologies for being lazy and
not checking the call path.

-- 
Rasmus([EMAIL PROTECTED])

You know how dumb the average guy is?  Well, by  definition, half
of them are even dumber than that.
-- J.R. "Bob" Dobbs 
-
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: [with-PATCH-really] highmem deadlock removal, balancing & cleanup

On Fri, 25 May 2001, Rik van Riel wrote:
>
> OK, shoot me.  Here it is again, this time _with_ patch...

I'm not going to apply this as long as it plays experimental games with
"shrink_icache()" and friends. I haven't seen anybody comment on the
performance on this, and I can well imagine that it would potentially
shrink the dcache too aggressively when there are lots of inactive-dirty
pages around, where page_launder is the right thing to do, and shrinking
icache/dcache might not be.

I'd really like to avoid having the MM stuff fluctuate too much. Have
people tested this under different loads etc?

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] Add missing spin_unlock_irq to ide.c (244ac16)

2001-05-25 Thread Jens Axboe


On Fri, May 25 2001, Rasmus Andersen wrote:
> (I forgot to cc l-k on this one when it went to andre.)
> 
> Hi.
> 
> This patch adds a spin_unlock_irqsave to ide_spin_wait_hwgroup as
> reported by the Stanford team way back. It applies against 244ac16.
> 
> 
> --- linux-244-ac16-clean/drivers/ide/ide.cFri May 25 21:11:08 2001
> +++ linux-244-ac16/drivers/ide/ide.c  Fri May 25 22:46:43 2001
> @@ -2362,6 +2362,8 @@
>   __restore_flags(lflags);/* local CPU only */
>   spin_lock_irq(_request_lock);
>   }
> +
> +spin_unlock_irq(_request_lock);
>   return 0;
>  }

This isn't right. Granted the locking isn't straight forward here, but
take a look at ide_write_setting -> ide_spin_wait_hwgroup and the
latters return value.

BTW, also try and follow local style when making such changes.

-- 
Jens Axboe

-
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] init -> initdata in drivers/video/matrox/matroxfb_base.c (244ac16)


Hi.

The following patch changes an __init to __initdata. Applies against
2.4.4-ac11.


--- linux-244-ac11-clean/drivers/video/matrox/matroxfb_base.c   Sat May 19 20:58:43 
2001
+++ linux-244-ac11/drivers/video/matrox/matroxfb_base.c Sun May 20 23:55:24 2001
@@ -2483,7 +2483,7 @@
return 0;
 }
 
-static int __init initialized = 0;
+static int __initdata initialized = 0;
 
 int __init matroxfb_init(void)
 {

-- 
Regards,
Rasmus([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: DVD blockdevice buffers

2001-05-25 Thread Eric W. Biederman

Linus Torvalds <[EMAIL PROTECTED]> writes:

> On 25 May 2001, Eric W. Biederman wrote:
> > 
> > For the small random read case we could use a 
> > mapping->a_ops->readpartialpage 
> 
> No, if so I'd prefer to just change "readpage()" to take the same kinds of
> arguments commit_page() does, namely the beginning and end of the read
> area. 

No.

I obviously picked a bad name, and a bad place to start.
int data_uptodate(struct page *page, unsigned offset, unsigned len)

This is really an extension to PG_uptodate, not readpage.  It should
never ever do any I/O.  It should just implement a check to see
if we have all of the data wanted already in the page in the page
cache.  As simply a buffer checking entity it will likely share
virtualy 0 code with read_page.

> Filesystems could choose to ignore the arguments completely, and just act
> the way they already do - filling in the whole page.
> 
> OR a filesystem might know that the page is partially up-to-date (because
> of a partial write), and just return an immediate "this area is already
> uptodate" return code or something. Or it could even fill in the page
> partially, and just unlock it (but not mark it up-to-date: the reader then
> has to wait for the page and then look at PG_error to decide whether the
> partial read succeeded or not).

First mm/filemap.c has generic cache management, so it should make the
decision.

The logic is does this page have the data in cache?
If so just return it.

Otherwise read all that you can at once.  

So we either want a virtual function that can make the decision on
a per filesystem bases if we have the data we need in the page cache.
Or we need to convert the buffer_head into a more generic entity
so everyone can use it.

> I don't think it really matters, I have to say. It would be very easy to
> implement (all the buffer-based filesystems already use the common
> fs/buffer.c readpage, so it would really need changes in just one place,
> along with some expanded prototypes with ignored arguments in some other
> places).
> 
> But it _could_ be a performance helper for some strange loads (write a
> partial page and immediately read it back - what a stupid program), and
> more importantly Al Viro felt earlier that a "partial read" approach might
> help his metadata-in-page-cache stuff because metadata tends to sometimes
> be scattered wildly across the disk.

Maybe I think despite the similarities (partial pages) Al & and I are
looking at two entirely different problems.

> So then we'd have
> 
>   int (*readpage)(struct file *, struct page *, unsigned offset, unsigned
> len);
> 
> 
> and the semantics would be:
>  - the function needs to start IO for _at_least_ the page area
>[offset, offset+len[
>  - return error code for _immediate_ errors (ie not asynchronous)
>  - if there was an asynchronous read error, we set PG_error
>  - if the page is fully populated, we set PG_uptodate
>  - if the page was not fully populated, but the partial read succeeded,
>the filesystem needs to have some way of keeping track of the partial
>success ("page->buffers" is obviously the way for a block-based one),
>and must _not_ set PG_uptodate.
>  - after the asynchronous operation (whether complete, partial or
>unsuccessful), the page is unlocked to tell the reader that it is done.
> 
> Now, this would be coupled with:
>  - generic_file_read() does the read-ahead decisions, and may decide that
>we really only need a partial page.
> 
> But NOTE! The above is meant to potentially avoid unnecessary IO and thus
> speed up the read-in. HOWEVER, it _will_ slow down the case where we first
> would read a small part of the page and then soon afterwards read in the
> rest of the page. I suspect that is the common case by far, and that the
> current whole-page approach is the faster one in 99% of all cases. So I'm
> not at all convinced that the above is actually worth it.

I don't want partial I/O at all.  And I always want to see reads
reading in all of the data for a page.  I just want an interface
where we can say hey we don't actually have to do any I/O for this
read request, give them back their data.

> If somebody can show that the above is worth it and worth implementing (ie
> the Al Viro kind of "I have a real-life schenario where I'd like to use
> it"), and implements it (should be a fairly trivial exercise), then I'll
> happily accept new semantics like this.
> 
> But I do _not_ want to see another new function ("partialread()"), and I
> do _not_ want to see synchronous interfaces (Al's first suggestion).

My naming mistake I don't want to see this logic combined with
readpage.  That is an entirely different case.

I can't see how adding a slow case to PageUptodate to check for a
partially uptodate page could hurt our performance.  And I can imagine
how it could help.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo

Re: [PATCH] check kmalloc return in ide-cd.c (244-ac16)

2001-05-25 Thread Jens Axboe


On Fri, May 25 2001, Rasmus Andersen wrote:
> Hi.
> 
> This patch adds a check for the return value from kmalloc in
> ide_cdrom_open. Applies against ac16.

Thanks, applied.

-- 
Jens Axboe

-
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: [CFT][PATCH] namespaces patch (2.4.5-pre6)

2001-05-25 Thread David L. Parsley


Alexander Viro wrote:
> 
> Folks, new version of the patch is on
> ftp.math.psu.edu/pub/viro/namespaces-c-S5-pre6.gz
> 
> News:
> * ported to 2.4.5-pre6
> * new (cleaner) locking mechanism
> * lock_super() is starting to become fs-private thing - first steps to
>   removing it from VFS code are done.
> 
> Please, help with testing. I'm feeding the pieces suitable for 2.4 into
> the Linus' tree, so patch got smaller.

OK, at the risk of asking a Stupid Question (tm), what exactly does
the namespaces patch buy us?  From the viewpoint of an
integrator/system admin?  I'd happily check it out if I thought it
would solve any of the problems I regularly see.

regards,
David

-- 
David L. Parsley
Network Administrator, Roanoke College
"If I have seen further it is by standing on ye shoulders of
Giants."
--Isaac Newton
-
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] fbdev logo (fwd)

2001-05-25 Thread Dr. Kelsey Hudson


On Thu, 10 May 2001, Geert Uytterhoeven wrote:
>   - Political fixes:
>   o There were still some penguins left carrying a glass of beer or wine.
> This problem is about 2 years old!

I still don't understand why the penguin holding beer/wine was wrong...

 Kelsey Hudson   [EMAIL PROTECTED]
 Software Engineer
 Compendium Technologies, Inc   (619) 725-0771
---

-
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] Add missing spin_unlock_irq to ide.c (244ac16)


(I forgot to cc l-k on this one when it went to andre.)

Hi.

This patch adds a spin_unlock_irqsave to ide_spin_wait_hwgroup as
reported by the Stanford team way back. It applies against 244ac16.


--- linux-244-ac16-clean/drivers/ide/ide.c  Fri May 25 21:11:08 2001
+++ linux-244-ac16/drivers/ide/ide.cFri May 25 22:46:43 2001
@@ -2362,6 +2362,8 @@
__restore_flags(lflags);/* local CPU only */
spin_lock_irq(_request_lock);
}
+
+spin_unlock_irq(_request_lock);
return 0;
 }
 
-- 
Rasmus([EMAIL PROTECTED])

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kmalloc checks for drivers/ide/ide-probe.c (244ac16)


On Fri, May 25, 2001 at 01:47:52PM -0700, Andre Hedrick wrote:
> 
> Not valid because the jump to that part of the code is protected.
> If a polling response for a valid status and no timeout, is detected then
> it attempts to the command for real only after success or a test.
> 
> Otherwise it would be valid.

So the EXABYTE case should return normally, I take (otherwise you
confused me good;))? The patch below drops this change and keeps
the rest.


--- linux-244-ac16-clean/drivers/ide/ide-probe.cFri May 25 21:11:08 2001
+++ linux-244-ac16/drivers/ide/ide-probe.c  Fri May 25 22:54:15 2001
@@ -58,6 +58,11 @@
struct hd_driveid *id;
 
id = drive->id = kmalloc (SECTOR_WORDS*4, GFP_ATOMIC);  /* called with 
interrupts disabled! */
+if (!id) {
+printk(KERN_WARNING "(ide-probe::do_identify) Out of memory.\n");
+goto err_kmalloc;
+}
+
ide_input_data(drive, id, SECTOR_WORDS);/* read 512 bytes of 
id info */
ide__sti(); /* local CPU only */
ide_fix_driveid(id);
@@ -76,8 +81,7 @@
if ((id->model[0] == 'P' && id->model[1] == 'M')
 || (id->model[0] == 'S' && id->model[1] == 'K')) {
printk("%s: EATA SCSI HBA %.10s\n", drive->name, id->model);
-   drive->present = 0;
-   return;
+goto err_misc;
}
 #endif /* CONFIG_SCSI_EATA_DMA || CONFIG_SCSI_EATA_PIO */
 
@@ -111,8 +115,7 @@
 #ifdef CONFIG_BLK_DEV_PDC4030
if (HWIF(drive)->channel == 1 && HWIF(drive)->chipset == ide_pdc4030) {
printk(" -- not supported on 2nd Promise port\n");
-   drive->present = 0;
-   return;
+goto err_misc;
}
 #endif /* CONFIG_BLK_DEV_PDC4030 */
switch (type) {
@@ -174,6 +177,12 @@
printk("ATA DISK drive\n");
QUIRK_LIST(HWIF(drive),drive);
return;
+
+err_misc:
+kfree(id);
+err_kmalloc:
+drive->present = 0;
+return;
 }
 
 /*
@@ -759,11 +768,23 @@
}
minors= units * (1part  = kmalloc (minors * sizeof(struct hd_struct), GFP_KERNEL);
-   bs= kmalloc (minors*sizeof(int), GFP_KERNEL);
-   max_sect  = kmalloc (minors*sizeof(int), GFP_KERNEL);
-   max_ra= kmalloc (minors*sizeof(int), GFP_KERNEL);
+if (!gd)
+goto err_kmalloc_gd;
+gd->sizes = kmalloc (minors * sizeof(int), GFP_KERNEL);
+if (!gd->sizes)
+goto err_kmalloc_gd_sizes;
+gd->part  = kmalloc (minors * sizeof(struct hd_struct), GFP_KERNEL);
+if (!gd->part)
+goto err_kmalloc_gd_part;
+bs= kmalloc (minors*sizeof(int), GFP_KERNEL);
+if (!bs)
+goto err_kmalloc_gs;
+max_sect  = kmalloc (minors*sizeof(int), GFP_KERNEL);
+if (!max_sect)
+goto err_kmalloc_max_sect;
+max_ra= kmalloc (minors*sizeof(int), GFP_KERNEL);
+if (!max_ra)
+goto err_kmalloc_max_ra;
 
memset(gd->part, 0, minors * sizeof(struct hd_struct));
 
@@ -816,6 +837,21 @@
devfs_mk_dir (ide_devfs_handle, name, NULL);
}
}
+return;
+
+err_kmalloc_max_ra:
+kfree(max_sect);
+err_kmalloc_max_sect:
+kfree(bs);
+err_kmalloc_gs:
+kfree(gd->part);
+err_kmalloc_gd_part:
+kfree(gd->sizes);
+err_kmalloc_gd_sizes:
+kfree(gd);
+err_kmalloc_gd:
+printk(KERN_WARNING "(ide::init_gendisk) Out of memory\n");
+return;
 }
 
 static int hwif_init (ide_hwif_t *hwif)

Regards,
   Rasmus
-
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] kmalloc checks for drivers/ide/ide-probe.c (244ac16)

2001-05-25 Thread Andre Hedrick



Not valid because the jump to that part of the code is protected.
If a polling response for a valid status and no timeout, is detected then
it attempts to the command for real only after success or a test.

Otherwise it would be valid.

Cheers,

On Fri, 25 May 2001, Rasmus Andersen wrote:

> Date: Fri, 25 May 2001 22:18:13 +0200
> From: Rasmus Andersen <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [PATCH] kmalloc checks for drivers/ide/ide-probe.c (244ac16)
> 
> Hi.
> 
> The following patch adds a number of checks for kmalloc returns
> to drivers/ide/ide-probe.c. It applies against ac16.
> 
> One comment: This patch adds 'drive-present = 0' to the
> code path for the EXABYTE case. I could not discern if this was a
> shortcoming of the original code or not. Please comment.
> 
> 
> --- linux-244-ac16-clean/drivers/ide/ide-probe.c  Fri May 25 21:11:08 2001
> +++ linux-244-ac16/drivers/ide/ide-probe.cFri May 25 21:51:08 2001
> @@ -58,6 +58,11 @@
>   struct hd_driveid *id;
>  
>   id = drive->id = kmalloc (SECTOR_WORDS*4, GFP_ATOMIC);  /* called with 
>interrupts disabled! */
> +if (!id) {
> +printk(KERN_WARNING "(ide-probe::do_identify) Out of memory.\n");
> +goto err_kmalloc;
> +}
> +
>   ide_input_data(drive, id, SECTOR_WORDS);/* read 512 bytes of 
>id info */
>   ide__sti(); /* local CPU only */
>   ide_fix_driveid(id);
> @@ -76,8 +81,7 @@
>   if ((id->model[0] == 'P' && id->model[1] == 'M')
>|| (id->model[0] == 'S' && id->model[1] == 'K')) {
>   printk("%s: EATA SCSI HBA %.10s\n", drive->name, id->model);
> - drive->present = 0;
> - return;
> +goto err_misc;
>   }
>  #endif /* CONFIG_SCSI_EATA_DMA || CONFIG_SCSI_EATA_PIO */
>  
> @@ -96,7 +100,7 @@
>   ide_fixstring (id->serial_no, sizeof(id->serial_no), bswap);
>  
>   if (strstr(id->model, "E X A B Y T E N E S T"))
> - return;
> +goto err_misc;
>  
>   id->model[sizeof(id->model)-1] = '\0';  /* we depend on this a lot! */
>   printk("%s: %s, ", drive->name, id->model);
> @@ -111,8 +115,7 @@
>  #ifdef CONFIG_BLK_DEV_PDC4030
>   if (HWIF(drive)->channel == 1 && HWIF(drive)->chipset == ide_pdc4030) {
>   printk(" -- not supported on 2nd Promise port\n");
> - drive->present = 0;
> - return;
> +goto err_misc;
>   }
>  #endif /* CONFIG_BLK_DEV_PDC4030 */
>   switch (type) {
> @@ -174,6 +177,12 @@
>   printk("ATA DISK drive\n");
>   QUIRK_LIST(HWIF(drive),drive);
>   return;
> +
> +err_misc:
> +kfree(id);
> +err_kmalloc:
> +drive->present = 0;
> +return;
>  }
>  
>  /*
> @@ -759,11 +768,23 @@
>   }
>   minors= units * (1<   gd= kmalloc (sizeof(struct gendisk), GFP_KERNEL);
> - gd->sizes = kmalloc (minors * sizeof(int), GFP_KERNEL);
> - gd->part  = kmalloc (minors * sizeof(struct hd_struct), GFP_KERNEL);
> - bs= kmalloc (minors*sizeof(int), GFP_KERNEL);
> - max_sect  = kmalloc (minors*sizeof(int), GFP_KERNEL);
> - max_ra= kmalloc (minors*sizeof(int), GFP_KERNEL);
> +if (!gd)
> +goto err_kmalloc_gd;
> +gd->sizes = kmalloc (minors * sizeof(int), GFP_KERNEL);
> +if (!gd->sizes)
> +goto err_kmalloc_gd_sizes;
> +gd->part  = kmalloc (minors * sizeof(struct hd_struct), GFP_KERNEL);
> +if (!gd->part)
> +goto err_kmalloc_gd_part;
> +bs= kmalloc (minors*sizeof(int), GFP_KERNEL);
> +if (!bs)
> +goto err_kmalloc_gs;
> +max_sect  = kmalloc (minors*sizeof(int), GFP_KERNEL);
> +if (!max_sect)
> +goto err_kmalloc_max_sect;
> +max_ra= kmalloc (minors*sizeof(int), GFP_KERNEL);
> +if (!max_ra)
> +goto err_kmalloc_max_ra;
>  
>   memset(gd->part, 0, minors * sizeof(struct hd_struct));
>  
> @@ -816,6 +837,21 @@
>   devfs_mk_dir (ide_devfs_handle, name, NULL);
>   }
>   }
> +return;
> +
> +err_kmalloc_max_ra:
> +kfree(max_sect);
> +err_kmalloc_max_sect:
> +kfree(bs);
> +err_kmalloc_gs:
> +kfree(gd->part);
> +err_kmalloc_gd_part:
> +kfree(gd->sizes);
> +err_kmalloc_gd_sizes:
> +kfree(gd);
> +err_kmalloc_gd:
> +printk(KERN_WARNING "(ide::init_gendisk) Out of memory\n");
> +return;
>  }
>  
>  static int hwif_init (ide_hwif_t *hwif)
> -- 
> regards,
> Rasmus([EMAIL PROTECTED])
> 
> An Emacs reference mug is what I want. It would hold ten gallons of
> coffee. -- Steve VanDevender 
> 

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc.

Re: Dedicated Interrupt handling on SMP

2001-05-25 Thread Ingo Oeser


On Fri, May 25, 2001 at 12:43:11PM -0400, Randy wrote:
> I'm trying to find the easiest way to to deidcate one CPU to responding
> to a specific Interrupt request.
> That CPU should only listen for that request while all other CPU should
> ignore the interrupt.

cat /proc/irq/*/smp_affinity

There you can select on which if the 32 CPUs Linux should handle
this IRQ.

Read Documentation/IRQ-affinity.txt for more.

Regards

Ingo Oeser
-- 
To the systems programmer,
users and applications serve only to provide a test load.
-
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/

[CFT][PATCH] namespaces patch (2.4.5-pre6)


Folks, new version of the patch is on
ftp.math.psu.edu/pub/viro/namespaces-c-S5-pre6.gz

News:
* ported to 2.4.5-pre6
* new (cleaner) locking mechanism
* lock_super() is starting to become fs-private thing - first steps to
  removing it from VFS code are done.

Please, help with testing. I'm feeding the pieces suitable for 2.4 into
the Linus' tree, so patch got smaller.

It works here(tm). It had survived rather sadistic tortu^Wtesting, but I
am _very_ interested in more eyes going through the thing and more people
giving it a beating.
Al

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] __idetape_kmalloc_stage return code check in ide-tape.c (244-ac16)


Hi.

This trivial patch adds a kmalloc check to ide-tape.c::
idetape_onstream_read_back_buffer as per the Stanford team's report
way back. It applies against 244ac16.

Reading the code I was not sure if it was OK to just return
or more should be done. Please sanity check this.

--- linux-244-ac11-clean/drivers/ide/ide-tape.c Sat May 19 21:06:35 2001
+++ linux-244-ac11/drivers/ide/ide-tape.c   Sun May 20 14:58:44 2001
@@ -3472,6 +3472,11 @@
printk(KERN_INFO "ide-tape: %s: reading back %d frames from the drive's 
internal buffer\n", tape->name, frames);
for (i = 0; i < frames; i++) {
stage = __idetape_kmalloc_stage(tape, 0, 0);
+if(!stage) {
+printk(KERN_WARNING "(idetape:) Failed to allocate memory for 
+buffer\n");
+return;
+}
+
if (!first)
first = stage;
aux = stage->aux;
-- 
Regards,
Rasmus([EMAIL PROTECTED])

'Xenix is the pinnacle of modern UNIX design, and will be used for many
years to come' -Xenix OS API manual 
-
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/

ATI Rage 128

2001-05-25 Thread Android


Are there any plans for including support for the ATI Rage 128 chipset into 
svgalib?
The VESA setting does not work. Causes any program using svgalib to crash.
Are there any configuration settings in the kernel that may help with this?

The kernel I am using is 2.4.4 and the card I am using is the Rage Fury (32 
MB).
The svgalib version is 1.4.2
Framebuffer does have support for Rage 128, so I don't see why svgalib doesn't.

Thanks!

   -- Ted

-
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] kmalloc checks for drivers/ide/ide-probe.c (244ac16)


Hi.

The following patch adds a number of checks for kmalloc returns
to drivers/ide/ide-probe.c. It applies against ac16.

One comment: This patch adds 'drive-present = 0' to the
code path for the EXABYTE case. I could not discern if this was a
shortcoming of the original code or not. Please comment.


--- linux-244-ac16-clean/drivers/ide/ide-probe.cFri May 25 21:11:08 2001
+++ linux-244-ac16/drivers/ide/ide-probe.c  Fri May 25 21:51:08 2001
@@ -58,6 +58,11 @@
struct hd_driveid *id;
 
id = drive->id = kmalloc (SECTOR_WORDS*4, GFP_ATOMIC);  /* called with 
interrupts disabled! */
+if (!id) {
+printk(KERN_WARNING "(ide-probe::do_identify) Out of memory.\n");
+goto err_kmalloc;
+}
+
ide_input_data(drive, id, SECTOR_WORDS);/* read 512 bytes of 
id info */
ide__sti(); /* local CPU only */
ide_fix_driveid(id);
@@ -76,8 +81,7 @@
if ((id->model[0] == 'P' && id->model[1] == 'M')
 || (id->model[0] == 'S' && id->model[1] == 'K')) {
printk("%s: EATA SCSI HBA %.10s\n", drive->name, id->model);
-   drive->present = 0;
-   return;
+goto err_misc;
}
 #endif /* CONFIG_SCSI_EATA_DMA || CONFIG_SCSI_EATA_PIO */
 
@@ -96,7 +100,7 @@
ide_fixstring (id->serial_no, sizeof(id->serial_no), bswap);
 
if (strstr(id->model, "E X A B Y T E N E S T"))
-   return;
+goto err_misc;
 
id->model[sizeof(id->model)-1] = '\0';  /* we depend on this a lot! */
printk("%s: %s, ", drive->name, id->model);
@@ -111,8 +115,7 @@
 #ifdef CONFIG_BLK_DEV_PDC4030
if (HWIF(drive)->channel == 1 && HWIF(drive)->chipset == ide_pdc4030) {
printk(" -- not supported on 2nd Promise port\n");
-   drive->present = 0;
-   return;
+goto err_misc;
}
 #endif /* CONFIG_BLK_DEV_PDC4030 */
switch (type) {
@@ -174,6 +177,12 @@
printk("ATA DISK drive\n");
QUIRK_LIST(HWIF(drive),drive);
return;
+
+err_misc:
+kfree(id);
+err_kmalloc:
+drive->present = 0;
+return;
 }
 
 /*
@@ -759,11 +768,23 @@
}
minors= units * (1part  = kmalloc (minors * sizeof(struct hd_struct), GFP_KERNEL);
-   bs= kmalloc (minors*sizeof(int), GFP_KERNEL);
-   max_sect  = kmalloc (minors*sizeof(int), GFP_KERNEL);
-   max_ra= kmalloc (minors*sizeof(int), GFP_KERNEL);
+if (!gd)
+goto err_kmalloc_gd;
+gd->sizes = kmalloc (minors * sizeof(int), GFP_KERNEL);
+if (!gd->sizes)
+goto err_kmalloc_gd_sizes;
+gd->part  = kmalloc (minors * sizeof(struct hd_struct), GFP_KERNEL);
+if (!gd->part)
+goto err_kmalloc_gd_part;
+bs= kmalloc (minors*sizeof(int), GFP_KERNEL);
+if (!bs)
+goto err_kmalloc_gs;
+max_sect  = kmalloc (minors*sizeof(int), GFP_KERNEL);
+if (!max_sect)
+goto err_kmalloc_max_sect;
+max_ra= kmalloc (minors*sizeof(int), GFP_KERNEL);
+if (!max_ra)
+goto err_kmalloc_max_ra;
 
memset(gd->part, 0, minors * sizeof(struct hd_struct));
 
@@ -816,6 +837,21 @@
devfs_mk_dir (ide_devfs_handle, name, NULL);
}
}
+return;
+
+err_kmalloc_max_ra:
+kfree(max_sect);
+err_kmalloc_max_sect:
+kfree(bs);
+err_kmalloc_gs:
+kfree(gd->part);
+err_kmalloc_gd_part:
+kfree(gd->sizes);
+err_kmalloc_gd_sizes:
+kfree(gd);
+err_kmalloc_gd:
+printk(KERN_WARNING "(ide::init_gendisk) Out of memory\n");
+return;
 }
 
 static int hwif_init (ide_hwif_t *hwif)
-- 
regards,
Rasmus([EMAIL PROTECTED])

An Emacs reference mug is what I want. It would hold ten gallons of
coffee. -- Steve VanDevender 
-
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: blkdev-pagecache-2 [was Re: DVD blockdevice buffers]


On Fri, May 25, 2001 at 10:12:51PM +0200, Andrea Arcangeli wrote:
>   
>ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.4.5pre6/blkdev-pagecache-2
   ^ 4 sorry
-
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/

blkdev-pagecache-2 [was Re: DVD blockdevice buffers]

On Thu, May 24, 2001 at 12:32:20AM +0200, Andrea Arcangeli wrote:
> userspace. I will try to work on the blkdev patch tomorrow to bring it
> in an usable state.

It seems in an usable state right but it is still very early beta, I
need to recheck the whole thing, I will do that tomorrow, for now it
should get it right the fsck on a ro mount fs and the cache coherency
across multiple inodes all pointing to the same blkdev, it actually
worked without any problem in the first basic tests I did. However I
expect it to corrupt a rw mounted fs if you open the blkdev under it
(the fsck test happens with the fs ro), so while it's in an usable state
it's not ready for public consumation yet. Of course ramdisk is still
totally broken too. The other first round of bugs mentioned in the first
thread should be fixed. The blocksize is still hardwired to 4k, I'll
think about the read-modify-write problem later. About the proposed
readpage API change I think it's not worthwhile for new hardware where
reading 1k or 4k doesn't make relevant difference. Handling partial
I/O seems worthwhile only during writes because a partial write would
otherwise trigger a read-modify-write operation with a synchronous read.

ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.4.5pre6/blkdev-pagecache-2

Andrea
-
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/

The difference between Linus's kernel and Alan Cox's kernel

2001-05-25 Thread Thiago Vinhas de Moraes


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi.

Maybe lots of you already know the answer, maybe it's a really stupid 
question. If it is, please tell me. I'll not be offended.

Why there are two different kernel trees? There is always the official 
release, provided by Torvalds, and then Alan provides a patch merging Linus's 
stuff, and adding (?) tons of bug fixes.

Why aren't the -ac patches completely merged to the official tree, and you 
centralize the work on single kernel patches ?? Won't it be easier to 
administrate?

I'm so sorry if it's a really stupid question. It's because I never know what 
pre-patch to apply, the -ac* or the -pre*. In doubt, I apply Alan's, because 
it appears to be always Linus stuff, and more bug fixes, recently, the 
Linus's -pre* appears to have merges from the -ac on each release.
I just don't understand why it can all be merged.


Regards,
Thiago Vinhas de Moraes
NetWorx - A SuaCompanhia.com
Rio de Janeiro - Brazil
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7Dry8GHuTR9LK9ocRAsIIAKCs/uMrlDxZSlst8J0h0D6k6tylkACeKNMB
ESyPHbcpcbxWr48NySQYUBs=
=FotG
-END PGP SIGNATURE-
-
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/

[with-PATCH-really] highmem deadlock removal, balancing & cleanup

OK, shoot me.  Here it is again, this time _with_ patch...

-- Forwarded message --
Date: Fri, 25 May 2001 16:53:38 -0300 (BRST)
From: Rik van Riel <[EMAIL PROTECTED]>

Hi Linus,

the following patch does:

1) Remove GFP_BUFFER and HIGHMEM related deadlocks, by letting
   these allocations fail instead of looping forever in
   __alloc_pages() when they cannot make any progress there.

   Now Linux no longer hangs on highmem machines with heavy
   write loads.

2) Clean up the __alloc_pages() / __alloc_pages_limit() code
   a bit, moving the direct reclaim condition from the latter
   function into the former so we run it less often ;)

3) Remove the superfluous wakeups from __alloc_pages(), not
   only are the tests a real CPU eater, they also have the
   potential of waking up bdflush in a situation where it
   shouldn't run in the first place.  The kswapd wakeup didn't
   seem to have any effect either.

4) Do make sure GFP_BUFFER allocations NEVER eat into the
   very last pages of the system. It is important to preserve
   the following ordering:
- normal allocations
- GFP_BUFFER
- atomic allocations
- other recursive allocations

   Using this ordering, we can be pretty sure that eg. a
   GFP_BUFFER allocation to swap something out to an
   encrypted device won't eat the memory the device driver
   will need to perform its functions. It also means that
   a gigabit network flood won't eat those pages...

5) Change nr_free_buffer_pages() a bit to not return pages
   which cannot be used as buffer pages, this makes a BIG
   difference on highmem machines (which now DO have a working
   write throttling again).

6) Simplify the refill_inactive() loop enough that it actually
   works again. Calling page_launder() and shrink_i/d_memory()
   by the same if condition means that the different caches
   get balanced against each other again.

   The illogical argument for not shrinking the slab cache
   while we're under a free shortage turned out to be very
   much illogical too.  All needed buffer heads will have been
   allocated in page_launder() and shrink_i/d_memory() before
   we get here and we can be pretty sure that these functions
   will keep re-using those same buffer heads as soon as the
   IO finishes.

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/

--- linux-2.4.5-pre6/mm/page_alloc.c.orig   Fri May 25 16:13:39 2001
+++ linux-2.4.5-pre6/mm/page_alloc.cFri May 25 16:35:50 2001
@@ -251,10 +251,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)
@@ -299,21 +299,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.
@@ -329,7 +314,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;
@@ -443,18 +428,26 @@
}
/*
 * 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.
+*
+* 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
+

[PATCH] highmem deadlock removal, balancing & cleanup


Hi Linus,

the following patch does:

1) Remove GFP_BUFFER and HIGHMEM related deadlocks, by letting
   these allocations fail instead of looping forever in
   __alloc_pages() when they cannot make any progress there.

   Now Linux no longer hangs on highmem machines with heavy
   write loads.

2) Clean up the __alloc_pages() / __alloc_pages_limit() code
   a bit, moving the direct reclaim condition from the latter
   function into the former so we run it less often ;)

3) Remove the superfluous wakeups from __alloc_pages(), not
   only are the tests a real CPU eater, they also have the
   potential of waking up bdflush in a situation where it
   shouldn't run in the first place.  The kswapd wakeup didn't
   seem to have any effect either.

4) Do make sure GFP_BUFFER allocations NEVER eat into the
   very last pages of the system. It is important to preserve
   the following ordering:
- normal allocations
- GFP_BUFFER
- atomic allocations
- other recursive allocations

   Using this ordering, we can be pretty sure that eg. a
   GFP_BUFFER allocation to swap something out to an
   encrypted device won't eat the memory the device driver
   will need to perform its functions. It also means that
   a gigabit network flood won't eat those pages...

5) Change nr_free_buffer_pages() a bit to not return pages
   which cannot be used as buffer pages, this makes a BIG
   difference on highmem machines (which now DO have a working
   write throttling again).

6) Simplify the refill_inactive() loop enough that it actually
   works again. Calling page_launder() and shrink_i/d_memory()
   by the same if condition means that the different caches
   get balanced against each other again.

   The illogical argument for not shrinking the slab cache
   while we're under a free shortage turned out to be very
   much illogical too.  All needed buffer heads will have been
   allocated in page_launder() and shrink_i/d_memory() before
   we get here and we can be pretty sure that these functions
   will keep re-using those same buffer heads as soon as the
   IO finishes.

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com/

-
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: ac15 and 2.4.5-pre6, pwc format conversion

2001-05-25 Thread Jeff Garzik


"Nemosoft Unv." wrote:
> On 25-May-01 Alan Cox wrote:
> > It breaks apps by doing conversions, and it breaks important apps like H263
> > codecs not silly little camera viewers, because you trash the performance
> 
> This is a NULL argument. First, it doesn´t break anything; I think H263 is
> smart to pick a YUV format if it´s available. Second, conversion has to be
> done at one point or another. If the native format of the camera is RGB,
> H263 will have to convert to YUV. Wether or not this is done in kernel space
> or user space doesn´t matter: it has to be done. And in case the native
> format of the camera doesn´t resemble anything in V4L, you will have TWO
> conversion: first, in kernel from native to V4L palette, and then in your
> tool from V4L to whatever format you need, while maybe the driver could do
> it all in one stage.

Sorry this is a slippery slope argument and it won't wash.

The kernel is intended as the arbiter between userspace and hardware,
and userspace and userspace.  Format conversion has nothing to do with
arbitration.

Format conversion in kernelspace is far less flexible than userspace: 
you cannot replace your algorithms at will nor fix bugs at will.  You
cannot support assembly optimizations for format conversions without
bloating the kernel.

Finally, the example you describe is invalid.  If your tool is doing
-two- format conversions, then [again] the tool should be fixed.  The
kernel most definitely should not work around stupid shortcomings of
userspace software.


> Anyway, I am not going to debate this any further at this point. Johannes,
> please remove my webcam driver from the USB source tree,

whatever.  I don't see Alan or Linus accepting such a change, even if
Johannes does.


> until the software
> YUV/RGB conversion has been removed from ALL other video devices (preferably
> all at the same time).

Send a patch for this instead!

Format conversion should not be in the kernel...

Jeff


-- 
Jeff Garzik  | "Are you the police?"
Building 1024| "No, ma'am.  We're musicians."
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: ac15 and 2.4.5-pre6, pwc format conversion

2001-05-25 Thread Nemosoft Unv.

Greetings,

Coalescing two messages in one:

On 25-May-01 Alan Cox wrote:
> Nope. Its been policy since 2.0. Its both v4l1 and v4l2 policy. In fact its
> fairly nonsensical to handle any format conversions in kernel unless the
> device outputs a unique format of its own.

Oh come on. 2.0 has been out since, what? 1996? Methinks you have had plenty
of time to really do something about it then. You are now simply too late.

> It breaks apps by doing conversions, and it breaks important apps like H263
> codecs not silly little camera viewers, because you trash the performance

This is a NULL argument. First, it doesn´t break anything; I think H263 is
smart to pick a YUV format if it´s available. Second, conversion has to be
done at one point or another. If the native format of the camera is RGB,
H263 will have to convert to YUV. Wether or not this is done in kernel space
or user space doesn´t matter: it has to be done. And in case the native
format of the camera doesn´t resemble anything in V4L, you will have TWO
conversion: first, in kernel from native to V4L palette, and then in your
tool from V4L to whatever format you need, while maybe the driver could do
it all in one stage.

On 25-May-01 Alan Cox wrote:
>> > that none of the sound drivers does sample rate conversion although
>> > some sound chips are locked at 48kHz only.
>> 
>> True, but a number of audio tools will break, because they don=B4t supp=
> 
> So fix the tools
> 
>> if you limit the number of available palettes per driver. Plus, you wil=
>> l get
>> severe fragmentation of which program works with which driver. Which is
>> unacceptable, in my opinion (and certainly NOT the idea behind a common=
>>  API!)
> 
> Fix the tools.

Gee, ¨Fix the tools¨ seems to be your mantra :-(. Anyway, breaking the tools
doesn´t necessarely mean they are going to get fixed; not all are
being actively maintained at the moment (okay, that´s a pity; still it´s a
shame).

And you are probably not going to get the endless streams of mails to the
webcam developers which state: ¨I upgraded my kernel to 2.4.X and my webcam
broke!¨ Do you really think we will enjoy replying time after time: ¨Yes, I
know, but Alan Cox told me to do so¨. No. To a lot of users, and even
application developers, this just plainly sucks.

>> routines, while (nearly) nothing has been said about other (USB) webcam
>> drivers which have conversion routines.
> 
> I have those in my firing line too. It has always been the policy that
> format
> conversions go in user space. The kernel is an arbitrator of resources it
> is not a shit bucket for solving other peoples incompetence.

Now you are being insulting, really. There are a lot of competent people
who put a lot of time and effort into these tools. But the Video4Linux API
is not complete and not completely suitable for webcams. For example, it
misses the quite fundamental call to query the available palettes; nor does
the V4L API give any hint that the number of palettes might be severely
limited. The first tools that were created had the luxury of hardware that
did all the work for them, so why not use it? Webcams are not so lucky.
There´s no need to penalize them, because if the change goes through, a lot
of tools will not work with webcams but with TV cards.

 ...

Anyway, I am not going to debate this any further at this point. Johannes,
please remove my webcam driver from the USB source tree, until the software
YUV/RGB conversion has been removed from ALL other video devices (preferably
all at the same time). I will *not* have a crippled driver into the Linux
kernel. If this is going to be policy, fine. But then this policy will apply
to ALL drivers equally, not just mine because suddenly Alan realizes he has
been sleeping for the past 5 years and decides to implement a policy hardly
noone ever knew existed.

 - Nemosoft

-
Try SorceryNet!   One of the best IRC-networks around!   irc.sorcery.net:9000
URL: neverIRC: nemosoft  IscaBBS (bbs.isca.uiowa.edu): Nemosoft
>> Never mind the daylight << 
-
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] check kmalloc return in ide-cd.c (244-ac16)


Hi.

This patch adds a check for the return value from kmalloc in
ide_cdrom_open. Applies against ac16.


--- linux-244-ac16-clean/drivers/ide/ide-cd.c   Fri May 25 21:11:08 2001
+++ linux-244-ac16/drivers/ide/ide-cd.c Fri May 25 21:30:20 2001
@@ -2869,12 +2869,12 @@
 int ide_cdrom_open (struct inode *ip, struct file *fp, ide_drive_t *drive)
 {
struct cdrom_info *info = drive->driver_data;
-   int rc;
+   int rc = -ENOMEM;
 
MOD_INC_USE_COUNT;
if (info->buffer == NULL)
info->buffer = (char *) kmalloc(SECTOR_BUFFER_SIZE, GFP_KERNEL);
-   if ((rc = cdrom_fops.open(ip, fp))) {
+if ((info->buffer == NULL) || (rc = cdrom_fops.open(ip, fp))) {
drive->usage--;
MOD_DEC_USE_COUNT;
}
-- 
Regards,
Rasmus([EMAIL PROTECTED])

The police are not here to create disorder.  They're here to preserve
disorder." -Former Chicago mayor Daley during the infamous 1968 Democratic
Party convention
-
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] init -> initdata for drivers/ide/feature.c (244-ac16)


Hi.

The following patch changes an __init to an __initdata. Applies
against 2.4.4-ac16.


--- linux-244-ac16-clean/arch/ppc/kernel/feature.c  Sat May 19 21:06:18 2001+++ 
linux-244-ac16/arch/ppc/kernel/feature.cMon May 21 00:04:35 2001
@@ -267,7 +267,7 @@
 static struct board_features_t {
char*   compatible;
u32 features;
-} board_features_datas[] __init =
+} board_features_datas[] __initdata =
 {
   {"AAPL,PowerMac G3", 0   }, /* Beige G3 */
   {"iMac,1",   0   }, /* First iMac 
(gossamer) */

-- 
Regards,
Rasmus([EMAIL PROTECTED])

We're going to turn this team around 360 degrees.
-Jason Kidd, upon his drafting to the Dallas Mavericks
-
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] (part 7) fs/super.c cleanups


Handling of refcounts for FS_SINGLE filesystems moved to
add_vfsmnt(). That's the first half of real fix for FS_SINGLE mess -
we should make it "read_super() if we hadn't done it yet, otherwise
return what we have". That will make kern_mount() uses simpler and
remove all special-casing with refcounts. in the hindsight, the trick
I've used in 2.4.0-test2 merge was ugly - kern_mount() should be used
only when kernel explicitly asks for a vfsmount of its own, not as
as part of init for FS_SINGLE filesystems. Fix is easy, but that chunk
touches several files besides fs/super.c and requires sane locking
to be safe. Patch below is the preliminary part local to fs/super.c.

Please, apply.

diff -urN S5-pre6-kern_mount/fs/super.c S5-pre6-single1/fs/super.c
--- S5-pre6-kern_mount/fs/super.c   Fri May 25 15:07:19 2001
+++ S5-pre6-single1/fs/super.c  Fri May 25 15:12:36 2001
@@ -367,6 +367,8 @@
list_add(>mnt_instances, >s_mounts);
list_add(>mnt_list, vfsmntlist.prev);
spin_unlock(_lock);
+   if (sb->s_type->fs_flags & FS_SINGLE)
+   get_filesystem(sb->s_type);
 out:
return mnt;
 fail:
@@ -852,7 +854,6 @@
sb = fs_type->kern_mnt->mnt_sb;
if (!sb)
BUG();
-   get_filesystem(fs_type);
do_remount_sb(sb, flags, data);
return sb;
 }
@@ -1165,8 +1166,6 @@
goto out2;
 
err = -ENOMEM;
-   if (old_nd.mnt->mnt_sb->s_type->fs_flags & FS_SINGLE)
-   get_filesystem(old_nd.mnt->mnt_sb->s_type);

down(_sem);
/* there we go */
@@ -1177,8 +1176,6 @@
err = 0;
up(_nd.dentry->d_inode->i_zombie);
up(_sem);
-   if (err && old_nd.mnt->mnt_sb->s_type->fs_flags & FS_SINGLE)
-   put_filesystem(old_nd.mnt->mnt_sb->s_type);
 out2:
path_release(_nd);
 out1:
@@ -1369,8 +1366,6 @@
return retval;
 
 fail:
-   if (fstype->fs_flags & FS_SINGLE)
-   put_filesystem(fstype);
kill_super(sb);
goto unlock_out;
 }

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Doug Ledford

"Adam J. Richter" wrote:
> 
> Doug Ledford wrote:
> >"Adam J. Richter" wrote:
> 
> >> On the question of whether this is nothing more than
> >> aggregation,
> 
> >Yes, on that very question, I would argue it is a mere aggregation.
> 
> >> the firmware works intimately with the device driver to
> >> produce a unitary result.
> 
> >Irrelevant.
> 
> The 1991 Abridged 6th Edition of _Black's Law Dictionary_
> defines "aggregation" thusly (unfortunately, talking in terms of
> patent law, but it is the most authoratitive definition I have found
> so far):
> 
> Aggregation: The combination of two or more elements in patent claims,

So the first thing the attorney would have to do is convince the judge that
the definition of a term from patent claims means what you are claiming it
means in software licensing claims.

> each of which is unrelated and each of which performs separately and
> without cooperation , where combination does not define a composite
> integrate mechanism.  Term means that the elements of a claimed
> combination are incapabile of co-operation to produce a unitary
> result, and in its true sense does not need prior art patents to
> support it.
> 
> If you want to argue that a court will use a different definition
> of aggregation, then please explain why and quote that definition.

Why is because the definition you have been pushing here is anything that
results in a "unitary" result.  That's flawed (it's actually quite insane
IMNSHO, since the major point of my last email was that *damn near everything*
in the computer world results in a "unitary" result, including the glibc ->
kernel syscall interface Larry mentions in his email, the module loading
interface that the kernel exports, etc.  The point of my last email was
largely that what you are calling a "unitary" result, is in fact what most
people call an API).  To quote Larry, it would take roughly 30 seconds to get
that definition of "unitary" result thrown out as overly broad.

>  Also,
> it's important not to forget the word "mere."  If the combination is anything
> *more* than aggregration, then it's not _merely_ aggregation.  So,
> if you wanted to argue from the definition on webster.com:
> 
> 1 : a group, body, or mass composed of many distinct parts
> or individuals
> 2 a : the collecting of units or parts into a mass or whole
>   b : the condition of being so collected
> 
> You have to argue that absolutely nothing more than this
> is being done.  For example, the code the parts are not working
> together.

Yep, that's pretty much what it is.  The firmware is what actually implements
the API on the device we are discussing.  The driver interacts via said API. 
The firmware is actually an opaque object that could be replaced with any
other firmware that implements the same API and things would work the same. 
The downloading of the firmware is just one step in the initialization of the
device and is not dependant on any given firmware version or release.  The
placing of the driver that downloads any valid firmware to the device (or
invalid for that matter) and the firmware itself in the same .o is a matter of
convenience and is merely collecting two individual parts into a mass.

> >All drivers work with some sort of firmware on their respective
> >targets to produce a unitary result, even if that firmware is implemented with
> >silicon (as a ROM BIOS that loads the proper firmware code, or as
> >microcode/state hardware built into the chip(set) itself).  As a closely
> >similar device, think about the 1542 SCSI controller.  [...]
> 
> Yes.  It would also be illegal to distribute a GPL'ed driver
> .o that #include'd that proprietary firmware.
> 
> >>  You actually have to do some
> >> kernel development to remove the
> >> [proprietary firmware from the keyspan_usa drivers].
> 
> >That's because you are assuming that uploading garbage to the device is not an
> >option.
> 
> No.  If I you change the driver to upload garbage, your
> userland loader that just looks for the unitialized device ID will
> not be able to get to the uninitialized device before the device
> driver claims the interface and trashes it.  So, your supposed act of
> disaggregation by zeroing out the effected bytes did not fully
> restore the old functionality.

You missed the point.  The firmware is an opaque object to the driver, not an
integral part of the driver.  Read above.

> >That is exactly the case.  The only change that must be made to remove that .h
> >file from the driver source is to tell the driver where the *new* location of
> >the correct firmware is.
> 
> What do you mean "remove the .h file" from the .o and
> "tell the driver" (open your mouth and talk to the screen?).

The current driver knows where the firmware is by #include'ing it in itself. 
That is, in and of itself, a means of locating the

[PATCH] (part 6) fs/super.c cleanups


Expands add_vfsmnt() call in kern_mount(), takes alloc_vfsmnt()
before reading superblock and makes (in add_vfsmnt()) insertion into
vfsmntlist unconditional (kern_mount()) was the only case when we didn't
want it to happen. Moreover, recovery in kern_mount() becomes simpler.

Please, apply.
diff -urN S5-pre6-alloc_vfsmnt/fs/super.c S5-pre6-kern_mount/fs/super.c
--- S5-pre6-alloc_vfsmnt/fs/super.c Fri May 25 04:13:30 2001
+++ S5-pre6-kern_mount/fs/super.c   Fri May 25 15:07:19 2001
@@ -365,8 +365,7 @@
mnt->mnt_parent = mnt;
}
list_add(>mnt_instances, >s_mounts);
-   if (nd || dev_name)
-   list_add(>mnt_list, vfsmntlist.prev);
+   list_add(>mnt_list, vfsmntlist.prev);
spin_unlock(_lock);
 out:
return mnt;
@@ -945,21 +944,31 @@
 
 struct vfsmount *kern_mount(struct file_system_type *type)
 {
-   kdev_t dev = get_unnamed_dev();
struct super_block *sb;
-   struct vfsmount *mnt;
-   if (!dev)
+   struct vfsmount *mnt = alloc_vfsmnt();
+   kdev_t dev;
+
+   if (!mnt)
+   return ERR_PTR(-ENOMEM);
+
+   dev = get_unnamed_dev();
+   if (!dev) {
+   kfree(mnt);
return ERR_PTR(-EMFILE);
+   }
sb = read_super(dev, NULL, type, 0, NULL, 0);
if (!sb) {
put_unnamed_dev(dev);
+   kfree(mnt);
return ERR_PTR(-EINVAL);
}
-   mnt = add_vfsmnt(NULL, sb->s_root, NULL);
-   if (!mnt) {
-   kill_super(sb);
-   return ERR_PTR(-ENOMEM);
-   }
+   mnt->mnt_sb = sb;
+   mnt->mnt_root = dget(sb->s_root);
+   mnt->mnt_mountpoint = mnt->mnt_root;
+   mnt->mnt_parent = mnt;
+   spin_lock(_lock);
+   list_add(>mnt_instances, >s_mounts);
+   spin_unlock(_lock);
type->kern_mnt = mnt;
return mnt;
 }

-
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: DVD blockdevice buffers

2001-05-25 Thread Stephen C. Tweedie

Hi,

On Fri, May 25, 2001 at 02:24:52PM -0400, Alexander Viro wrote:

> If you are OK with adding two extra arguments to ->readpage() I could
> submit a patch replacing that with plain and simple page cache by tomorrow.
> It should not be a problem to port, but I want to get some sleep before
> testing it...

The problem will be returning the IO completion status.  We can't just
rely on PG_Error: what happens if two separate partial reads are
submitted at once within the same page, yet the page is not completely
in cache?  If we forced readpage to be synchronous in that case we
could just return the status directly.  Otherwise we need a separate
way of determining the completion status once the page becomes
unlocked (eg. have a special readpage return which means "all done,
completion status is X", and resubmit the readpage to get that
completion status once the page lock is dropped.)

--Stephen

-
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: [CHECKER] error path memory leaks in 2.4.4 and 2.4.4-ac8

2001-05-25 Thread arjan

In article <[EMAIL PROTECTED]> you wrote:
>> I believe we can make that a short. Arjan?

> Is the general way to fix these too-large stack vars to heap allocate
> them?  Or is it preferable to put a "static" in front of them, if the
> routine is non-reentrant?

You're not always allowed to allocate memory. Esp in filesystems it can be
tricky as writes can be triggered by low-memory situations and allocating
memory their is suboptimal.
-
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: DVD blockdevice buffers

2001-05-25 Thread Stephen C. Tweedie

Hi,

On Fri, May 25, 2001 at 09:09:37AM -0600, Eric W. Biederman wrote:

> The case we don't get quite right are partial reads that hit cached
> data, on a page that doesn't have PG_Uptodate set.  We don't actually
> need to do the I/O on the surrounding page to satisfy the read
> request.  But we do because generic_file_read doesn't even think about
> that case.

That's *precisely* the case in question.  The whole design of the page
cache involves reading entire pages at a time, in fact.  We _could_
read in only partial pages, but in that case we end up wasting a lot
of the page.

> For the small random read case we could use a 
> mapping->a_ops->readpartialpage 
> function that sees if a request can be satisfied entirely 
> from cached data.  But this is just to allow generic_file_read
> to handle this, case. 

Agreed.  The only case where blockdev-in-pagecache really results in
significantly more IO is partial writes followed by partial reads.
Reads from totally-uncached pages ought to just fill the entire page
from disk; it's only when there is something already present
in the cache for that page that we want to look for partial buffers.

--Stephen
-
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: CRAK: a process checkpoint/restart kernel module

2001-05-25 Thread Hua Zhong

Please cc to me - I am currently off the list.

On Wed, 23 May 2001, Pavel Machek wrote:

> Hi!!
>
> One question: can crak be used for process migration (assuming nodes
> share filesystem)? [As in, node of
> cluster is going down so we checkpoint and resume on some other node?]

Yes, as long as the resources (opened files) can be accessed on both
nodes.

> PS: Can it checkpoint/restart X applications? I guess some games would
> be easier with ability to checkpoint ;-)

Which means we need to support migrating network sockets.  I added
TCP/IPv4 socket support this spring (currently for 2.2.19 and will port to
2.4 shortly), and I tested migrating X.  In certain cases I
successfully migrated some applications like Emacs, Acroread, etc, but
there is a problem.  (The socket migration code has not been put online,
but I'd like to discuss how it works here)

Basically I took three steps to migrate a TCP socket.  Assuming A and B
are the two peers:

1. shutdown process A while keep B open
2. restart A and re-establish the socket which points to B
3. change the socket on B to point to the new location of A

The problem is, during this stage, if B sends packets to A before 3 is
complete, B's socket will get a RST.  In the case of X, if you click or
move cursor on A's window when A is being migrated, it will crash.

One solution might be that freezing B when A is being migrated.  There are
two ways to freeze B:

1) send a SIGSTOP to B and later SIGCONT it.  It's simple to do but would
result in freezing the whole process, which is bad in certain cases (e.g.,
the whole X server is stopped - the screen freezes).

2) freeze the socket only.  I tried to set window sizes of B's socket to
zero, but it didn't work (I didn't try too hard though).  I'd like to know
whether there is a way to do so.

Unfortunately, even we use 1), it still doesn't solve the whole problem.
For exmaple, when the X connection is tunneled through ssh, you can only
freeze the sshd process, but packets are still sent to it when you click
on the server side, which will crash the connection as well (at least for
my current implementation).  One reason might be I didn't take care of
pending packets when I migrage a socket, but in fact, the real problem of
socket migration is that you don't know what would happen if the network
address is changed.  Appliactions may depend on it (such as FTP).  A
virtual network interface should be provided to solve the problem
gracefully.

As of migrating games, hmmm, here are my 2cents:

1) Most online games use UDP, and CRAK hasn't implemented UDP support.
It's much easier than TCP though.
2) I am not sure of what the effect would be if we changed the network
address.  Most games requires you to join a group before you start, and
maybe the group membership is based on network address.

At last, there are a lot of work left to do to make process migration work
truly reliably, and CRAK is still far from that.  For example, what if an
application depends on pid?  What if a process uses temporary files
(/tmp) which are not present on other nodes?  Or what if an application
deletes files that are still opened (evil programs like make)?  Not all of
these are possible, or possible without enough kernel cooperation.
Particularly hard when CRAK is just a kernel module.

I am still a lerner.  I wrote CRAK mostly for fun, but I'd like to
hear some advice from the kernel hacker community if people think it has
some value.

> --
> Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
> details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
>

Hua Zhong

Central Research Facilities Department of Computer Science
Columbia University New York, NY 10027
Email: [EMAIL PROTECTED] http://www.cs.columbia.edu/~huaz

-
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: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

2001-05-25 Thread dean gaudet


On Sat, 26 May 2001, Keith Owens wrote:

> On Fri, 25 May 2001 08:31:24 -0700 (PDT),
> dean gaudet <[EMAIL PROTECTED]> wrote:
> >another possibility for a debugging mode for the kernel would be to hack
> >gcc to emit something like the following in the prologue of every function
> >(after the frame is allocated):
>
> IKD already does that, via the CONFIG_DEBUG_KSTACK, CONFIG_KSTACK_METER
> and CONFIG_KSTACK_THRESHOLD options.  No need to hack gcc.

oh nice!  you hook in through gcc -pg mcount stuff.

-dean

-
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: Why O_SYNC and fsync are slow in Linux?

2001-05-25 Thread Lance Larsh

On Wed, 16 May 2001, Heikki Tuuri wrote:

> On Red Hat 6.2 and 7.? Intel big block writes are very slow if
> I open the file with O_SYNC. I call pwrite to write 1 MB chunks to
> the file, and I get only 1 MB/s write speed. If I open without O_SYNC
> and call fsync only after writing the whole 100 MB file,
> I get 5 MB/s. I got the same adequate speed 5 MB/s with 16 MB writes
> after which I called fdatasync.

When you open with O_SYNC, the data must go all the way to disk on
every write call.  This means you get at least one disk access for
every write, and possibly more if the writes are large (>64k).

When you don't use O_SYNC and only flush after all writes have been
submitted by the application, then the kernel is able to combine writes
in the cache and at the blk dev layer.  Therefore you end up with fewer
accesses to the physical disk, which makes it much faster.

> On a Linux-Compaq Alpha I measured the following: if I open with O_SYNC,
> I can flush the end of my file (it is a log file) to
> disk 170 times / second. If I do not open with O_SYNC,
> but call fsync or fdatasync after each write, I get only 50
> writes/second.

This is generally the case.  If you need to sync every write, O_SYNC
is usually faster than fsync.  If you don't need to sync
every individual write, then a single fsync after the last
write is the fastest to get all the data to disk.

> 
> On the Red Hat 7.? I get 500 writes per second if I open with O_SYNC.
> That is too much because the disk does not rotate
> 500 rotations/second. Does the disk fool the operating
> system to believe a write has ended while it has not?

Are you using an IDE disk?  If so, it probably has a huge cache.

-Lance

-
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] (part 5) fs/super.c cleanups


Takes allocation/initalization of vfsmounts into separate function.
We will need this separation to deal with several places where we need
a non-blocking (and non-failing) equivalent of add_vfsmnt(). There allocation
will be done outside of critical area.

Please, apply.

diff -urN S5-pre6-MNT_VISIBLE/fs/super.c S5-pre6-alloc_vfsmnt/fs/super.c
--- S5-pre6-MNT_VISIBLE/fs/super.c  Thu May 24 23:57:23 2001
+++ S5-pre6-alloc_vfsmnt/fs/super.c Fri May 25 04:13:30 2001
@@ -282,6 +282,21 @@
 
 static LIST_HEAD(vfsmntlist);
 
+struct vfsmount *alloc_vfsmnt(void)
+{
+   struct vfsmount *mnt = kmalloc(sizeof(struct vfsmount), GFP_KERNEL); 
+   if (mnt) {
+   memset(mnt, 0, sizeof(struct vfsmount));
+   atomic_set(>mnt_count,1);
+   INIT_LIST_HEAD(>mnt_clash);
+   INIT_LIST_HEAD(>mnt_child);
+   INIT_LIST_HEAD(>mnt_mounts);
+   INIT_LIST_HEAD(>mnt_list);
+   mnt->mnt_owner = current->uid;
+   }
+   return mnt;
+}
+
 static void detach_mnt(struct vfsmount *mnt, struct nameidata *old_nd)
 {
old_nd->dentry = mnt->mnt_mountpoint;
@@ -324,10 +339,9 @@
struct super_block *sb = root->d_inode->i_sb;
char *name;
 
-   mnt = kmalloc(sizeof(struct vfsmount), GFP_KERNEL);
+   mnt = alloc_vfsmnt();
if (!mnt)
goto out;
-   memset(mnt, 0, sizeof(struct vfsmount));
 
/* It may be NULL, but who cares? */
if (dev_name) {
@@ -337,8 +351,6 @@
mnt->mnt_devname = name;
}
}
-   mnt->mnt_owner = current->uid;
-   atomic_set(>mnt_count,1);
mnt->mnt_sb = sb;
 
spin_lock(_lock);
@@ -351,10 +363,7 @@
} else {
mnt->mnt_mountpoint = mnt->mnt_root;
mnt->mnt_parent = mnt;
-   INIT_LIST_HEAD(>mnt_child);
-   INIT_LIST_HEAD(>mnt_clash);
}
-   INIT_LIST_HEAD(>mnt_mounts);
list_add(>mnt_instances, >s_mounts);
if (nd || dev_name)
list_add(>mnt_list, vfsmntlist.prev);

-
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: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

2001-05-25 Thread dean gaudet

On Fri, 25 May 2001, Jonathan Lundell wrote:

> At 8:45 AM -0700 2001-05-25, dean gaudet wrote:
> >i think it really depends on how you use current -- here's an alternative
> >usage which can fold the extra addition into the structure offset
> >calculations, and moves the task struct to the top of the stack.
> >
> >not that this really solves anything, 'cause a stack underflow will just
> >trash something else rather than the task struct :)
>
> It would open the door for putting a guard page (which only occupies
> virtual space, after all) below the stack. I have no idea whether
> that's practical, given other constraints, but it's a potential
> benefit of having the stack at the bottom rather than the top of a
> page.

somewhere else in the thread someone indicated this was a hard thing to
do.

also you don't need the task struct at the top to do this -- you just
allocate 16k instead of 8k, put the task struct on page 0 of the
allocation, unmap page 1, and put the stack frame on pages 2 and 3.
(you'd probably have to do a 16k allocation regardless to get the guard
page.)

-dean

-
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] (part 4) fs/super.c cleanup


* MNT_VISIBLE is gone. We simply do not insert vfsmounts we don't
want to see into the vfsmntlist. The only place where it is used is
get_filesystem_info(), so it's obviously correct.

Please, apply.

PS: I've done a different locking scheme for superblocks, so right
now I'm testing it on a complete patch. I.e. that part is postponed until
it gets some testing. So the next several pieces will be just a bunch
of trivial cleanups.

diff -urN S5-pre6/fs/super.c S5-pre6-MNT_VISIBLE/fs/super.c
--- S5-pre6/fs/super.c  Thu May 24 22:15:03 2001
+++ S5-pre6-MNT_VISIBLE/fs/super.c  Thu May 24 23:57:23 2001
@@ -314,13 +314,6 @@
  * Potential reason for failure (aside of trivial lack of memory) is a
  * deleted mountpoint. Caller must hold ->i_zombie on mountpoint
  * dentry (if any).
- *
- * Node is marked as MNT_VISIBLE (visible in /proc/mounts) unless both
- * @nd and @devname are %NULL. It works since we pass non-%NULL @devname
- * when we are mounting root and kern_mount() filesystems are deviceless.
- * If we will get a kern_mount() filesystem with nontrivial @devname we
- * will have to pass the visibility flag explicitly, so if we will add
- * support for such beasts we'll have to change prototype.
  */
 
 static struct vfsmount *add_vfsmnt(struct nameidata *nd,
@@ -336,9 +329,6 @@
goto out;
memset(mnt, 0, sizeof(struct vfsmount));
 
-   if (nd || dev_name)
-   mnt->mnt_flags = MNT_VISIBLE;
-
/* It may be NULL, but who cares? */
if (dev_name) {
name = kmalloc(strlen(dev_name)+1, GFP_KERNEL);
@@ -366,7 +356,8 @@
}
INIT_LIST_HEAD(>mnt_mounts);
list_add(>mnt_instances, >s_mounts);
-   list_add(>mnt_list, vfsmntlist.prev);
+   if (nd || dev_name)
+   list_add(>mnt_list, vfsmntlist.prev);
spin_unlock(_lock);
 out:
return mnt;
@@ -500,8 +491,6 @@
 
for (p = vfsmntlist.next; p !=  p = p->next) {
struct vfsmount *tmp = list_entry(p, struct vfsmount, mnt_list);
-   if (!(tmp->mnt_flags & MNT_VISIBLE))
-   continue;
path = d_path(tmp->mnt_root, tmp, buffer, PAGE_SIZE);
if (!path)
continue;
diff -urN S5-pre6/include/linux/mount.h S5-pre6-MNT_VISIBLE/include/linux/mount.h
--- S5-pre6/include/linux/mount.h   Thu May 24 22:15:06 2001
+++ S5-pre6-MNT_VISIBLE/include/linux/mount.h   Thu May 24 23:58:00 2001
@@ -12,8 +12,6 @@
 #define _LINUX_MOUNT_H
 #ifdef __KERNEL__
 
-#define MNT_VISIBLE1
-
 struct vfsmount
 {
struct dentry *mnt_mountpoint;  /* dentry of mountpoint */

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Larry McVoy

On Fri, May 25, 2001 at 10:02:08AM -0700, Adam J. Richter wrote:
>   If you want to argue that a court will use a different definition
> of aggregation, then please explain why and quote that definition.  Also,
> it's important not to forget the word "mere."  If the combination is anything
> *more* than aggregration, then it's not _merely_ aggregation.  So,
> if you wanted to argue from the definition on webster.com:

Adam, the point is not what the GPL says or what the definition is.
The point is "what is legal".  You can, for example, write a license
which says

By running the software covered by this license, you agree to 
become my personal slave and you will be obligated to bring
me coffee each morning for the rest of my life, greating
me with a "Good morning, master, here is your coffee oh
most magnificent one".

If anyone is stupid enough to obey such a license, they need help.
The problem is that licenses can write whatever they want, but what they
say only has meaning if it is enforceable.  The "license" above would
be found to be unenforceable by the courts in about 30 seconds or so.

OK, so what does this have to do with aggregration?  The prevailing 
legal opinions seem to be that viral licenses cannot extend their
terms across boundaries.  The aggregration verbage is alluding to that
boundary.  If it is true that viral licenses cannot cross some sort of
boundary (and obviously it is true, otherwise the system call boundary
would not be recognized and all programs ever run on Linux would be GPLed),
then the GPL doesn't get to say what it means by that boundary, the law
gets to say that.  Just like the above "license" doesn't get to create
slaves, some issues are outside the license scope.

I've spoken with my lawyer in depth about this and the feeling is that
there are boundaries which licenses may not cross, and the definition
of such a boundary is one where you could remove the code on one side
of the boundary (aka interface), replace it with completely different 
code, and get substantially the same behaviour.  A device driver is a
good example.  
-- 
---
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: OOM process killer: strange X11 server crash...

2001-05-25 Thread Jesse Pollard


Ishikawa <[EMAIL PROTECTED]>:

>Anyway, this time, here is what was printed on the screen (the tail end
> of it).
> --- begin quote ---
> ... could not record the above. they scrolled up and disapper...
> Out of Memory: Killed process 4550 (XF8_SVGA.ati12).
> __alloc_pages: 0-order allocation failed.
> VM: killing process XF86_SVGA.ati12
> --- end quote
> 
> And before the message disappeared, I think I saw the
> netscape process was killed, too.
> I checked the log message and looked for "Memory"
> Sure enough I foundnetscapewas killed, too, in this case.
> 
> May 25 09:16:46 duron kernel: Memory: 255280k/262080k available (978k
> kernel cod
> e, 6412k reserved, 378k data, 224k init, 0k highmem)
> ...
> May 25 10:45:31 duron kernel: Out of Memory: Killed process 5562
> (netscape).
> May 25 10:45:31 duron kernel: Out of Memory: Killed process 5450
> (XF86_SVGA.ati1
> 2).
>  ...

Something I have noticed with netscape is that if the X server is
killed out from under it (user logout, or kill X11 manually) is that
it continues to run. The process appears to be looping around select
and attempting to reconnect to the (now dead) X server, and not exiting
like it should.

Other times it seems to terminate properly. The problem may exhibit itself
if netscape is waiting for some asynchronous event (like the name service
lookup maybe) and misses the/a signal that it's socket to the X server
has failed. If a kill -15 doesn't terminate the rogue netscape, then it
takes a kill -9 . In my expierence it is in a tight loop, and ignoring
normal user input. It could still be expanding memory consumption...


-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
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: DVD blockdevice buffers

On Fri, 25 May 2001, Linus Torvalds wrote:

> For example, I suspect that the metadata bitmaps in particular cache so
> well that the fact that we need to do several seeks over them every once
> in a while is a non-issue: we might be happier having the bitmaps in
> memory (and having simpler code), than try to avoid the occasional seeks.
>
> The "simpler code" argument in particular is, I think, a fairly strong
> one. Our current bitmap code is quite horrible, with multiple layers of
> caching (ext2 will explicitly hold references to some blocks, while at the
> same time depending on the buffer cache to cache the other blocks -
> nightmare)

Oh, current code is a complete mess - no arguments here. 8-element LRU.
Combined with the fact that directories allocation tries to get even
distribution of directory inodes by cylinder groups, you blow that LRU
completely on a regular basis if your fs is larger that 16 cg. For 1Kb
blocks fs it's 128Mb. For 4Kb - 2Gb. And pain starts at the half of that
size.

If you are OK with adding two extra arguments to ->readpage() I could
submit a patch replacing that with plain and simple page cache by tomorrow.
It should not be a problem to port, but I want to get some sleep before
testing it...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: DVD blockdevice buffers

On Fri, 25 May 2001, Alexander Viro wrote:
> 
> OK, here's a real-world scenario: inode table on 1Kb ext2 (or 4Kb on
> Alpha, etc.) consists of compact pieces - one per cylinder group.
> 
> There is a natural mapping from inodes to offsets in that beast.
> However, these pieces can trivially be not page-aligned. readpage()
> on a boundary of two pieces means large seek.

Yes.

But by "real-world" I mean "you can tell in real life".

I see the theoretical arguments for it. But I want to know that it makes a
real difference under real load.

For example, I suspect that the metadata bitmaps in particular cache so
well that the fact that we need to do several seeks over them every once
in a while is a non-issue: we might be happier having the bitmaps in
memory (and having simpler code), than try to avoid the occasional seeks.

The "simpler code" argument in particular is, I think, a fairly strong
one. Our current bitmap code is quite horrible, with multiple layers of
caching (ext2 will explicitly hold references to some blocks, while at the
same time depending on the buffer cache to cache the other blocks -
nightmare)

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: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Torrey Hoffman

Adam J. Richter wrote:
> Doug Ledford wrote:
> >"Adam J. Richter" wrote:
> 
> >> On the question of whether this is nothing more than
> >> aggregation,

... 
[patent law definition of aggregation]
...

Well, I'm just an interested bystander.  But having read the recent 
lkml posts on this issue, it seems to me that the critical points are:

>From the point of view of the kernel, the firmware code is just a big
magic number that "turns on" the firmware.  

The kernel is not _linked_ _with_ the firmware code.

The kernel doesn't even _exec_ the firmware.

The firmware code can be used, unmodified, in other operating systems.

The firmware code does not run in the same address space as the kernel.

In principle, and maybe in practice, that firmware code might be running
on a different processor, with different RAM, and a different instruction
set.  

It's obviously not part of the kernel! 

Torrey Hoffman  -  [EMAIL PROTECTED]
---
I find this corpse guilty of carrying a concealed weapon and I fine it $40. 
-- Judge Roy Bean, finding a pistol and $40 on a man he'd just shot. 
-
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.x: update for PCI vendor id 0x12d4

2001-05-25 Thread Khachaturov, Vassilii


This is my 1st attempt to submit a patch here - flames welcome if I did smth
wrong...
It was done across 2.4.2, but it works safely against 2.4.4 as well.

 <> 

Kind regards,
Vassilii

 pci_vendor_12d4.patch

Re: [CHECKER] free bugs in 2.4.4 and 2.4.4-ac8