Re: A signal fairy tale

[Balbir Singh]

Shouldn't there be a sigclose() and other operations to make the API
orthogonal. sigopen() should be selective about the signals it allows
as argument. Try and make sigopen() thread specific, so that if one
thread does a sigopen(), it does not imply it will do all the signal
handling for all the threads.

Does using sigopen() imply that signal(), sigaction(), etc cannot be used.
In the same process one could do a sigopen() in the library, but the
process could use sigaction()/signal() without knowing what the library
does (which signals it handles, etc).

Let me know, when somebody has a patch or needs help, I would like to
help or take a look at it.

Balbir

|NAME
|   sigopen - open a signal as a file descriptor
| 
|SYNOPSIS
|   #include 
| 
|   int sigopen(int signum);
| 
|DESCRIPTION
|   The sigopen system call opens signal number signum as a file descriptor.
|   That signal is no longer delivered normally or available for pickup
|   with sigwait() et al.  Instead, it must be picked up by calling
|   read() on the file descriptor returned by sigwait(); the buffer passed to
|   read() must have a size which is a multiple of sizeof(siginfo_t).
|   Multiple signals may be picked up with a single call to read().
|   When that file descriptor is closed, the signal is available once more 
|   for traditional use.
|   A signal number cannot be opened more than once concurrently; sigopen() 
|   thus provides a way to avoid signal usage clashes in large programs.
|
|RETURN VALUE
|   signal returns the new file descriptor, or -1 on error (in which case, errno
|   is set appropriately).
|
|ERRORS
|   EWOULDBLOCK signal is already open
|
|NOTES
|   read() will block when reading from a file descriptor opened by sigopen()
|   until a signal is available unless fcntl(fd, F_SETFL, O_NONBLOCK) is called
|   to set it into nonblocking mode.
|
|HISTORY
|   sigopen() first appeared in the 2.5.2 Linux kernel.
|
|Linux  July, 2001 1   
|

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

Re: NETDEV WATCHDOG with 2.4.5

[Andrew Morton]

Tim Timmerman wrote:
> 
> > "kees" == kees  <[EMAIL PROTECTED]> writes:
> 
> kees> Hi,
> 
> kees> I tried 2.4.5 but after a couple of hours I lost all network
> kees> connectivety.  The log shows:
> 
> Can I just add a me too here ?
> 
> System: Abit BP6, Dual Celeron, Ne2k-pci, usb ohci and
> scanner; 128 Mb Ram, Nvidia TNT2 graphics. Kernel 2.4.5

ne2k and, to a lesser extent, 3c59x do not work correctly on many
x86 SMP machines because of a problem with the APIC interrupt
controller.

Probable fixes include booting with the `noapic' option,
running -ac kernels or applying Maciej's APIC workaround
patch.  There's a copy at http://www.uow.edu.au/~andrewm/linux/apic.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NETDEV WATCHDOG with 2.4.5

[Tim Timmerman]

> "kees" == kees  <[EMAIL PROTECTED]> writes:

kees> Hi,

kees> I tried 2.4.5 but after a couple of hours I lost all network
kees> connectivety.  The log shows:

Can I just add a me too here ?

System: Abit BP6, Dual Celeron, Ne2k-pci, usb ohci and
scanner; 128 Mb Ram, Nvidia TNT2 graphics. Kernel 2.4.5

After scanning a couple of images (scanner is a Mustek 1200cu)
using Xsane, the system simply hangs. All network connectivity
dies, and the system basically stops responding. I can switch
consoles, and maybe log in[1], but that's basically it.

Debugging this is a bit beyond me, but it is fairly
reproducible, so let me know what I need to do to provide
useful information (The system is not critical, though I'd
prefer not to break it)

Sorry, no logs.. 

TimT. 

[1] /var/spool/mail is NFS mounted, so a check for mail times out. 

-- 
[EMAIL PROTECTED]  040-2683613
[EMAIL PROTECTED]   Voodoo Programmer/Keeper of the Rubber Chicken
I've been doing a lot of abstract painting lately, extremely
abstract. No brush, no paint, no canvas, I just think about 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/

pc°ü·ÃÁ¤º¸ÀÔ´Ï´Ù

[comzon]

ÃÖ½ÅÇüPC
CPU¡¦¡¦¡¦.933 (ÀÎÅÚ)
RAM¡¦¡¦¡¦128 (»ï¼ºÁ¤Ç°133)
HDD¡¦¡¦¡¦30 G
MONITER.17"(»ï¼º77E)

¸ðµÎ43¸¸¿ø

°ü½ÉÀÖÀ¸¼¼¿ä

 http://comzon.atozpia.com/news/news.html

À̸®·Î ¿À¼¼¿ä
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] User chroot

[David Wagner]

Mohammad A. Haque wrote:
>Why do this in the kernel when it's available in userspace?

Because the userspace implementations aren't equivalent.
In particular, it is not so easy for them to enforce the following
restriction:
  (*) If a non-root user requested the chroot, then setuid/setgid
  bits won't have any effect under the new root.
The proposed kernel patch respects (*), but I'm not aware of any
user-level application that ensures (*) is followed.

(Also, there is the small matter that the user-level implementations
are only usable by root, or are setuid root.  The latter is only a
minor difference, though, IMHO.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Process creating

[Blesson Paul]

hi all
  I have in a confusion regarding the creation of
processes by the kernel. Let I have two processes P1 and P2, both are childs
of P0. I want to know the following facts regarding P1 and P2. I have created
two processes by forking. Everyone knows that when P1 and P2 created, they
have different process spaces. 
1  If I point  to a address 0x434343 in P1 and  P2, will it point to the  
same memory area.
2  If not, I need two processes to use same process area, how to do that
3  Will linux kernel support threading
Actually I first thought about shared memory. But
for my application, I need huge memory area upto 50MB or more. So 50MB of
shared memory is no good. So I looking for any other alternatives

   by
  Blesson


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

driver/sound/soundcard.c lock_kernel()/unlock_kernel()

[Frank Davis]

Hello all,
  I've been looking through the sound drivers in the 2.4.5-ac series
.  
drivers/sound/soundcard.c has a few lock_kernel()/unlock_kernel() calls,
esp. in the read() and write() functions. Could these calls be easily
replaced with semaphores or spinlock calls? I vaguely remember emails on
lkml a while ago regarding the removal of lock_kernel()/unlock_kernel(),
but I'm don't recall what the replacement was (if any).
Regards,
Frank

btw, Sorry in advance if the mailer causes probelms.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] User chroot

[H. Peter Anvin]

Albert D. Cahalan wrote:

> 
> Normal users can use an environment provided for them.
> 
> While trying to figure out why the "heyu" program would not
> work on a Red Hat box, I did just this. As root I set up all
> the device files needed, along Debian libraries and the heyu
> executable itself. It was annoying that I couldn't try out
> my chroot environment as a regular user.
> 
> Creating the device files isn't a big deal. It wouldn't be
> hard to write a setuid app to make the few needed devices.
> If we had per-user limits, "mount --bind /dev/zero /foo/zero"
> could be allowed. One way or another, devices can be provided.
> 


Hell no!  This would give the user a way to subvert root or other 
system-provided things by having device nodes or such appear where they 
aren't expected.  NOT GOOD.

-hpa


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: A signal fairy tale

[Christopher Smith]

--On Tuesday, June 26, 2001 05:54:37 -0700 Dan Kegel <[EMAIL PROTECTED]> wrote:
> Once upon a time a hacker named Xman
> wrote a library that used aio, and decided
> to use sigtimedwait() to pick up completion
> notifications.  It worked well, and his I/O
> was blazing fast (since was using a copy
> of Linux that was patched to have good aio).
> But when he tried to integrate his library
> into a large application someone else had
> written, woe! that application's use of signals
> conflicted with his library.  "Fsck!" said Xman.
> At that moment a fairy appeared, and said
> "Young man, watch your language, or I'm going to
> have to turn you into a goon!  I'm the good fairy Eunice.
> Can I help you?"  Xman explained his problem to Eunice,
> who smiled and said "All you need is right here,
> just type 'man 2 sigopen'".  Xman did, and saw:

I must thank the god fair Eunice. ;-) From a programming standpoint, this 
looks like a really nice approach. I must say I prefer this approach to the 
various "event" strategies I've seen to date, as it fixes the primary 
problem with signals, while still allowing us to hook in to all the 
standard POSIX API's that already use signals. It'd be nice if I could pass 
in a 0 for signum and have the kernel select from unused signals (problem 
being that "unused" is not necessarily easy to define), althouh I guess an 
inefficient version of this could be handled in userland.

I presume the fd could be shared between threads and otherwise behave like 
a normal fd, which would be sper nice.

I guess the main thing I'm thinking is this could require some significant 
changes to the way the kernel behaves. Still, it's worth taking a "try it 
and see approach". If anyone else thinks this is a good idea I may hack 
together a sample patch and give it a whirl.

Thanks again good fairy Dan/Eunice. ;-)

--Chris

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

Re: PCI Power Management / Interrupt Context

[Jeff Garzik]

David T Eger wrote:
> when I read documentation (Documentation/pci.txt) which mentions that
> remove() can be called from interrupt context.

ignore that.  You can sleep in remove, and it will not be called from
interrupt context.


> Reading code in my sister frame buffer devices, I see that
> unregister_framebuffer() can fail.  I can easily see a nice happy console
> or user app diddling away on the framebuffer writing to the memory on the
> device, and then poof! someone yanks the card, processor takes an
> interrupt, and then... and then?  what to do?

if someone yanks the card, how is it going to deliver an interrupt to
the CPU?


> In fact, here's an interesting snippet from cyber2000fb.c:
> 
> static void __devexit cyberpro_remove(struct pci_dev *dev)
> {
> struct cfb_info *cfb = (struct cfb_info *)dev->driver_data;
> 
> if (cfb) {
> /*
> * If unregister_framebuffer fails, then
> * we will be leaving hooks that could cause
> * oopsen laying around.
> */
> if (unregister_framebuffer(>fb))
> printk(KERN_WARNING "%s: danger Will Robinson, "
> "danger danger!  Oopsen imminent!\n",
> cfb->fb.fix.id);
> cyberpro_unmap_smem(cfb);
> cyberpro_unmap_mmio(cfb);
> cyberpro_free_fb_info(cfb);
> 
> /*
> * Ensure that the driver data is no longer
> * valid.
> */
> dev->driver_data = NULL;
> if (cfb == int_cfb_info)
> int_cfb_info = NULL;
> }
> }
> 
> So, umm, is there a consensus on what to do if someone currently expects
> to be writing to memory that doesn't exist any more?

huh?  what are you talking about?  oops or random memory corruption
occurs.  there is no consensus necessary.

If you are worried about unregister_framebuffer failure, then don't
deallocate the memory, or sleep until unregister_framebuffer succeeds,
or any one of a number of workarounds.

Jeff


-- 
Jeff Garzik  | Andre the Giant has a posse.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: VM Requirement Document - v0.0

[Daniel Phillips]

> I personally don't feel that the cache should be allowed to grow over
> 50% of the system's memory at all, we've got so much in the cache at
> that point, that we're probably not hitting it all that much.

That depends very much on what you're using the system for.  Suppose you're 
running a trivial database application on a gigantic disk array - the name of 
the game is to cache as much metadata as possible, and that goes directly to 
the bottom line as performance.  Might as well use 90%+ of your memory for 
that.

The conclusion to draw here is, the balance between file cache and process 
memory should be able to slide all the way from one extreme to the other.  
It's not a requirement that that be fully automatic but it's highly 
desireable.

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

Compiling with gcc-3.0

[Steve Youngs]

I'm not on this list, followups set to my email address.

Trying to compile 2.4.5 with gcc-3.0 gives me this:

,
| gcc -D__KERNEL__ -I/usr/src/linux-2.4.5/include -Wall \
|   -Wstrict-prototypes -O2 -fomit-frame-pointer \
|   -fno-strict-aliasing -pipe \
|   -mpreferred-stack-boundary=2 -march=athlon \
|   -c -o timer.o timer.c
| 
| timer.c:35: conflicting types for `xtime'
| 
| /usr/src/linux-2.4.5/include/linux/sched.h:540: \
|   previous declaration of `xtime'
| 
| make[2]: *** [timer.o] Error 1
| make[2]: Leaving directory `/usr/src/linux-2.4.5/kernel'
| make[1]: *** [first_rule] Error 2
| make[1]: Leaving directory `/usr/src/linux-2.4.5/kernel'
| make: *** [_dir_kernel] Error 2
`

Has anyone else seen this?  Is it a problem with the kernel or gcc?
Have I just stuffed up the gcc installation?

I don't see this with gcc-2.95.2

Thanks very much for any light you can shed of this for me.

-- 
|-|
|  Ashes to ashes, dust to dust.   |
|  The proof of the pudding, is under the crust.   |
|-<[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] User chroot

[Albert D. Cahalan]

H. Peter Anvin writes:
> [somebody]

>> Have you ever wondered why normal users are not allowed to chroot?
>>
>> I have. The reasons I can figure out are:
>>
>> * Changing root makes it trivial to trick suid/sgid binaries to do
>>   nasty things.
>>
>> * If root calls chroot and changes uid, he expects that the process
>>   can not escape to the old root by calling chroot again.
>>
>> If we only allow user chroots for processes that have never been
>> chrooted before, and if the suid/sgid bits won't have any effect under
>> the new root, it should be perfectly safe to allow any user to chroot.
>
> Safe, perhaps, but also completely useless: there is no way the user
> can set up a functional environment inside the chroot.  In other
> words, it's all pain, no gain.

Normal users can use an environment provided for them.

While trying to figure out why the "heyu" program would not
work on a Red Hat box, I did just this. As root I set up all
the device files needed, along Debian libraries and the heyu
executable itself. It was annoying that I couldn't try out
my chroot environment as a regular user.

Creating the device files isn't a big deal. It wouldn't be
hard to write a setuid app to make the few needed devices.
If we had per-user limits, "mount --bind /dev/zero /foo/zero"
could be allowed. One way or another, devices can be provided.


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

PCI Power Management / Interrupt Context

[David T Eger]

So I'm writing some code for a PCI card that is a framebuffer device, and
happily filling in the functions for the probe() and remove() functions
when I read documentation (Documentation/pci.txt) which mentions that
remove() can be called from interrupt context.

Now in order to properly tear down some things in the system, there are
some standard unregister() interfaces.  For instance,
unregister_framebuffer() and unregister_netdev().  After which, drivers
believe all is safe and go on about releasing ioremap()'d regions and
such.

One of the first things that unregister_netdev() does is to down() the
rtnl semaphore.  *cough* *cough*  This is a blocking operation, I believe,
which, umm - you can't do that from an interrupt, correct?

Reading code in my sister frame buffer devices, I see that
unregister_framebuffer() can fail.  I can easily see a nice happy console
or user app diddling away on the framebuffer writing to the memory on the
device, and then poof! someone yanks the card, processor takes an
interrupt, and then... and then?  what to do? 

In fact, here's an interesting snippet from cyber2000fb.c:

static void __devexit cyberpro_remove(struct pci_dev *dev)
{
struct cfb_info *cfb = (struct cfb_info *)dev->driver_data;

if (cfb) {
/*
* If unregister_framebuffer fails, then
* we will be leaving hooks that could cause
* oopsen laying around.
*/
if (unregister_framebuffer(>fb))
printk(KERN_WARNING "%s: danger Will Robinson, "
"danger danger!  Oopsen imminent!\n",
cfb->fb.fix.id);
cyberpro_unmap_smem(cfb);
cyberpro_unmap_mmio(cfb);
cyberpro_free_fb_info(cfb);

/*
* Ensure that the driver data is no longer
* valid.
*/
dev->driver_data = NULL;
if (cfb == int_cfb_info)
int_cfb_info = NULL;
}
}

So, umm, is there a consensus on what to do if someone currently expects
to be writing to memory that doesn't exist any more?  Leave the mappings
there?  Take them out and laugh as our users' machine suddenly oopses to a
halt? Pray? Laugh? Cry?

-David Thomas Eger ([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/

mm and Oops

[Andries . Brouwer]

After sending util-linux out, I booted a kernel that had kdev_t
a pointer type, to see whether that still works.
And all (minus md/lvm/nfs that didnt compile) was fine
except that kswapd produced an oops. Investigation shows
that it was caused by the combination of what  calls
"Ugly ugly ugly HACK" and what  judges with "yuk".

So, maybe we must remove one or both of these sore spots.
The second one is the use of a special constant B_FREE
as device value to indicate that the buffer is free.
I'll look at this tomorrow but perhaps someone knows:
must the constant B_FREE (used only in fs/buffer.c) be nonzero?
If so, then we probably need a bitfield to indicate "free".
Otherwise we can use 0 ("no device") as value.

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

Re: [PATCH] User chroot

[Paul Menage]

>
>You need to be root to do mknod. You need to do mknod to create /dev/zero.
>You need /dev/zero to get anywhere near the normal behaviour of the system.
>

Sure, but we're not necessarily looking for a system that behaves
normally in all aspects. The example given was that of a paranoid
network server that does all its initialisation in a normal environment,
and then does a chroot to its data directory. Or alternatively, forks
after accepting a connection, and the child does a chroot. No need to be
able to exec other programs, etc. Such a daemon is certainly possible,
as I've written one myself. But it had to be started by root, rather
than by a normal user.

I'm not claiming that the user chroot patch is necessarily useful enough
to be included in the standard kernel - merely that it does have some
real-world uses.

Paul


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Configure.help CONFIG_PPC

[Cort Dougan]

I like the assurances that the PowerPC is a "capable" processor.  Perhaps
even adequate.  Perhaps we should note that Dave has yet to take me up on
my challenge to the sparc to sissy-slap the PowerPC...

} +++ /tmp/Configure.help   Tue Jun 26 10:36:21 2001
} @@ -171,7 +171,7 @@
}  Power PC processor
}  CONFIG_PPC
}The PowerPC is a very capable 32-bit RISC processor from Motorola,
} -  the successor the their venerable 68000 series.  It powers recent
} +  the successor to their venerable 68000 series.  It powers recent
}Macintoshes and also a widely-used series of single-board computers
}from Motorola.  The Linux PowerPC port has a home page at
}.
} 
} Gr{oetje,eeting}s,
} 
}   Geert
} 
} --
} Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
} 
} In personal conversations with technical people, I call myself a hacker. But
} when I'm talking to journalists I just say "programmer" or something like that.
}   -- Linus Torvalds
} 
} -
} To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
} the body of a message 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: Microsoft and Xenix.

[Steve Underwood]

Rob Landley wrote:
> 
> On Monday 25 June 2001 11:13, you wrote:
> 
> > 1937 claude shannon A Symbolic Analysis of Relay and Switching Circuits,"
> >
> > 1948 claude shannon A mathematical theory of information.
> >
> > without those you're kind in trouble on the computing front...
> 
> Yeah, I know I've bumped into that name (and probably taken notes) somewhere.
>  Hmmm...  Might be from "Where wizards stay up late", or might have been an
> article linked from slashdot...  (I don't THINK it was mentioned in
> "Hackers"...  Rodents, where was the reference...  Crystal fire?  That's
> mostly hardware.  Accidental Empries?  Doesn't sound right...  Can't have
> been "Fire in the valley" because I haven't read that yet, it's still sitting
> on the bookshelf.  Not soul of a new machine, that's post-digital Equipment
> Corporation...)
> 
> I THINK that's in the set of notes that's on the box that's not hooked up
> right now...  (Shortage of monitors at home.)
> 
> This was the dude who decided to apply a binary and boolean approach to
> electronic computation, right?  I KNOW I've read some stuff about him... late
> last year?
> 
> Now I remember.  Slashdot linked to his obituary:

Shannon was one of the clearest thinkers of the 20th century, and yet
his name is hardly known outside his own field. Within his field he is
respected at the level of, say, Newton. It was a real loss to mankind
when he died a few months back.

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

Re: [PATCH] User chroot

[Alexander Viro]

On Tue, 26 Jun 2001, Paul Menage wrote:

> But only root can set this up, since you currently have to be root in
> order to chroot(). The (only) advantage of the user chroot() patch would
> be that users would be able to do the same thing without root
> intervention.

You need to be root to do mknod. You need to do mknod to create /dev/zero.
You need /dev/zero to get anywhere near the normal behaviour of the system.

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

Re: 2.4.6 Pre 5 Not see all available RAM

[Wayne Whitney]

In mailing-lists.linux-kernel, you wrote:

> I have discovered that while running 2.4.6pre5, the kernel does not
> see all available RAM - I have 1GB and the kernel only sees ~899MB.

The 1GB memory option in the kernel configuration is really the 896MB
memory option.  So for more than 896MB, you need to select the 4GB
memory option, which really is 4GB.

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: Microsoft and Xenix.

[Rob Landley]

On Tuesday 26 June 2001 12:15, Daniel Phillips wrote:
> On Tuesday 26 June 2001 17:15, Joel Jaeggli wrote:
> > On Tue, 26 Jun 2001, Jocelyn Mayer wrote:
> >
> > you get DR-DOS = Digital Research DOS, then you get Novell DOS, then
> > you get Caldera OpenDOS, currently opendos is owned by lineo
>
> Yes, and the source actually was open for a short time when Caldera had it,
> then it snapped back shut like a clam.  I wanted to use DrDos for an
> industrial project because of less paranoid licensing than MS-Dos, but
> after being rebuffed in no uncertain terms when I offered to fix a bug I
> ran away shuddering and jumped on the Linux cluetrain.
>
> > > I think I remember that DR-DOS was the name that Caldera
> > > gave to the Digital Research OS, previously known as GEMDOS,

After Ransom Love fell for Microsoft's "Stop using the GPL so we can fork 
your stuff and make a proprietary version" campaign...  That pretty much 
buried the needle on my "cluelessness" meter.  As far as I'm concerned, the 
only thing Caldera could still do that would suprise me would be to come to 
their senses.

Rob

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] User chroot

[Paul Menage]

>Paul Menage wrote:
>> This could be regarded as the wrong way to solve such a problem, but
>> this kind of bug seems to be occurring often enough on BugTraq that it
>> might be useful if you don't have the resources to do a full security
>> audit on your program (or if the source to some of your libraries
>> isn't available).
>
>Why do this in the kernel when it's available in userspace?
>
>http://freshmeat.net/projects/rj/
>

But only root can set this up, since you currently have to be root in
order to chroot(). The (only) advantage of the user chroot() patch would
be that users would be able to do the same thing without root
intervention.

Paul

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Re: Microsoft and Xenix.

[Rob Landley]

On Tuesday 26 June 2001 08:57, Patrick O'Callaghan wrote:
> Ah, fame at last :-)

You seem to have been inexplicably excluded from "a quarter century of unix" 
by peter salus.  (You're not in the index, anyway.)  Haven't read "life with 
unix" yet...

> I'm not on the linux-kernel list but a friend forwarded me this message:
> > Subject: Re: Microsoft and Xenix.
> > Date: Mon, 25 Jun 2001 18:11:01 +0100 (BST)
> > From: <[EMAIL PROTECTED]>
> >
> > I first used  Unix on a PDP11/44 whilst studying for my Computer
> >  Engineering degree at Heriot-Watt University in Edinburgh.  I think
> >  they and Queen Margaret
> > College, London were the first folk running Unix version 6 outside
> >  Bell Labs.
>
> It was in fact a PDP-11/45. Unix 5th Edition was first installed by Peter
> De Souza around January 1975 (if anyone knows Peter's whereabouts please
> mail me; I know he emigrated to the US and I lost track of him). Anyway,
> the 11/45 had only 48kb of (core) memory, which was enough to boot the
> system and run the Shell but almost nothing else. We had to connect the
> machine to a neighbouring 11/20 with Unibus cable and a special bus switch
> box built in-house in order to do anything.

I'm a little fuzzy on how that would really improve things...  It still 
wouldn't have enough memory to run anything except the shell.  (Ummm...  You 
skipped running the shell and booted straight to your app as process 1?)

> This quickly improved when we
> purchased a 256kb semiconductor memory board from Plessey (the DEC guy
> couldn't believe all that memory would fit on only one 19-inch board :-).

Sounds cool.  Who's Plessey?  (What was DEC selling at about that time?  I 
take it they hadn't made the jump to IC dram yet?)

Had anybody actually HEARD of Intel at this time?  They seem to be a no-name 
fringe DRAM player until the 4004.  Their retroactive history makes it seem 
quite noble, but I'm still not sure who they actually sold their DRAM -TO-...

> It cost 3000 quid.

Okay, a quid's a pound?  (You are referring to the cost of the DRAM here?)  I 
have no idea what the exchange rate was back about then...

> We had 2 RK05 removable disks (2.5 Mb each!) and a paper
> tape reader. Note that we had no tape drive, and Unix came on a reel of
> tape, so we had to trudge around various places in the Edinburgh area doing
> media conversions on non-Unix machines. Oh how we laughed. We later bought
> an SMC 80Mb removable washing-machine style disk for I think about 15000
> pounds (for which we had to fight off the Control Engineering guys who
> wanted to buy a floating-point unit -- yes, the fp was emulated!).

How many different departments shared this box?  What kind of things were 
done on it?

> This system supported around 10 ASCII terminals via a DZ-11 serial-line
> multiplexor. Memory was so tight we couldn't run VI, but I wrote my PhD
> thesis on it (in NROFF) using George Coulouris' EM editor from Queen Mary
> College (not Queen Margaret). They were the first to run Unix in the UK
> along with us. I've never known who was really the first because of course
> there was no Internet, not even UUCP mail.

Ken Thompson would know, he sent out the tapes.

Peter Salus's book just says (page 70), "The United Kingdom, which had 
received Unix in 1973..."

Sigh...

> We may even have been the first
> in Europe for all I know, though I think Andy Tanenbaum was fairly close
> behind.

I thought Tanenbaum worked at Bell Labs?  (Did he just visit, or did he move 
to europe after leaving the BTL?)

> Anyway, I'll not rabbit on. Those were the days when men were men, real
> programmers wrote assembler, and we didn't need no steenking GUIs (mumbles
> into beer).

And I'm writing a book about it. :)

> > If anyone knows where Patrick O'Callaghan is now (ask
> >  him).
>
> I'm at Simón Bolívar University in Caracas, Venezuela. My home page is
> http://www.ldc.usb.ve/~poc.

And the mailing list we're discussing computing history on is:

http://lists.sourceforge.net/lists/listinfo/penguicon-comphist

(Yes, I am recruiting!  :)

> Cheers
>
> poc

Rob

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [OT] Re: When the FUD is all around (sniff).

[Rob Landley]

On Tuesday 26 June 2001 11:09, Jonathan Lundell wrote:

> >account of the speech didn't mention it. The Fehrenbachers give the
> >old-timers' recollections a D. The evidence, the scholars say,
> >"suggests that this is a case of reminiscence echoing folklore or
> >fiction."

I don't feel NEARLY so bad about the ongoing computer history thread being 
too far off-topic now. :)

Rob

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] User chroot

[Mohammad A. Haque]

Paul Menage wrote:
> This could be regarded as the wrong way to solve such a problem, but
> this kind of bug seems to be occurring often enough on BugTraq that it
> might be useful if you don't have the resources to do a full security
> audit on your program (or if the source to some of your libraries
> isn't available).

Why do this in the kernel when it's available in userspace?

http://freshmeat.net/projects/rj/

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [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: Client receives TCP packets but does not ACK

[Robert Kleemann]

SUMMARY:

The bad network behavior was due to shared irqs somehow screwing
things up.  This explained most but not all of the problems.

DETAILS:

Many people emailed me that they were experiencing similar problems.
Even though the cause of my problem is not kernel related, I'm hoping
my narrative and eventual solution will helps some folks.  I also
still think this behavior is really weird so those of you with an
abundance of brains and curiosity might want to take a guess at
explaining the behavior that I'm seeing.

When I last posted I had a reproducible test case which spewed a bunch
of packets from a server to a client.  The behavior is that the client
eventually stops ACKing and so the the connection stalls indefinitely.
I spent some time studying the kernel networking code and traced the
code path taken by a tcp packet:

linux/net/core/dev.c:netif_rx() // packet received by eth card
linux/net/ipv4/ip_input.c:ip_rcv()
linux/net/ipv4/ip_input.c:ip_rcv_finish()
linux/net/ipv4/tcp_ipv4.c:tcp_v4_recv()
linux/net/ipv4/tcp_ipv4.c:tcp_v4_do_rcv()
linux/net/ipv4/tcp_input.c:tcp_rcv_established() // packet placed in user queue

Each routine had 2 to 6 conditions that would result in a dropped
packet.  I added printk statements for each of these conditions in
hopes of detecting why the final packet is not acked.  I recompiled
the kernel, and reran the test.  The result was that the packet was
being droped in tcp_rcv_established() due to an invalid checksum.  I
then ran tcpdump to verify that the packets sent from the server were
the same packets that were received by the client.  It turned out that
one byte was being corrupted and it was always the same byte in the
stream that was corrupted.

This was very confusing because my previous logs show _no_ corruption
of the final packet.

Anyway, now it appeared to be a hardware related problem so I started
swapping ethernet cards to no effect.  I then look at the irqs (cat
/proc/interrupts) and noticed that the ethernet card in the client was
sharing an irq with the aic7xxx scsi adapter. The following url made
me think that this could be causing a problem:
http://www.scyld.com/expert/irq-conflict.html

The motherboard on the client is an old Intel PR440FX (dual 200mhz
PPro, onboard LAN, SCSI) and doesn't allow any kind of configuring of
the irqs so I ended up throwing another pci net card in the box just
to juggle the irqs enough so that one of the net cards was not sharing
an irq with the scsi card.  The bug no longer repros!  Neither the
reduced test case nor the original shows any problems.

My only remaining questions are:

1) Does this make sense?  Would a scsi card sharing an irq with a net
   card cause rare but highly reproducable corruption?  I was able to
   run http, telnet, ftp, mail, and games though this card with no
   problems.  It only failed on a specific set of data.  This is what
   initially led me to believe that the problem was not hardware
   related.

2) Now that two net cards are sharing an irq, have I just trading one
   subtle corruption bug for another?  Will some different data set
   cause the same type of corruption?  Is it safe to share irqs?

3) My old tcpdump logs (from several weeks ago) show _no_ corruption.
   I would have believed that I must have screwed up except that I
   still have the logs and the packets sent from the server compare
   exactly with those received by the client.  I can't seem to
   reproduce this behavior.

Robert.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] User chroot

[David Wagner]

It is not rocket science to populate a chroot environment with enough
files to make many interesting applications work.  Don't expect a general
solution---chroot is not a silver bullet---but it is useful.  (Note also
that whether you can populate a chroot environment sufficiently is roughly
independent of whether you called chroot(2) with root privileges or not.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] User chroot

[David Wagner]

Paul Menage  wrote:
>It could potentially be useful for a network daemon (e.g. a simplified
>anonymous FTP server) that wanted to be absolutely sure that neither it
>nor any of its libraries were being tricked into following a bogus
>symlink, or a "/../" in a passed filename. After initialisation, the
>daemon could chroot() into its data directory, and safely only serve
>the set of files within that directory hierarchy.
>
>This could be regarded as the wrong way to solve such a problem, but
>this kind of bug seems to be occurring often enough on BugTraq that it
>might be useful if you don't have the resources to do a full security
>audit on your program (or if the source to some of your libraries
>isn't available).

Or even where you have done a full security audit on your program, it is
often still useful to have backup protection.  Belt and suspenders[*],
and all that.

[*] For those who are not familiar with the reference: If you really,
really want to avoid getting caught with your pants down, you might
wear both a belt and a pair of suspenders.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] swapin flush cache bug

[NIIBE Yutaka]

Hello Marcelo, 

This is follow-up to the mail in February.  You may perhaps forget the
context, it's the bug of MM about cache flushing for swapped-in-pages.
I see this bug on SuperH port (SH-4).

I think that we have this issue on the machine whose flush_dcache_page()
is defined.  In current code, the cache aren't flushed for 
the asynchronously-swapped-in pages which is cached in swap cache.
This is the problem.

Marcelo Tosatti writes:
 > Yet another thing (1) on end_buffer_io_async() to handle a case which is
 > only true for a specific user of it. Since the other special case handling
 > is for swap IO too, I think a separate IO end operation for swap would be
 > interesting.
 > 
 > (1) The current one is SetPageDecrAfter handling.

How about this?  I've updated MM bugzilla already.

2001-06-26  NIIBE Yutaka  <[EMAIL PROTECTED]>

* include/linux/mm.h (PG_flush_after, PageFlushAfter,
SetPageFlushAfter, PageTestandClearFlushAfter): New bit.
* mm/page_io.c (rw_swap_page_base): Set flush-after bit.
* fs/buffer.c (end_buffer_io_async): Implement flush-ing
with PG_flush_after.

* mm/memory.c (do_swap_page): Remove flush-ing the page.

diff -ruNp --exclude=CVS --exclude=.cvsignore v2.4.6-pre5/fs/buffer.c 
kernel/fs/buffer.c
--- v2.4.6-pre5/fs/buffer.c Mon Jun 25 18:48:07 2001
+++ kernel/fs/buffer.c  Tue Jun 26 15:11:17 2001
@@ -831,6 +831,9 @@ static void end_buffer_io_async(struct b
if (PageTestandClearDecrAfter(page))
atomic_dec(_async_pages);
 
+   if (PageTestandClearFlushAfter(page))
+   flush_dcache_page(page);
+
UnlockPage(page);
 
return;
diff -ruNp --exclude=CVS --exclude=.cvsignore v2.4.6-pre5/include/linux/mm.h 
kernel/include/linux/mm.h
--- v2.4.6-pre5/include/linux/mm.h  Mon Jun 25 18:48:09 2001
+++ kernel/include/linux/mm.h   Tue Jun 26 14:58:56 2001
@@ -282,6 +282,7 @@ typedef struct page {
 #define PG_inactive_clean  11
 #define PG_highmem 12
 #define PG_checked 13  /* kill me in 2.5.. */
+#define PG_flush_after 14
/* bits 21-29 unused */
 #define PG_arch_1  30
 #define PG_reserved31
@@ -364,6 +365,10 @@ static inline void set_page_dirty(struct
 
 #define SetPageReserved(page)  set_bit(PG_reserved, &(page)->flags)
 #define ClearPageReserved(page)clear_bit(PG_reserved, &(page)->flags)
+
+#define PageFlushAfter(page)   test_bit(PG_flush_after, &(page)->flags)
+#define SetPageFlushAfter(page)set_bit(PG_flush_after, &(page)->flags)
+#define PageTestandClearFlushAfter(page)   test_and_clear_bit(PG_flush_after, 
+&(page)->flags)
 
 /*
  * Error return values for the *_nopage functions
diff -ruNp --exclude=CVS --exclude=.cvsignore v2.4.6-pre5/mm/memory.c 
kernel/mm/memory.c
--- v2.4.6-pre5/mm/memory.c Mon Jun 25 18:48:10 2001
+++ kernel/mm/memory.c  Tue Jun 26 14:48:15 2001
@@ -1109,8 +1109,6 @@ static int do_swap_page(struct mm_struct
return -1;
}
wait_on_page(page);
-   flush_page_to_ram(page);
-   flush_icache_page(vma, page);
}
 
/*
diff -ruNp --exclude=CVS --exclude=.cvsignore v2.4.6-pre5/mm/page_io.c 
kernel/mm/page_io.c
--- v2.4.6-pre5/mm/page_io.cMon Apr 30 16:15:32 2001
+++ kernel/mm/page_io.c Tue Jun 26 15:01:00 2001
@@ -50,6 +50,7 @@ static int rw_swap_page_base(int rw, swp
 
if (rw == READ) {
ClearPageUptodate(page);
+   SetPageFlushAfter(page);
kstat.pswpin++;
} else
kstat.pswpout++;
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] User chroot

[David Wagner]

H. Peter Anvin wrote:
>By author:Jorgen Cederlof <[EMAIL PROTECTED]>
>> If we only allow user chroots for processes that have never been
>> chrooted before, and if the suid/sgid bits won't have any effect under
>> the new root, it should be perfectly safe to allow any user to chroot.
>
>Safe, perhaps, but also completely useless: there is no way the user
>can set up a functional environment inside the chroot.

Why is it useless?  It sounds useful to me, on first glance.  If I want
to run a user-level network daemon I don't trust (for instance, fingerd),
isolating it in a chroot area sounds pretty nice: If there is a buffer
overrun in the daemon, you can get some protection [*] against the rest
of your system being trashed.  Am I missing something obvious?

[*] Yes, I know chroot is not sufficient on its own to completely
protect against this, but it is a useful part of the puzzle, and
there are other things we can do to deal with the remaining holes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] User chroot

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Paul Menage <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> It could potentially be useful for a network daemon (e.g. a simplified
> anonymous FTP server) that wanted to be absolutely sure that neither it
> nor any of its libraries were being tricked into following a bogus
> symlink, or a "/../" in a passed filename. After initialisation, the
> daemon could chroot() into its data directory, and safely only serve
> the set of files within that directory hierarchy.
> 
> This could be regarded as the wrong way to solve such a problem, but
> this kind of bug seems to be occurring often enough on BugTraq that it
> might be useful if you don't have the resources to do a full security
> audit on your program (or if the source to some of your libraries
> isn't available).
> 

If the source to some of your libraries aren't available, you have no
clue when/why/if they will try to access other files in the
filesystem.  Since libc WILL do this, a random chroot() breaks libc
(unless you can set up a proper root environment), and therefore
pretty much anything else is pointless.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: VM Requirement Document - v0.0

[Mike Castle]

On Tue, Jun 26, 2001 at 08:43:33PM -0400, Dan Maas wrote:
> (hrm, maybe I could hack up my own manual read-ahead/drop-behind with mmap()
> and memory locking...)

Just to argue portability for a moment (portability on the expected
results, that is, vs APIs).

Would this technique work across a variety of OSes?

Would the recent caching difficulties of the 2.4.* series have handled such
a technique in a reasonable fashion?

mrc
-- 
 Mike Castle  [EMAIL PROTECTED]  www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: VM Requirement Document - v0.0

[Dan Maas]

> Windows NT/2000 has flags that can be for each CreateFile operation
> ("open" in Unix terms), for instance
>
>   FILE_ATTRIBUTE_TEMPORARY
>   FILE_FLAG_WRITE_THROUGH
>   FILE_FLAG_NO_BUFFERING
>   FILE_FLAG_RANDOM_ACCESS
>   FILE_FLAG_SEQUENTIAL_SCAN
>

There is a BSD-originated convention for this - madvise().

If you look in the Linux VM code there is a bit of explicit code for
different madvise access patterns, but I'm not sure if it's 100% supported.

Drop-behind would be really, really nice to have for my multimedia
applications. I routinely deal with very large video files (several times
larger than my RAM). When I sequentially read though such files a bit at a
time, I do NOT want the old pages sitting there in RAM while all of my other
running programs are rudely paged out...

(hrm, maybe I could hack up my own manual read-ahead/drop-behind with mmap()
and memory locking...)

Regards,
Dan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] User chroot

[Paul Menage]

In article <[EMAIL PROTECTED]>,
you write:
>
>Safe, perhaps, but also completely useless: there is no way the user
>can set up a functional environment inside the chroot.  In other
>words, it's all pain, no gain.
>

It could potentially be useful for a network daemon (e.g. a simplified
anonymous FTP server) that wanted to be absolutely sure that neither it
nor any of its libraries were being tricked into following a bogus
symlink, or a "/../" in a passed filename. After initialisation, the
daemon could chroot() into its data directory, and safely only serve
the set of files within that directory hierarchy.

This could be regarded as the wrong way to solve such a problem, but
this kind of bug seems to be occurring often enough on BugTraq that it
might be useful if you don't have the resources to do a full security
audit on your program (or if the source to some of your libraries
isn't available).

Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: When the FUD is all around (sniff).

[Schilling, Richard]

Interesting. .  .

What country is that? What is it about the computer that won't allow it to
run things other than Windows - or is the TV just mistaken (I suspect so)?


Richard Schilling

-Original Message-
From: lk [mailto:[EMAIL PROTECTED]]

> Speaking of:
> A TV station in my country said that the most pirated products belong to
> M$ because computers cannot work wothout the GUI M$ windows provides.

> In my country about 75% percent of M$ software are illegal copies :)



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.6 Pre 5 Not see all available RAM

[Stuart Haas]

Hi All,

I have discovered that while running 2.4.6pre5, the kernel does not see all
available RAM - I have 1GB and the kernel only sees ~899MB.  The stock
Redhat 7.1 kernel sees the full 1024MB.  Adding mem=1024M on boot does not
help either.

I'm running an IBM x340, dual 1GHz cpu.

Have I missed something?

Stuart



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: VM Requirement Document - v0.0

[Mike Castle]

On Tue, Jun 26, 2001 at 03:48:09PM -0700, Jeffrey W. Baker wrote:
> These flags would be really handy.  We already have the raw device for
> sequential reading of e.g. CDROM and DVD devices.

Not going to help 99% of the applications out there.

mrc
-- 
 Mike Castle  [EMAIL PROTECTED]  www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] Checks in ext2_new_block()

[Alexander Viro]

Ted, could you comment on sanity checks in ext2_new_block()?
a)
if (tmp == le32_to_cpu(gdp->bg_block_bitmap) ||
tmp == le32_to_cpu(gdp->bg_inode_bitmap) ||
in_range (tmp, le32_to_cpu(gdp->bg_inode_table),
  sb->u.ext2_sb.s_itb_per_group))
ext2_error (sb, "ext2_new_block",
"Allocating block in system zone - "
"block = %u", tmp);

will go ahead and return the block. Looks like we can do better than that
if we mark it in use (we do that anyway), decremnt relevant free blocks
counters (global and cylinder group one) and goto repeat;

b) we don't do similar checks for blocks we grab in preallocation loop.
And ext2_alloc_block() doesn't do such checks either.

c)
if (ext2_set_bit (j, bh->b_data)) {
ext2_warning (sb, "ext2_new_block",
  "bit already set for block %d", j);
DQUOT_FREE_BLOCK(sb, inode, 1);
goto repeat;
}
is of the "if memory got corrupted during the last dozens of cycles" variety -
we had seen that bit 0 several lines before and we couldn't even block during
that interval (not that it mattered much, since all modifications of these
bitmaps are under lock_super() anyway).

d)
if (j >= le32_to_cpu(es->s_blocks_count)) {
ext2_error (sb, "ext2_new_block",
"block(%d) >= blocks count(%d) - "
"block_group = %d, es == %p ",j,
le32_to_cpu(es->s_blocks_count), i, es);
goto out;
}
is a bit too late _and_ we don't do anything similar for preallocated blocks.

The question being: which of these checks deserve to stay ((c) doesn't, IMO)
and which deserve to be extended to preallocation? If we do them for
main path, we ought to be at least consistent...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: EXT2 Filesystem permissions (bug)?

[Guest section DW]

"H. Peter Anvin" wrote:

:: It's neither a bug nor undocumented.

Kenneth Johansson wrote:

: Interesting but I wonder how much this helps someone that not already know
: what it is. Should not the ls manual also contain something that explains

In fact the best info is on the stat page:

...
   The set GID bit (S_ISGID) has several special uses: For  a
   directory  it  indicates  that BSD semantics is to be used
   for that directory:  files  created  there  inherit  their
   group ID from the directory, not from the effective gid of
   the creating process, and directories created  there  will
   also  get  the  S_ISGID bit set.  For a file that does not
   have the group execution bit (S_IXGRP) set,  it  indicates
   mandatory file/record locking.

   The  `sticky'  bit  (S_ISVTX)  on a directory means that a
   file in that directory can be renamed or deleted  only  by
   the  owner of the file, by the owner of the directory, and
   by root.
...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Ext2-devel] Re: [UPDATE] Directory index for ext2

[Theodore Tso]

On Tue, Jun 26, 2001 at 12:25:32AM +0200, Daniel Phillips wrote:
> > This is only true without the COMPAT_DIR_INDEX flag.  Since e2fsck _needs_
> > to know about every filesystem feature, it will (correctly) refuse to touch
> > such a system for now.  You could "tune2fs -O ^FEATURE_C4 /dev/hdX" to
> > turn of the COMPAT_DIR_INDEX flag and let e2fsck go to town.  That will
> > break all of the directory indexes, I believe.
> 
> This is what he wants, a workaround so he can fsck.  However, the above 
> command (on version 1.2-WIP) just gives me:
> 
>Invalid filesystem option set: ^FEATURE_C4
> 
> Maybe he should just edit the source so it doesn't set the superblock flag 
> for now.

I haven't had a chance to analyze the directory index format to see if
an-dirindexing-ignorant e2fsck could do any damage to the index.  It's
probably the case as long as the filesystem isn't corrupted, simply
modifying e2fsck to ignore the compatibility flag won't hurt.  But
it's certainly not something I would recommend for any kind of
production operation.

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

[OT] util-linux-2.11g

[Andries . Brouwer]

Just released: util-linux-2.11g

* MCONFIG & configure: fix for gcc 3.0
  Note that nfsmount_xdr.c may give warnings with gcc 3.0, essentially
  because of defines in  that use things like ntohl(*buf++)
  where ntohl(x) is a macro with several occurrences of x.
* blockdev: support for the get/set blocksize ioctls
  [not yet in the 2.4.5 kernel]
* fdisk: added Linux/PA-RISC type (Matt Taggart)
* mount: minor fix (Andrey J. Melnikoff)
* mount: added some ext3 stuff (Andrew Morton)
* mount: added heuristics for reiserfs (Andrew Morton)
* mount.8: added ext3 and reiserfs docs (Andrew Morton)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] User chroot

[H. Peter Anvin]

Followup to:  <20010627014534.B2654@ondska>
By author:Jorgen Cederlof <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> Have you ever wondered why normal users are not allowed to chroot?
> 
> I have. The reasons I can figure out are:
> 
> * Changing root makes it trivial to trick suid/sgid binaries to do
>   nasty things.
> 
> * If root calls chroot and changes uid, he expects that the process
>   can not escape to the old root by calling chroot again.
> 
> If we only allow user chroots for processes that have never been
> chrooted before, and if the suid/sgid bits won't have any effect under
> the new root, it should be perfectly safe to allow any user to chroot.
> 

Safe, perhaps, but also completely useless: there is no way the user
can set up a functional environment inside the chroot.  In other
words, it's all pain, no gain.

-hpa
-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Maintainers master list?

[Marc Brekoo]

On Tue, 26 Jun 2001, Robert Love wrote:
> me.  I took issue with the MAINTAINERS file when Eric brought it up
> originally.  However, I don't think drastic measures need to be taken.
> I have seen a lot of ideas, including Meta-data in the kernel source.
>
> What I think we need is the simple solution: find a maintainer for the
> file, cleanup the current cruft and misinformation, and then actively
> work to keep the file current.  I am willing to be this maintainer.
>
> I am not a major "maintainer" in the kernel, but I have and do
> contribute.  Thus I think this is a good task for me.  I am willing and
> wanting to do this.  Comments?

I've been waiting for an opportunity like this to join in, so I'd be very
happy to help you with this.

(This would be my first contribution to linux, please be gentle :-)

Regards,

Marc Brekoo


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] User chroot

[Jorgen Cederlof]

Hi,

Have you ever wondered why normal users are not allowed to chroot?

I have. The reasons I can figure out are:

* Changing root makes it trivial to trick suid/sgid binaries to do
  nasty things.

* If root calls chroot and changes uid, he expects that the process
  can not escape to the old root by calling chroot again.

If we only allow user chroots for processes that have never been
chrooted before, and if the suid/sgid bits won't have any effect under
the new root, it should be perfectly safe to allow any user to chroot.

Example:

user:~$ /usr/sbin/traceroute 127.1
traceroute to 127.1 (127.0.0.1), 30 hops max, 38 byte packets
 1  localhost (127.0.0.1)  6.658 ms  0.764 ms  0.613 ms
user:~$ /usr/sbin/chroot /
user:/$ /usr/sbin/traceroute 127.1
traceroute: icmp socket: Operation not permitted
user:/$ /usr/sbin/chroot /
/usr/sbin/chroot: cannot change root directory to /: Operation not permitted
user:/$ 

Is there any reason why this could not be the default behavior for the
official kernel?

 Jörgen


diff -urN -X dontdiff linux-2.4.6-pre5-vanilla/CREDITS linux-2.4.6-pre5-devel/CREDITS
--- linux-2.4.6-pre5-vanilla/CREDITSSat Jun 23 02:00:54 2001
+++ linux-2.4.6-pre5-devel/CREDITS  Sat Jun 23 02:04:31 2001
@@ -497,6 +497,13 @@
 S: Fremont, California 94539
 S: USA
 
+N: Jörgen Cederlöf
+E: [EMAIL PROTECTED]
+D: User capabilities, user chroot
+S: Rydsvägen 258 A.36
+S: 584 34 Linköping
+S: Sweden
+
 N: Gordon Chaffee
 E: [EMAIL PROTECTED]
 W: http://bmrc.berkeley.edu/people/chaffee/
diff -urN -X dontdiff linux-2.4.6-pre5-vanilla/fs/exec.c 
linux-2.4.6-pre5-devel/fs/exec.c
--- linux-2.4.6-pre5-vanilla/fs/exec.c  Thu Apr 26 23:11:29 2001
+++ linux-2.4.6-pre5-devel/fs/exec.cSat Jun 23 02:04:31 2001
@@ -617,7 +617,7 @@
 
if(!IS_NOSUID(inode)) {
/* Set-uid? */
-   if (mode & S_ISUID)
+   if (mode & S_ISUID && capable(CAP_EXECSUID))
bprm->e_uid = inode->i_uid;
 
/* Set-gid? */
@@ -626,14 +626,15 @@
 * is a candidate for mandatory locking, not a setgid
 * executable.
 */
-   if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP))
+   if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)
+   && capable(CAP_EXECSGID))
bprm->e_gid = inode->i_gid;
}
 
/* We don't have VFS support for capabilities yet */
-   cap_clear(bprm->cap_inheritable);
+   cap_clear_set_user(bprm->cap_inheritable);
cap_clear(bprm->cap_permitted);
-   cap_clear(bprm->cap_effective);
+   cap_clear_set_user(bprm->cap_effective);
 
/*  To support inheritance of root-permissions and suid-root
  *  executables under compatibility mode, we raise all three
diff -urN -X dontdiff linux-2.4.6-pre5-vanilla/fs/open.c 
linux-2.4.6-pre5-devel/fs/open.c
--- linux-2.4.6-pre5-vanilla/fs/open.c  Fri Feb  9 20:29:44 2001
+++ linux-2.4.6-pre5-devel/fs/open.cSat Jun 23 02:04:32 2001
@@ -421,9 +421,22 @@
goto dput_and_out;
 
error = -EPERM;
-   if (!capable(CAP_SYS_CHROOT))
+   if (!capable(CAP_SYS_CHROOT) && !capable(CAP_USER_CHROOT))
goto dput_and_out;
 
+   if (!capable(CAP_SYS_CHROOT)) {
+   cap_lower(current->cap_effective,   CAP_EXECSUID);
+   cap_lower(current->cap_permitted,   CAP_EXECSUID);
+   cap_lower(current->cap_inheritable, CAP_EXECSUID);
+   cap_lower(current->cap_effective,   CAP_EXECSGID);
+   cap_lower(current->cap_permitted,   CAP_EXECSGID);
+   cap_lower(current->cap_inheritable, CAP_EXECSGID);
+   }
+
+   cap_lower(current->cap_effective,   CAP_USER_CHROOT);
+   cap_lower(current->cap_permitted,   CAP_USER_CHROOT);
+   cap_lower(current->cap_inheritable, CAP_USER_CHROOT);
+   
set_fs_root(current->fs, nd.mnt, nd.dentry);
set_fs_altroot();
error = 0;
diff -urN -X dontdiff linux-2.4.6-pre5-vanilla/include/linux/capability.h 
linux-2.4.6-pre5-devel/include/linux/capability.h
--- linux-2.4.6-pre5-vanilla/include/linux/capability.h Sat May 26 03:01:28 2001
+++ linux-2.4.6-pre5-devel/include/linux/capability.h   Sat Jun 23 02:04:32 2001
@@ -3,7 +3,7 @@
  *
  * Andrew G. Morgan <[EMAIL PROTECTED]>
  * Alexander Kjeldaas <[EMAIL PROTECTED]>
- * with help from Aleph1, Roland Buresund and Andrew Main.
+ * with help from Aleph1, Roland Buresund, Andrew Main and Jörgen Cederlöf.
  *
  * See here for the libcap library ("POSIX draft" compliance):
  *
@@ -277,6 +277,36 @@
 
 #define CAP_LEASE28
 
+
+/**
+ ** Capabilities used by normal user processes
+ **
+ ** They are handled somewhat different from other capabilities -
+ ** they are not cleared unless you drop them by hand, and using them
+ ** doesn't set PF_SUPERPRIV.
+ **/
+
+/* Allow the suid bit on executables to have effect */
+
+#define 

Re: EXT2 Filesystem permissions (bug)?

[Albert D. Cahalan]

Kenneth Johansson writes:

> Do linux even support the sticky bit (t) I can't see a reason
> to use it, why would I want the file to be stored in the swap ?? 

It is not currently supported. Swapping out executables would
be very nice when using an NFS or CD-ROM filesystem, because
swap space is much faster.

> Also I think S (setuid but no execute bit) have something to
> do with file locking but I'am not shure exactly how it works. 

Yeah, if you mount with mandatory locking enabled it does stuff.
It's a UNIX feature.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Regrading signal/sigaction.

[siva kumar]

Hi,

Is it possible to pass any local variable as an
argument in the signal handler function.Basically I
want to print the value of the local variable in the
signal handler function.

In the below program I want to print the value of a in
the timeout function(siganl handler), whenever the
Alaram signal send.


Your comment are welcomed.

My prototype code is:

#include
#include
void timeout(int signo,int a)
{
printf ("timeout");
printf("the value is %d and %d",signo,a);
}
 
main()
{
int a =5;
struct sigaction act,oact;
act.sa_handler = timeout;
sigemptyset(_mask);
act.sa_flags = 0;
sigaction(SIGALRM, , );
 
alarm(10);
sleep(10);
 
}

Thanks,
siva.s


__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.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: VM Requirement Document - v0.0

[Jeffrey W. Baker]

On Wed, 27 Jun 2001, Stefan Hoffmeister wrote:

> : On Tue, 26 Jun 2001 18:42:56 -0300 (BRST), Rik van Riel wrote:
>
> >On Tue, 26 Jun 2001, John Stoffel wrote:
> >
> >> Or that we're doing big sequential reads of file(s) which are
> >> larger than memory, in which case expanding the cache size buys
> >> us nothing, and can actually hurt us alot.
> >
> >That's a big "OR".  I think we should have an algorithm to
> >see which of these two is the case, otherwise we're just
> >making the wrong decision half of the time.
>
> Windows NT/2000 has flags that can be for each CreateFile operation
> ("open" in Unix terms), for instance
>
>   FILE_ATTRIBUTE_TEMPORARY
>
>   FILE_FLAG_WRITE_THROUGH
>   FILE_FLAG_NO_BUFFERING
>   FILE_FLAG_RANDOM_ACCESS
>   FILE_FLAG_SEQUENTIAL_SCAN
>
> If Linux does not have mechanism that would allow the signalling of
> specific use case, it might be helpful to implement such a hinting system?

These flags would be really handy.  We already have the raw device for
sequential reading of e.g. CDROM and DVD devices.

-jwb

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: When the FUD is all around (sniff).

[lk]

Speaking of:
A TV station in my country said that the most pirated products belong to
M$ because computers cannot work wothout the GUI M$ windows provides.

In my country about 75% percent of M$ software are illegal copies :)






> > I suppose they received some pression from M$, but if people read of a FUD
> > from a M$ employed, then they can guess what is going on, if it is a
> > newspaper usually telling facts in a correct way...
>
> It is common for newspaper staff to be corrupt, same with magazine people.
> Sometimes because people generally believe in a cause and are not impartial
> (which I've seen both pro and anti Linux btw) and sometimes because advertising
> revenue is a good thing.
>
> > The situation is going to be sad
>
> There is a saying in he UK 'You can fool all of the people some of the time,
> you can fool some of the people all the time, but you cannot fool all of the
> people all of the time'. You only have to look at the incredibly dim view
> technical people take of most printed reviews to see that.
>
> Alan
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: EXT2 Filesystem permissions (bug)?

[Hua Zhong]

> Do linux even support the sticky bit (t) I can't see a reason to use it, why would I 
>want the file to be stored in the swap ?? 

For files I think it was used in days when there was no VM, so that you could 
hint the system to put frequently used executables always in memory (like vi, 
sh, etc).  After VM was invented, there is really no reason to use it.  I 
don't think newer OSes like Linux implemented this.
 
> Also I think S (setuid but no execute bit) have something to do with file locking 
>but I'am not shure exactly how it works. 

On some unix systems S means using mandatory locking (instead of advisory 
locking).  I am not sure about Linux though.

> "H. Peter Anvin" wrote:
> > 
> > Followup to:  <[EMAIL PROTECTED]>
> > By author:Shawn Starr <[EMAIL PROTECTED]>
> > In newsgroup: linux.dev.kernel
> > >
> > > Is this a bug or something thats undocumented somewhere?
> > >
> > > dT
> > > and
> > > drwSrwSrwT
> > >
> > > are these special bits? I'm not aware of +S and +T
> > >
> > 
> > It's neither a bug nor undocumented.
> > 
> > "info ls" would have told you the following:
> > 
> >  The permissions listed are similar to symbolic mode
> >  specifications
> >  (*note Symbolic Modes::.).  But `ls' combines multiple bits into
> >  the third character of each set of permissions as follows:
> > `s'
> >   If the setuid or setgid bit and the corresponding executable
> >   bit are both set.
> > 
> > `S'
> >   If the setuid or setgid bit is set but the corresponding
> >   executable bit is not set.
> > 
> > `t'
> >   If the sticky bit and the other-executable bit are both set.
> > 
> > `T'
> >   If the sticky bit is set but the other-executable bit is not
> >   set.
> > 
> > `x'
> >   If the executable bit is set and none of the above apply.
> > 
> > `-'
> >   Otherwise.
> > 
> > -hpa
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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/

Swap error message I've seen in 2.4.5-ac17

[tcm]

Yep, me again. I've been playing around with ac17 on my old 486 machine
for a few days (it seems strange that the 486 works fine while the K6
doesn't, but I digress) and I noticed today something that made my hair
stand on end:

Jun 26 16:17:27 debian kernel: VM: Bad swap entry 0033da00
Jun 26 16:17:27 debian kernel: Unused swap offset entry in swap_count
0033da00
Jun 26 16:17:27 debian kernel: Unused swap offset entry in swap_count
0033da00
Jun 26 16:38:16 debian -- MARK --
Jun 26 16:53:13 debian kernel: PPP BSD Compression module registered
Jun 26 16:53:14 debian kernel: PPP Deflate Compression module registered
Jun 26 16:53:24 debian kernel: VM: Bad swap entry 0033da00

Now I have been told by Rik Van Riel that this is a kernel bug - I
initially figured it was a bad disk, thanks to him I can breathe now...

Anyway, at the time the kernel did these messages I was just stopping
playing quake on my K6-III (486 handles packets to/from the modem) and
was reloading the compression modules, changing the mtu of my modem's 
interface to 1500 from 576, and starting fetchmail. And about one
minute later I decided to simply disconnect.

I can't seem to find a way to reproduce this problem all the time like I
can with the freezing bug, but I will reply to this thread if I see it
again and/or can repeatedly reproduce 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: User space zero copy HOWTO?

[Camm Maguire]

Greetings, and thanks for this.  If I recall, there is some facility
for this in the tulip cards too, no?  Can one get any benefit with
100Mbps, or is the copy too fast anyway?  Is the source code for Tux
available somewhere?  This is probably the best bet.  It seems as
though the source for X15 is not available.  Any pointers
appreciated.  I'm investigating implementing something like this for
the lam MPI libs.

Take care,

"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:

> > Greetings!  Is there any faq/sample code somewhere showing how to get
> > zero copy tcp/ip with kernel 2.4, and what special hardware if any is
> > required?  Any information most appreciated.  Kindly cc me directly.
> 
> The hardware must do scatter-gather and IP checksuming.
> 
> The Alteon-based gigabit cards do this well. They are fully
> programmable, and even have a developer's kit that can be used
> to implement non-IP message passing protocols.
> 
> 
> 
> 

-- 
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Finding out the name behind a /dev/dsp device

[james rich]

On Tue, 26 Jun 2001, Ilya Konstantinov wrote:

> How can I find out the module name which handles a /dev/dsp* device
> and/or the full name of the Sound Card I'd be addressing by it?

If you use ALSA this is very simple.  See:

http://www.alsa-project.org

I feel that ALSA provides a superior audio driver.  I understand that the
it will become the default kernel driver.

James Rich
[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: VM Requirement Document - v0.0

[Stefan Hoffmeister]

: On Tue, 26 Jun 2001 18:42:56 -0300 (BRST), Rik van Riel wrote:

>On Tue, 26 Jun 2001, John Stoffel wrote:
>
>> Or that we're doing big sequential reads of file(s) which are
>> larger than memory, in which case expanding the cache size buys
>> us nothing, and can actually hurt us alot.
>
>That's a big "OR".  I think we should have an algorithm to
>see which of these two is the case, otherwise we're just
>making the wrong decision half of the time.

Windows NT/2000 has flags that can be for each CreateFile operation
("open" in Unix terms), for instance

  FILE_ATTRIBUTE_TEMPORARY

  FILE_FLAG_WRITE_THROUGH
  FILE_FLAG_NO_BUFFERING
  FILE_FLAG_RANDOM_ACCESS
  FILE_FLAG_SEQUENTIAL_SCAN

If Linux does not have mechanism that would allow the signalling of
specific use case, it might be helpful to implement such a hinting system?

Disclaimer: I am clueless about what the kernel provides at this time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Tracking down semaphore usage/leak

[Ken Brownfield]

Urgh, learn something new everyday (ipcs, ipcrm).  My apologies; apropos
didn't catch it on my boxes. :-(
-- 
Ken.
[EMAIL PROTECTED]

On Tue, Jun 26, 2001 at 02:09:16PM -0700, Ken Brownfield wrote:
| With RedHat's new Samba 2.0.10 RPM (the one to patch the latest 
| vulnerability) they seem to have sniffed enough glue to start using SysV 
| IPC semaphores which apparently leak until SEM??? are reached.  semget() 
| is returning "No space left on device", and disk/inodes/memory are all 
| fine.
| 
| Anyway, could someone give me a very quick rundown of the options for 
| tracking/force-freeing semaphores, or how to determine from proc, if 
| possible, what the current semaphore allocation status is?  Or did RH 
| slay a machine I really don't want to reboot?  I've restarted all 
| semaphore-using processes to no avail, but even so the SEM??? limits are 
| far above the normal needs of this machine.
| 
| Thanks much.  Searched the archives/Google/FAQ/semaphore docs; sorry if 
| it's been covered.  I'll summarize if folks want to hit me on or off the 
| list.
| --
| Ken.
| [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: EXT2 Filesystem permissions (bug)?

[Kenneth Johansson]

Interesting but I wonder how much this helps someone that not already know what it is. 
Should not the ls manual also contain something that explains the meaning instead of 
just the mapping from bits to symbol.

Do linux even support the sticky bit (t) I can't see a reason to use it, why would I 
want the file to be stored in the swap ?? 

Also I think S (setuid but no execute bit) have something to do with file locking but 
I'am not shure exactly how it works. 

"H. Peter Anvin" wrote:
> 
> Followup to:  <[EMAIL PROTECTED]>
> By author:Shawn Starr <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > Is this a bug or something thats undocumented somewhere?
> >
> > dT
> > and
> > drwSrwSrwT
> >
> > are these special bits? I'm not aware of +S and +T
> >
> 
> It's neither a bug nor undocumented.
> 
> "info ls" would have told you the following:
> 
>  The permissions listed are similar to symbolic mode
>  specifications
>  (*note Symbolic Modes::.).  But `ls' combines multiple bits into
>  the third character of each set of permissions as follows:
> `s'
>   If the setuid or setgid bit and the corresponding executable
>   bit are both set.
> 
> `S'
>   If the setuid or setgid bit is set but the corresponding
>   executable bit is not set.
> 
> `t'
>   If the sticky bit and the other-executable bit are both set.
> 
> `T'
>   If the sticky bit is set but the other-executable bit is not
>   set.
> 
> `x'
>   If the executable bit is set and none of the above apply.
> 
> `-'
>   Otherwise.
> 
> -hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: failed kernel 2.4.2 build after applying the patch ac28

[MEHTA,HIREN (A-SanJose,ex1)]

>On 26 Jun 2001 15:35:09 -0600, MEHTA,HIREN (A-SanJose,ex1) wrote:
>> I tried to build the 2.4.2 kernel after applying patch ac28
>> (patch-2.4.2-ac28) and it failed :-((
>> 
>> When it failed it gave the following message :
>> 
>> *** Install db development libraries
>> 
>> I thought kernel build should be independent of any userland libraries.


>i think this is because aicasm (the assembler for the aha7xxx scsi
>firmware) uses db1 to build itself.  are you compiling aha7xxx support
>into the kernel?

Yes, I am trying to compile aic7xxx support into the kernel.

>upgrade to the newest kernel (2.4.5-ac18) and rebuilding the firmware is
>optional, so you won't need the berekely db libraries.

Do you know from where can I get the berkeley db libraries ? Currently I do 
not want to upgrade my kernel. If you can suggest some changes to makefiles/
config files which will skip the steps to build the firmware, that would
also be great.

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

Does select (for write) work on PACKET_SOCKETs ?

[Ben Greear]

It does not seem to work for me like I want it to.  Basically,
it seems that it always takes the entire timeout (50-80 ms in my
case), but at least the socket descriptor is SET when select returns.  I want
it to return as soon as the socket is writable, which at low (56kbps)
speed on a 100bt NIC should be immediate, or certainly less than 50ms.

I'm using kernel 2.4.6-pre3 with RH 7.1.

Here is a snippet of code that does the socket creation (I am binding in this case.):

int createPacketSocket(const char* dev_name, int ether_type, int dev_idx, int 
should_bind) {
   LF_TRC_IN;
   VLOG << "dev_name -:" << dev_name << ":- dev_idx: " << dev_idx 
<< " type (decimal): " << ether_type << endl;

   int s = socket(PF_PACKET, SOCK_RAW, htons(ether_type));
   int r; //retval

   if (s < 0) {
  cerr << "ERROR: socket:  " << strerror(errno) << endl;
  VLOG << "ERROR: socket:  " << strerror(errno) << endl;
  return s;
   }

   if (should_bind) {
  struct sockaddr_ll myaddr;

  memset(, '\0', sizeof(myaddr));
  myaddr.sll_family = AF_PACKET;
  myaddr.sll_protocol = htons(ether_type);
  myaddr.sll_ifindex = dev_idx;
  //strcpy(myaddr.sa_data, dev_name);
  
  r = bind(s, (struct sockaddr*)(), sizeof(myaddr));
  if (r < 0) {
 cerr << "ERROR: bind:  " << strerror(errno) << endl;
 VLOG << "ERROR: bind:  " << strerror(errno) << endl;
 return r;
  }
   }

   nonblock(s);
   return s;
}


Any ideas?

Thanks,
Ben

-- 
Ben Greear <[EMAIL PROTECTED]>  <[EMAIL PROTECTED]>
President of Candela Technologies Inc  http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com http://scry.wanfear.com/~greear
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: VM Requirement Document - v0.0

[Jason McMullan]

On Tue, Jun 26, 2001 at 06:21:21PM -0300, Rik van Riel wrote:
> > * If we're getting low cache hit rates, don't flush
> >   processes to swap.
> > * If we're getting good cache hit rates, flush old, idle
> >   processes to swap.
> 
> ... but I fail to see this one. If we get a low cache hit
> rate, couldn't that just mean we allocated too little memory
> for the cache ?

Hmmm. I didn't take that into consideration. But at the
same time, shouldn't a VM be able to determine that its cache
strategy is causing _more_ (absolute) misses by increasing it 
cache size? The percentage of misses may go down, but total 
device I/O may stay the same.

So let's see... I'll rephrase that 'Motiviation' as:

* Minimize the total medium/slow I/Os that occur over a 
  sliding window of time. 

Is that a more general case?
 
> Also, how would we translate all these requirements into
> VM strategies ?

First, I would like to translate them into measurements.
Once we know how to measure these criteria, its possible to
formalize the feedback mechanism/accounting that a VM should
be aware of.

In the end, I would like a VM to have some idea of
how well its performing, and be able to attempt various
well-known strategies based upon its own performance.

-- 
Jason McMullan, Senior Linux Consultant
Linuxcare, Inc. 412.432.6457 tel, 412.656.3519 cell
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Putting open source to work.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: VM Requirement Document - v0.0

[Rik van Riel]

On Tue, 26 Jun 2001, John Stoffel wrote:

> >> * If we're getting low cache hit rates, don't flush
> >> processes to swap.
> >> * If we're getting good cache hit rates, flush old, idle
> >> processes to swap.
>
> Rik> ... but I fail to see this one. If we get a low cache hit rate,
> Rik> couldn't that just mean we allocated too little memory for the
> Rik> cache ?
>
> Or that we're doing big sequential reads of file(s) which are
> larger than memory, in which case expanding the cache size buys
> us nothing, and can actually hurt us alot.

That's a big "OR".  I think we should have an algorithm to
see which of these two is the case, otherwise we're just
making the wrong decision half of the time.

Also, in many systems we'll be doing IO on _multiple_ files
at the same time, so I guess this will have to be a file-by-file
decision.

> I personally don't feel that the cache should be allowed to grow over
> 50% of the system's memory at all, we've got so much in the cache at
> that point, that we're probably not hitting it all that much.

Remember that disk cache includes stuff like mmap()ed
executables and swap-backed user memory. Do you really
want to limit those too ?


regards,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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: failed kernel 2.4.2 build after applying the patch ac28

[Robert Love]

On 26 Jun 2001 15:35:09 -0600, MEHTA,HIREN (A-SanJose,ex1) wrote:
> I tried to build the 2.4.2 kernel after applying patch ac28
> (patch-2.4.2-ac28) and it failed :-((
> 
> When it failed it gave the following message :
> 
> *** Install db development libraries
> 
> I thought kernel build should be independent of any userland libraries.


i think this is because aicasm (the assembler for the aha7xxx scsi
firmware) uses db1 to build itself.  are you compiling aha7xxx support
into the kernel?

upgrade to the newest kernel (2.4.5-ac18) and rebuilding the firmware is
optional, so you won't need the berekely db libraries.

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

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

failed kernel 2.4.2 build after applying the patch ac28

[MEHTA,HIREN (A-SanJose,ex1)]

Hi All,

I tried to build the 2.4.2 kernel after applying patch ac28
(patch-2.4.2-ac28) and it failed :-((

When it failed it gave the following message :

*** Install db development libraries

I thought kernel build should be independent of any userland libraries.

Any thoughts ?

TIA
-hiren
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: VM Requirement Document - v0.0

[John Stoffel]

>> * If we're getting low cache hit rates, don't flush
>> processes to swap.
>> * If we're getting good cache hit rates, flush old, idle
>> processes to swap.

Rik> ... but I fail to see this one. If we get a low cache hit rate,
Rik> couldn't that just mean we allocated too little memory for the
Rik> cache ?

Or that we're doing big sequential reads of file(s) which are larger
than memory, in which case expanding the cache size buys us nothing,
and can actually hurt us alot.  

I personally don't feel that the cache should be allowed to grow over
50% of the system's memory at all, we've got so much in the cache at
that point, that we're probably not hitting it all that much.

This is why the discussion on the other cache scanning algorithm
(2Q+?) was so interesting, since it looked to handle both the LRU
vs. FIFO tradeoffs very nicely.  

Rik> I am very much interested in continuing this discussion...

Me too, even if I can just contribute comments and not much code.  

John
   John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
 [EMAIL PROTECTED] - http://www.lucent.com - 978-952-7548
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-fbdev-devel] Re: [PATCH] fbgen & multiple RGBA

[Romain Dolbeau]

Romain Dolbeau wrote:

> If on your console you do a 'fbset -depth 16 -rgba 5,6,5,0' followed by
> a 'fbset -depth 16 -rgba 5,5,5,1' [1], any driver using fbdev will end
 
That should have been 'fbgen', sorry for the momentary lapse of reason
and the waste of bandwith.

> up with a crazy colormap because it hasn't been reinstalled after the
> RGBA change.

-- 
DOLBEAU Romain   | The Gods made Heavy Metal
ENS Cachan / Ker Lann| and it's never gonna die
Thesard IRISA / CAPS |   -- Manowar
[EMAIL PROTECTED]| in 'The Gods made Heavy Metal'
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Microsoft and Xenix.

[Michael Meissner]

On Tue, Jun 26, 2001 at 11:16:27AM -0400, Rob Landley wrote:
> On Monday 25 June 2001 15:23, Kai Henningsen wrote:
> 
> > The AS/400 is still going strong. It's a virtual machine based on a
> > relational database (among other things), mostly programmed in COBOL (I
> > think the C compiler has sizeof(void*) == 16 or something like that, so
> > you can put a database position in that pointer), it doesn't know the
> > difference between disk and memory (memory is *really* only a cache), and
> > these days it's usually running on PowerPC hardware.
> >
> > ISTR there's a gcc port for the AS/400. Oh, and it does have normal BSD
> > Sockets. These days, it's often sold as a web server.
> >
> > Main customer base seems to be medium large businesses and banks.
> 
> The AS400 seems to be based out of Austin.  We hear a lot about it around 
> here...

Ummm, the AS/400 was based out of Rochester, Minnesota at least initially.  It
was the follow to System/3 -> System/36 -> System/38, and customers originally
programmed it in RPG-III and Cobol.  Now that AS/400's are based on special
PowerPC's, the home may have moved to Austin, which is the PowerPC/AIX center.
The AS/400 line was intended to be the mid-range system, between the mainframes
(360 -> 370 -> 3080 -> 3900 -> ???) and the PCs.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [comphist] Re: Microsoft and Xenix.

[Michael Meissner]

On Tue, Jun 26, 2001 at 10:44:53AM -0400, Rob Landley wrote:
> Okay, so they're 2.4 megabyte removable cartridges?  How big?  Are they tapes 
> or disk packs?  (I.E. can you run off of them or are they just storage?)  I 
> know lots of early copies of unix were sent out from Bell Labs on RK05 
> cartidges signed "love, ken"...

IIRC, rk05 was a removable disk drive, 1 platter to the assembly, about the
size of a large pizza box.  They were the standard disk drives for small DEC
machines of the era.  My memories from 30+ years ago, say they were maybe 10
pounds each.  I would imagine you are confusing tapes with disks (ie, tk
instead of rk) in terms of the release media Bell Labs sent out (at least
I never saw a disk with the media, and I did have a job of trying to port the
V7 compiler to a V6 system).  It could be the very early customers got disks,
and the later ones got tapes.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED]   phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED]   fax:   +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: VM Requirement Document - v0.0

[Rik van Riel]

On Tue, 26 Jun 2001, Jason McMullan wrote:

>   If we take all the motivations from the above, and list
> them, we get:
>
>   * Don't write to the (slow,packeted) devices until
> you need to free up memory for processes.
>   * Never cache reads from immediate/fast devices.
>   * Keep packetized devices as continuously-idle as possible.
> Small chunks of idleness don't count. You want to have
> maximal stetches of idleness for the device.
>   * Keep running processes as fully in memory as possible.

I agree with your modification, and with the obvious 4
points above ...

>   * If we're getting low cache hit rates, don't flush
> processes to swap.
>   * If we're getting good cache hit rates, flush old, idle
> processes to swap.

... but I fail to see this one. If we get a low cache hit
rate, couldn't that just mean we allocated too little memory
for the cache ?

I am very much interested in continuing this discussion...

Also, how would we translate all these requirements into
VM strategies ?

regards,

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


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: [Linux-fbdev-devel] Re: [PATCH] fbgen & multiple RGBA

[Romain Dolbeau]

> This happens every time you VC switch.
[snip]
> But because of the way the current console system
> is designed the colormap will always be set on VC switches.

The fix wasn't intended for VC switch, but for any change of
fb_var_screeninfo parameter. Those can happen without VC switching,
that's exactly what 'fbset' is for.

If on your console you do a 'fbset -depth 16 -rgba 5,6,5,0' followed by
a 'fbset -depth 16 -rgba 5,5,5,1' [1], any driver using fbdev will end
up with a crazy colormap because it hasn't been reinstalled after the
RGBA change.

Hence the need for the fix.

[1] yes, in fbset, "-depth" really mean "-bpp" ...

-- 
DOLBEAU Romain   |
ENS Cachan / Ker Lann| l'histoire est entierement vraie, puisque
Thesard IRISA / CAPS | je l'ai imaginee d'un bout a l'autre
[EMAIL PROTECTED]|   -- Boris Vian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Duplicate IP ??

[Matti Aarnio]

On Tue, Jun 26, 2001 at 03:51:33PM -0400, Richard B. Johnson wrote:
> I just got a bunch of messages from vger.kernel.org, sent to
> [EMAIL PROTECTED], claiming a "local configuration error"
> and some kind of a loop.

Weird...   I don't recall any bounces..

Logs show *one* bounce from  chaos.analogic.com  just
about an hour ago, and it went to linux-kernel-owner ..

There are also 121 successfull deliveries in 12 hours
collected in the log.

> There is no configuration that has changed on that machine for
> at least two years although our firewall got updated last week
> to fix the ECN bug.
> 
> I checked with ns.uu.net to see if the machine address was still
> resolvable, it is.
> 
> I can `telnet vger.kernel.org 25`. That connectivity works.
> So I don't get any mail from vger.kernel.org.  What goes?

Where then those 121 messages went ?

The ECN connectivity problem is visible only when
connection originator (= vger) has the ECN bit on.

If incoming SYN doesn't have ECN bit on, reply to
SYN is sent without ECN.   That is why people can
reach VGER, but VGER might not be able to reach
people's MTAs.

> Dick Johnson

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

Tracking down semaphore usage/leak

[Ken Brownfield]

With RedHat's new Samba 2.0.10 RPM (the one to patch the latest 
vulnerability) they seem to have sniffed enough glue to start using SysV 
IPC semaphores which apparently leak until SEM??? are reached.  semget() 
is returning "No space left on device", and disk/inodes/memory are all 
fine.

Anyway, could someone give me a very quick rundown of the options for 
tracking/force-freeing semaphores, or how to determine from proc, if 
possible, what the current semaphore allocation status is?  Or did RH 
slay a machine I really don't want to reboot?  I've restarted all 
semaphore-using processes to no avail, but even so the SEM??? limits are 
far above the normal needs of this machine.

Thanks much.  Searched the archives/Google/FAQ/semaphore docs; sorry if 
it's been covered.  I'll summarize if folks want to hit me on or off the 
list.
--
Ken.
[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/

about get_zeroed_page() and page_address()

[Ho Chak Hung]

In the get_zeroed_page()function, address = page_address(page)
1)Does address point to a contiguous block of 4KB of physical memory? i.e.can I 
access the individual bytes by *address++?
2)How is page_address() function defined? I did a grep and found something like: 
#define page_address(page) ({ if (!(page)->virtual) BUG(); (page)->virtual; })? What's 
(page)->virtual?

Thanks
Any help would be greatly appreciated.

__
Get your own FREE, personal Netscape Webmail account today at 
http://webmail.netscape.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: [comphist] Re: Microsoft and Xenix.

[Alan Cox]

There seems to be a bug in the mail routing again. It may be related to the
recent problem with ditto copier history outbreaks on Linux S/390 and the
infamous 'pdp-11 memory subsystem' article routing bug that plagued 
comp.os.minix once.

In the meantime can people check that their mailer hasnt spontaneously added
linux-kernel to their history articles before posting them ?

Alan

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

Re: Making a module 2.4 compatible

[Jonathan Corbet]

> It would be nice to have it working under 2.4, so is there someplace
> that outlines some of the major things that would have changed so I can
> update the module accordingly?



Within a week or so, "Linux Device Drivers" second edition should hit the
shelves.  It will also hit the net, but that's going to take a little
longer.  If it doesn't answer all your questions, then we failed to achieve
what we set out to do.



jon

Jonathan Corbet
Executive editor, LWN.net
[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: [comphist] Re: Microsoft and Xenix.

[Jonathan Lundell]

At 10:44 AM -0400 2001-06-26, Rob Landley wrote:
>"A quarter century of unix" mentions RK05 cartridges several times, but never
>says much ABOUT them.
>
>Okay, so they're 2.4 megabyte removable cartridges?  How big?  Are they tapes
>or disk packs?  (I.E. can you run off of them or are they just storage?)  I
>know lots of early copies of unix were sent out from Bell Labs on RK05
>cartidges signed "love, ken"...

http://www.pdp8.net/rk05/rk05.shtml

>What was that big reel to reel tape they always show in movies, anyway?

The big-refrigerator-sized guys were generally attached to 
mainframes, IBM or otherwise. Here's a little info: 
http://www.digital-interact.co.uk/site/html/reference/media_9trk.html 
(but take it with a grain of salt; IBM surely didn't go to nine 
tracks because of ASCII!).
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Maintainers master list?

[Robert Love]

On 26 Jun 2001 16:03:05 -0300, Rik van Riel wrote:
> On Tue, 26 Jun 2001, Holzrichter, Bruce wrote:
> 
> > respect Eric, and all the developers work.  How about starting
> > with a simple MAINTAINERS file maintainer?  Someone to actively
> > follow project developers and contact info?
> 
> That's the best idea I've read so far.
> 
> Any takers?

me.  I took issue with the MAINTAINERS file when Eric brought it up
originally.  However, I don't think drastic measures need to be taken.
I have seen a lot of ideas, including Meta-data in the kernel source.

What I think we need is the simple solution: find a maintainer for the
file, cleanup the current cruft and misinformation, and then actively
work to keep the file current.  I am willing to be this maintainer.

I am not a major "maintainer" in the kernel, but I have and do
contribute.  Thus I think this is a good task for me.  I am willing and
wanting to do this.  Comments?

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] proc_file_read() (Was: Re: proc_file_read() question)

[Mike Galbraith]

On Tue, 26 Jun 2001, Martin Wilck wrote:

> Hi,
>
> > Shhh ;-)  Last time that hack was mentioned, someone wanted to _remove_
> > it.  It's a very nice little hack to have around, and IKD uses it.
>
> I am not saying it should be removed. But IMO it is a legitimate (if
> not the originally intended) use of "start" to serve as a pointer to
> a memory area allocated in the proc_read () function. This use is broken
> with this hack in its current form, because reading from such a file
> will fail depending on the (random) order of the page and start pointers.
>
> If I understand the "hack" right, legitimate offsets generated for it
> are always between 0 and PAGE_SIZE. Therefore the patch below would
> not break it, while overcoming the abovementioned problem, because
> legitimate page pointers will never be < PAGE_SIZE.

It's dead simple.  My variable length data often didn't quite fit into
the transport vehicle.. so I whacked the excess to avoid the fault.

-Mike

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

Re: [Linux-fbdev-devel] Re: [PATCH] fbgen & multiple RGBA

[James Simmons]

> For the color component, yes, but you can't use a memcmp
> on the 'fb_var_screeninfo', as some member of the struct
> are irrelevant to colormap switching (you don't want
> to reinstall the colormap if only the refresh rate changed,
> for instance).

But it does. If you look at the console code it always calls set_palette
which in turn calls fbcon_set_palette which in turn calls fb_set_cmap. 
This happens every time you VC switch. A few driver writers noticed this
and don't bother with calling fb_Set_var in con_switch but instead a few
pieces of the function. But because of the way the current console system
is designed the colormap will always be set on VC switches.

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

Patch(2.4.5): Fix PCMCIA ATA/IDE freeze (w/ PCI add-in cards)

[Gunther Mayer]

Hi,

this patch fixes the hard hang (no SYSRQ) on inserting
any PCMCIA ATA/IDE card (e.g. CompactFlash, Clik40 etc)
to a PCI-Cardbus bridge add-in card.

Thanks David for his valuable explanation about what happens:
ide-probe registers it's irq handler too late! After it
triggers the interrupt during the probe the (shared) irq
loops forever, effectively wedging the machine completely.

Regards, Gunther



--- linux245.orig/drivers/ide/ide-cs.c  Fri Feb  9 20:40:02 2001
+++ linux/drivers/ide/ide-cs.c  Tue Jun 26 21:22:19 2001
@@ -324,6 +324,9 @@
 if (link->io.NumPorts2)
release_region(link->io.BasePort2, link->io.NumPorts2);
 
+outb(0x02, ctl_base); // Set nIEN = disable device interrupts
+ // else it hangs on PCI-Cardbus add-in cards, wedging irq
+
 /* retry registration in case device is still spinning up */
 for (i = 0; i < 10; i++) {
hd = ide_register(io_base, ctl_base, link->irq.AssignedIRQ);
--- linux245.orig/drivers/ide/ide-probe.c   Sun Mar 18 18:25:02 2001
+++ linux/drivers/ide/ide-probe.c   Tue Jun 26 21:25:07 2001
@@ -685,6 +685,8 @@
 #else /* !CONFIG_IDEPCI_SHARE_IRQ */
int sa = (hwif->chipset == ide_pci) ? SA_INTERRUPT|SA_SHIRQ : 
SA_INTERRUPT;
 #endif /* CONFIG_IDEPCI_SHARE_IRQ */
+
+   outb(0x00, hwif->io_ports[IDE_CONTROL_OFFSET]); // clear nIEN == 
+enable irqs
if (ide_request_irq(hwif->irq, _intr, sa, hwif->name, hwgroup)) {
if (!match)
kfree(hwgroup);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [comphist] Re: Microsoft and Xenix.

[Rob Landley]

On Monday 25 June 2001 16:19, [EMAIL PROTECTED] wrote:
> Hi again,
>
>
>
> some old brain-cells got excited with the "good-ol-days" and other names
> have surfaced like "Superbrain","Sirius" and "Apricot".Sirius was Victor in
> the USA.  If you go done the so-called IBM compatible route then the nearly
> compatible  nightmares  will arise and haunt you, your lucky if the scars
> have faded!!

With the spelling cleaned up slightly, I just might want to quote that last 
sentence in my book.  Would you object?

I take it that superbrain, sirius/victor, and apricot were PC clones like the 
Tandy and Wang that were sort of but not really compatable?

> I learnt my computing on a PDP8/E with papertape punch/reader, RALF,
> Fortran II, then later 2.4Mb removable cartridges (RK05 I think).  toggling
> in the bootstrap improved your concentration. Much later you could
> get a single chip(?) version of this in a wee knee sized box.

"A quarter century of unix" mentions RK05 cartridges several times, but never 
says much ABOUT them.

Okay, so they're 2.4 megabyte removable cartridges?  How big?  Are they tapes 
or disk packs?  (I.E. can you run off of them or are they just storage?)  I 
know lots of early copies of unix were sent out from Bell Labs on RK05 
cartidges signed "love, ken"...

What was that big reel to reel tape they always show in movies, anyway?

I need a weekend just to collate stuff...

> One summer job was working on a PDP15 analog computer alongside an 11/20
> with DECTAPE, trying to compute missile firing angles. [A simple version of
> Pres Bush's starwars shield].

Considering that the Mark I was designed to compute tables of artillery 
firing angles during World War II...  It's a distinct trend, innit?  And the 
source of the game "artillery duel", of course...

> --
>
> Andrew Smith in Edinburgh,Scotland
>
>  On 25 Jun 2001, Kai Henningsen wrote:
> > [EMAIL PROTECTED] (Rob Landley)  wrote on 24.06.01 in 
<[EMAIL PROTECTED]>:
> > > Now if somebody here could just point me to a decent reference on A/UX
> > > - Apple's mid-80's version of Unix (for the early macintosh, I
> > > believe...)
> >
> > http://www.google.com/search?q=%22%2ba/ux%22
> >
> > Usually a good idea.
> >
> >
> >
> > Also, you probably want to look at RFC 2235.
> >
> > MfG Kai
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > in the body of a message to [EMAIL PROTECTED]
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
>
> ___
> Penguicon-comphist mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/penguicon-comphist
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Microsoft and Xenix.

[Rob Landley]

On Monday 25 June 2001 15:23, Kai Henningsen wrote:

> The AS/400 is still going strong. It's a virtual machine based on a
> relational database (among other things), mostly programmed in COBOL (I
> think the C compiler has sizeof(void*) == 16 or something like that, so
> you can put a database position in that pointer), it doesn't know the
> difference between disk and memory (memory is *really* only a cache), and
> these days it's usually running on PowerPC hardware.
>
> ISTR there's a gcc port for the AS/400. Oh, and it does have normal BSD
> Sockets. These days, it's often sold as a web server.
>
> Main customer base seems to be medium large businesses and banks.

The AS400 seems to be based out of Austin.  We hear a lot about it around 
here...

> > Lotus-Intel-Microsoft Expanded Memory Specification), and "DOSShell"
> > which conformed to the SAA graphical user interface guidelines.
>
> Nope, the text user interface guidelines, a related but not the same
> beast. That's where F1 == Help is from, by the way.

Same overall push.  I think the distinction there is a bit nit-picking to put 
in the book, but I'll have to look it up to make sure...

> In fact, the user interface part of SAA was (is?) called CUA. And many IBM
> text mode interfaces more or less follow it, including OS/400 (the os of
> the AS/400). Once upon a time, I had the specs for CUA.

When I worked at IBM I had to program for CUA.  Ouch.  Painful memories...

How did any of this related to the "Common Desktop Environment", by the way?

> > The PS/2 model 70/80 (desktop/tower versions of same thing) were IBM's
> > first 386 based PC boxes, which came with either DOS 3.3, DOS 4.0, OS/2
> > (1.0), or AIX.
>
> The first 386 PCs where not from IBM, by the way. Was it Compaq?

It was compaq.  The "Desqpro" or some such.  That was actually an important 
turning point, Compaq basically stuck a 32 bit processor in a machine that 
was otherwise designed for a 16 bit one.  It had a 16 bit ISA bus, 8 bit 30 
pin simms that had been paired off now needed to be used in groups of 4...  
It was a painful hack from a hardware perspective.

IBM was busy trying to upgrade the memory system and bus and stuff to be a 
better platform for the 386, but the waited to long and compaq just came out 
with "a quick hack now", and everybody else started copying compaq 
(especially when IBM's alternative was patented and thus not easily 
clonable...)

With the PS/2 IBM succeeded in preventing the clones from copying them.  
Their mistake was in thinking that this was a good thing.

> > AIX was NOT fully SAA/SNA compliant,
>
> AFAICT, nothing ever was fully SAA compliant, though some systems were
> more compliant than others.

Yeah, but AIX didn't even pretend to be.  And that sidelined it within IBM in 
the late 80's in a big way.  (Up until Gerster took over and overturned 
everything.)

> > Hmmm...  Notes on the history of shareware (pc-write/bob
> > wallace/quiicksoft, pc-file/pc-calc/jim button/buttonware, pc-talk/andrew
> > flugelman, apparently the chronological order is andrew-jim-bob, and bob
> > came up with the name "shareware" because "freeware" was a trademark of
> > Headlands Press, Inc...)
>
> That may be, but I believe the *concept* was invented in 1980 by Bill

The "concept" of freeware had been around as public domain software forever.  
The homebrew club thought that way naturally about micros, and the MIT 
hackers thought that way also.

If you're saying basham invented shareware...  Maybe.  I'll have to look into 
it.  I'm just tracing back the origin of the word...

> Basham, with the Apple ][ DOS replacement Diversi-DOS (which was the most
> popular of many versions to increase disk speed by about a factor of 5). I
> still remember discussions how copying this stuff was actually the right
> thing to do. Seems he's still in business as "Diversified Software
> Research", http://www.divtune.com/.

Adding link to link pile...

> > running AIX.  The engineers (in Austin) whent on for the second
> > generation Risc System 6000 (the RS/6000) with AIX version 3, launched
> > February 15 1990. The acronym "POWER" stands for Performance Optimized
> > WIth Enhanced Risc.
>
> The PowerPC was split off from the POWER architecture, and then the POWER
> stuff was turned into the high end above PowerPC (with system prices about
> a factor of ten higher as the lower bound).

Yeah, I have to research that bit still.  I know the vague bits (the 
IBM/apple/motorola hegemony to unseat Intel with risc, conceived before Intel 
came out with the Pentium, of course...)

> IBM developed a version of OS/2 2.0 for the PowerPC, but *never* marketed
> it - you could buy it if you knew the right number, but they never spent a
> single cent on advertizing - by the time it was done, IBM had given up on
> OS/2. Most OS/2 fans agreed that it was killed by IBM with extremely bad
> marketing.

My first job out of college was working at IBM in Boca Raton florida on the 
install 

VM Requirement Document - v0.0

[Jason McMullan]

Here's my first pass at a VM requirements document,
for the embedded, desktop, and server cases. At the end is 
a summary of general rules that should take care of all of 
these cases.

Bandwidth Descriptions:

immediate: RAM, on-chip cache, etc. 
fast:  Flash reads, ROMs, etc.
medium:Hard drives, CD-ROMs, 100Mb ethernet, etc.
slow:  Flash writes, floppy disks,  CD-WR burners
packeted:  Reads/write should be in as large a packet as possible

Embedded Case
-

Overview

  In the embedded case, the primary VM motiviation is to
use as _little_ caching of the filesystem for reads as
possible because (a) reads are very fast and (b) we don't
have any swap. However, we want to cache _writes_ as hard
as possible, because Flash is slow, and prone to wear.
  
Machine Description
--
RAM:4-64Mb   (reads: immediate, writes: immediate)
Flash:  4-128Mb  (reads: fast, writes: slow, packeted)
CDROM:  640-800Mb (reads: medium)
Swap:   0Mb

Motiviations

* Don't write to the (slow,packeted) devices until
  you need to free up memory for processes.
* Never cache reads from immediate/fast devices.

Desktop Case


Overview

  On the desktop, interactivity is king. We don't want to eat
lots of I/O bandwidth paging in and out, however we also want
to cache as much of the FS as possible, to speed compiles and
multiple operations over the same sets of files. 

  Balancing this is the notion of 'cache-hit-rates'. If our 
access patterns aren't hitting cache, but disk instead, don't 
swap out processes, just shrink the cache. Contrawise, if we
have good cache hit rates, swap out the idle tasks.

Machine Description
---
RAM:32Mb-1Gb  (reads: immediate, writes: immediate)
HD: 1Gb-100Gb (reads: medium, writes: medium)
CDROM:  640-800Mb (reads: medium)
DVD:1Gb-8Gb   (reads: medium)
Swap:   RAM size  (HD speeds)

Motivations
---
* If we're getting low cache hit rates, don't flush 
  processes to swap.
* If we're getting good cache hit rates, flush old, idle
  processes to swap.

Laptop Case
---

Overview

  Same as a desktop, except now you must treat the HDs as
packetized devices for power-saving.

Machine Description
---
RAM:32Mb-1Gb  (reads: immediate, writes: immediate)
HD: 1Gb-100Gb (reads: medium,packeted, writes: medium,packeted)
CDROM:  640-800Mb (reads: medium)
DVD:1Gb-8Gb   (reads: medium)
Swap:   RAM size  (HD speeds)

Motivations
---
* Keep packetized devices as continuously-idle as possible.
  Small chunks of idleness don't count. You want to have
  maximal stetches of idleness for the device.

Server Case
---

Overview

  Same as a desktop, except that interactivity be damned. You
want processes to _rarely_ have to wait for swap-ins, and 
you want as much read-ahead as possible. Idle tasks are pressed
firmly into cache to make room for running processes.

Machine Description
---
RAM:512Mb-64Gb (reads: immediate, writes: immediate)
HD: 10Gb-4Tb   (reads: medium, writes: medium)
Swap:   2*RAM size  (HD speeds)

Motivations
---
* Keep running processes as fully in memory as possible.

- SUMMARY --

If we take all the motivations from the above, and list them,
we get:

* Don't write to the (slow,packeted) devices until
  you need to free up memory for processes.
* Never cache reads from immediate/fast devices.
* If we're getting low cache hit rates, don't flush 
  processes to swap.
* If we're getting good cache hit rates, flush old, idle
  processes to swap.
* Keep packetized devices as continuously-idle as possible.
  Small chunks of idleness don't count. You want to have
  maximal stetches of idleness for the device.
* Keep running processes as fully in memory as possible.


Oddly enough, they don't seem to conflict. I'll continue to
work on these motivations, and try to determine testable methods
of 

Re: parport_pc tries to load parport_serial automatically

[Tim Waugh]

On Tue, Jun 26, 2001 at 06:59:11PM +0100, Philip Blundell wrote:

> This would be a bit bad, because it would require people to guess
> whether they might have a card that parport_serial can drive and/or
> try loading the module to see what happens.

Not necessarily.  The module has a PCI device table, so a user-space
utility can figure it out and adjust /etc/modules.conf accordingly.

> I guess one option would be for parport_pc to somehow "know" what cards are 
> really multi-I/O ones, and only load parport_serial when it will be able to 
> find something to do.  Doesn't seem all that appealing though.

Replace parport_pc's "knowledge" with parport_serial's PCI device
table and a user-space utility, and that's kind of what I had in
mind.

> If you do that then the code will effectively be there all the time,
> even when it's not needed.  You might as well just compile it in to
> parport_pc.  To be honest, there isn't all that much of it so maybe
> this wouldn't be such a bad idea.

Perhaps.

Tim.
*/

 PGP signature

Duplicate IP ??

[Richard B. Johnson]

I just got a bunch of messages from vger.kernel.org, sent to
[EMAIL PROTECTED], claiming a "local configuration error"
and some kind of a loop.

There is no configuration that has changed on that machine for
at least two years although our firewall got updated last week
to fix the ECN bug.

I checked with ns.uu.net to see if the machine address was still
resolvable, it is.

I can `telnet vger.kernel.org 25`. That connectivity works.
So I don't get any mail from vger.kernel.org.  What goes?

Dick Johnson


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AIC7xxx kernel driver; ATTN Mr. Justin T. Gibbs

[Brian Gerst]

Mihai Gata wrote:
> 
> Trying to use an AIC7890 SCSI controller with kernel 2.4.5 I have
> the problem reported into the attached log files.  Same problems with
> kernel 2.4.3.  Kernels below 2.4 doesn't even see it.  In MS Windows 95
> it works without any problems.  I used 3 variations of SCSI controllers
> built upon AIC7890, so I don't think all 3 are bad.  One was made for
> Compaq and two for Dell.  The AIC7890 is around since a while so that's
> the problem with Linux in corp. computing.  It's great but cannot use
> it.

Make certain that the SCSI bus is properly terminated.  Most of the SCSI
errors reported here are a result of bad termination.

--

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

Finding out the name behind a /dev/dsp device

[Ilya Konstantinov]

Dear LKML,

(Please CC your replies to me, since I'm not subscribed)

How can I find out the module name which handles a /dev/dsp* device
and/or the full name of the Sound Card I'd be addressing by it?

For /dev/mixer* devices, there's a SOUND_MIXER_INFO ioctl to retrieve
the Mixer chip name, but I couldn't find a similar call for /dev/dsp
devices. Parsing /etc/modules.conf doesn't seem correct, since a single
module can support multiple installed cards of the same type (thus
creating /dev/dsp entries for multiple cards), and since drivers can be
compiled statically.

This functionality is essential when building an application which
prompts the user to select a Sound Output Device from a list of
installed sound cards (avoiding exposing the user to a plain list of
dsp devices). Using the mixer chip's name isn't exactly friendly, and
still doesn't let you know which dsp device belongs to which mixer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: loop device broken in 2.4.6-pre5

[Anton Altaparmakov]

At 18:59 26/06/2001, Jari Ruusu wrote:
>[EMAIL PROTECTED] wrote:
> > From [EMAIL PROTECTED] Tue Jun 26 10:20:51 2001
> >
> > This patch fixes the problem. Please consider applying.
> >
> > --- linux-2.4.6-pre5/drivers/block/loop.cSat Jun 23 07:52:39 2001
> > +++ linux/drivers/block/loop.cTue Jun 26 09:21:47 2001
> > @@ -653,7 +653,7 @@
> >  bs = 0;
> >  if (blksize_size[MAJOR(lo_device)])
> >  bs = blksize_size[MAJOR(lo_device)][MINOR(lo_device)];
> > -if (!bs)
> > +if (!bs || S_ISREG(inode->i_mode))
> >  bs = BLOCK_SIZE;
> >
> >  set_blocksize(dev, bs);
> >
> > But why 1024? Next week your neighbour comes and has a file-backed
> > loop device with an odd number of 512-byte sectors.
> > If you want a guarantee, then I suppose one should pick 512.
> > (Or make the set blocksize ioctl also work on loop devices.)
>
>Because 1024 was the previous default. Keeping the same default that was
>used before offers least surprises to users and tools.

But also makes it not work for odd number of sectors which is much worse IMHO.

Also it is far more surprising to find that the last sector is lost 
silently than to have a difference in behaviour, incorrect behaviour needs 
to be corrected not kept for backwards compatibility till the end of time. 
And the sooner that happens, the better. Both people and utilities will get 
used to it. Due to that 1024, mkntfs has to mark the disk dirty because it 
can never be sure just how many sectors there really are and hence can't be 
sure whether the backup boot sector was written to the correct place or not...

Also, the loop device is currently not consistent with the rest of the kernel:

* kernel physical block device: get_nr_sectors_sys_call returns the real 
number of 512 byte sectors
* file mounted on loop device: sam sys_call returns the number of sectors & ~1.

This difference in behaviour causes a much bigger surprise than anything 
else if we are talking about surprises!

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/

[PATCH] CREDITS update

[Gareth Hughes]

My association with VA Linux Systems (and Precision Insight before that)
ended last month.  At this stage, it is unclear whether I will continue
working on the various open source 3D graphics projects (DRI, Mesa etc)
or not.  My work is being transitioned to the remaining members of the
PI group or, unfortunately, abandoned for the time being.

I hope to be able to continue working on the kernel, perhaps in slightly
different areas though :-)

-- Gareth

--- linux/CREDITS   Thu May 17 23:34:54 2001
+++ linux.gh/CREDITSWed Jun 27 04:06:50 2001
@@ -1256,12 +1256,11 @@
 S: USA
 
 N: Gareth Hughes
-E: [EMAIL PROTECTED]
-E: [EMAIL PROTECTED]
+E: [EMAIL PROTECTED]
 D: Pentium III FXSR, SSE support
-S: 11/187 West Street
-S: Crows Nest NSW 2065
-S: Australia
+D: Author/maintainer of most DRM drivers (especially ATI, MGA)
+D: Core DRM templates, general DRM and 3D-related hacking
+S: No fixed address
 
 N: Kenn Humborg
 E: [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/

multi-path IO in SCSI mid-layer

[Patrick Mansfield]

Hi -

I'm interested in multi-path IO in the linux scsi mid-layer.

Are there developers working on changes to the scsi layers/interfaces?
I've seen references about such work, but no details.

Anyone else interested in or working on multi-path IO in the mid-layer?

I've looked at the code as to what changes might be required, and did
a simple prototype to issue IO requests using multiple paths for one device -
configuring one device in with multiple paths using SCSI INQUIRY page 0x83,
and selecting a path (just round-robin) at scsi_submit_cmd() time.

But, a decent multi-path IO implementation requires significant changes
to the current linux scsi interfaces/structures - especially where no
functional interfaces exist, such as the direct references to Scsi_Device
host, and Scsi_Host host_queue.

-- 
Patrick Mansfield
[EMAIL PROTECTED]
[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: parport_pc tries to load parport_serial automatically

[Philip Blundell]

>- change parport_pc so that it doesn't request parport_serial at
>  init.  In this case, how will parport_serial get loaded at all?
>  Perhaps with some recommended /etc/modules.conf lines (perhaps
>  parport_lowlevel{1,2,3,...})?

This would be a bit bad, because it would require people to guess whether they 
might have a card that parport_serial can drive and/or try loading the module 
to see what happens.

I guess one option would be for parport_pc to somehow "know" what cards are 
really multi-I/O ones, and only load parport_serial when it will be able to 
find something to do.  Doesn't seem all that appealing though.

>- parport_serial could be made to initialise successfully even if it
>  doesn't see any devices that it can drive.

If you do that then the code will effectively be there all the time, even when 
it's not needed.  You might as well just compile it in to parport_pc.  To be 
honest, there isn't all that much of it so maybe this wouldn't be such a bad 
idea.

p.



 PGP signature

Re: loop device broken in 2.4.6-pre5

[Jari Ruusu]

[EMAIL PROTECTED] wrote:
> From [EMAIL PROTECTED] Tue Jun 26 10:20:51 2001
> 
> This patch fixes the problem. Please consider applying.
> 
> --- linux-2.4.6-pre5/drivers/block/loop.cSat Jun 23 07:52:39 2001
> +++ linux/drivers/block/loop.cTue Jun 26 09:21:47 2001
> @@ -653,7 +653,7 @@
>  bs = 0;
>  if (blksize_size[MAJOR(lo_device)])
>  bs = blksize_size[MAJOR(lo_device)][MINOR(lo_device)];
> -if (!bs)
> +if (!bs || S_ISREG(inode->i_mode))
>  bs = BLOCK_SIZE;
> 
>  set_blocksize(dev, bs);
> 
> But why 1024? Next week your neighbour comes and has a file-backed
> loop device with an odd number of 512-byte sectors.
> If you want a guarantee, then I suppose one should pick 512.
> (Or make the set blocksize ioctl also work on loop devices.)

Because 1024 was the previous default. Keeping the same default that was
used before offers least surprises to users and tools.

Regards,
Jari Ruusu <[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: Maintainers master list?

[Holzrichter, Bruce]

>What happens now when somebody takes over responsibility for a file
>or subsystem and the MAINTAINERS file doesn't get patched, either because
>that person forgets to send a MAINTAINERS update or Linus doesn't 
>happen to take the MAINTAINERS patch for a while?

>What happens when I look at a file and it's not obvious which
>subsystem it belongs to?  Sure, I can grovel through MAINTAINERS.  But
>how do I know which verbal description matches the function of the
>cryptically-commented or uncommented code I have in front of me?

>Distributed-information problems need distributed-information
>solutions.  Locality is your friend.  This crowd should know that
>if anybody should.

I'll throw this back out again, and if you all are not interested, drop it
if you want.  I am looking for places and points to help out where I see
issues come up several times, and this is one I have seen occasionally. I am
not advocating Eric's proposal for sweeping maintainer's changes, though I
respect Eric, and all the developers work.  How about starting with a simple
MAINTAINERS file maintainer?  Someone to actively follow project developers
and contact info?  Not a small or simple project, I understand, but maybe a
central point to send patches to Linus for the Maintainers file?  Just my
two cents, on a Tuesday  :o)

B.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] proc_file_read() (Was: Re: proc_file_read() question)

[Jonathan Lundell]

At 7:14 PM +0200 2001-06-26, Martin Wilck wrote:
>Hi,
>
>>  Shhh ;-)  Last time that hack was mentioned, someone wanted to _remove_
>>  it.  It's a very nice little hack to have around, and IKD uses it.
>
>I am not saying it should be removed. But IMO it is a legitimate (if
>not the originally intended) use of "start" to serve as a pointer to
>a memory area allocated in the proc_read () function. This use is broken
>with this hack in its current form, because reading from such a file
>will fail depending on the (random) order of the page and start pointers.
>
>If I understand the "hack" right, legitimate offsets generated for it
>are always between 0 and PAGE_SIZE. Therefore the patch below would
>not break it, while overcoming the abovementioned problem, because
>legitimate page pointers will never be < PAGE_SIZE.
>
>Please correct me if I'm wrong.

I use the hack myself, to implement a record-oriented file where the 
file position is a record number. I could probably live with 
PAGE_SIZE, but the current hack works fine with start bigger than 
that, and it's possible that someone counts on it.

But if you're allocating your own buffer, you'd probably be better 
off writing your own file ops, and not using the default 
proc_file_read() at all. At the very least you'd save a redundant 
__get_free_page/free_page pair.

>Cheers,
>Martin
>
>--
>Martin Wilck <[EMAIL PROTECTED]>
>FSC EP PS DS1, Paderborn  Tel. +49 5251 8 15113
>
>
>--- linux-2.4.5/fs/proc/generic.c  Mon Jun 25 13:46:26 2001
>+++ 2.4.5mw/fs/proc/generic.c  Tue Jun 26 20:42:22 2001
>@@ -104,14 +104,14 @@
>* return the bytes, and set `start' to the desired offset
>* as an unsigned int. - [EMAIL PROTECTED]
>*/
>-  n -= copy_to_user(buf, start < page ? page : start, n);
>+  n -= copy_to_user(buf, (unsigned long) start < 
>PAGE_SIZE ? page : start, n);
>   if (n == 0) {
>   if (retval == 0)
>   retval = -EFAULT;
>   break;
>   }
>
>-  *ppos += start < page ? (long)start : n; /* Move down 
>the file */
>+  *ppos += (unsigned long) start < PAGE_SIZE ? 
>(unsigned long) start : n; /* Move down the file */
>   nbytes -= n;
>   buf += n;
>   retval += n;

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

NETDEV WATCHDOG with 2.4.5

[kees]

Hi,

I tried 2.4.5 but after a couple of hours I lost all network connectivety.
The log shows:


Jun 25 19:34:17 schoen3 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jun 25 19:34:17 schoen3 kernel: eth0: Tx timed out, lost
interrupt? TSR=0x3, ISR=0Jun 25 19:34:19 schoen3 kernel: NETDEV
WATCHDOG: eth0: transmit timed out
Jun 25 19:34:19 schoen3 kernel: eth0: Tx timed out, lost
interrupt? TSR=0x3, ISR=0Jun 25 19:34:21 schoen3 kernel: NETDEV
WATCHDOG: eth0: transmit timed out
Jun 25 19:34:21 schoen3 kernel: eth0: Tx timed out, lost
interrupt? TSR=0x3, ISR=0/tmp/NETDEV


O well, back to 2.2.19 again. The network card is 

<6>ne2k-pci.c: v1.02 for Linux 2.2, 10/19/2000, D. Becker/P. Gortmaker,
http://www<4>ne2k-pci.c: PCI NE2000 clone 'Compex RL2000' at I/O 0xec00,
IRQ 19.
<4>eth0: Compex RL2000 found at 0xec00, IRQ 19, 00:80:48:CA:1D:4C.

regards 
Kees

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AIC7xxx kernel driver; ATTN Mr. Justin T. Gibbs

[Alan Cox]

> kernel 2.4.3.  Kernels below 2.4 doesn't even see it.  In MS Windows 95
> it works without any problems.  I used 3 variations of SCSI controllers
> built upon AIC7890, so I don't think all 3 are bad.  One was made for
> Compaq and two for Dell.  The AIC7890 is around since a while so that's
> the problem with Linux in corp. computing.  It's great but cannot use

One useful thing to try would be to try the old aic7xx driver (say N to 
aic7xxx and it will offer you the old one). Clearly if the aic7xxx_old driver
works then it is rather good information.

Except for an obscure bug under very high memory load I'm not aware of any 
outstanding bugs in the AIC7xxx driver, certainly not like you describe. There
is however always a first time for any bug 8)


Alan

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

AIC7xxx kernel driver; ATTN Mr. Justin T. Gibbs

[myemail]

Trying to use an AIC7890 SCSI controller with kernel 2.4.5 I have
the problem reported into the attached log files.  Same problems with
kernel 2.4.3.  Kernels below 2.4 doesn't even see it.  In MS Windows 95
it works without any problems.  I used 3 variations of SCSI controllers
built upon AIC7890, so I don't think all 3 are bad.  One was made for
Compaq and two for Dell.  The AIC7890 is around since a while so that's
the problem with Linux in corp. computing.  It's great but cannot use
it.
I Couldn't send this bug report directly to the author of the
driver, Justin T. Gibbs, because there is no e-mail address provided.
If you need further details please, let me know.  Same if you need a
sample controller for your tests.
If you fix the problem, please, let me know.  Maybe next time we may
be really able to use your OS.

Thank you very much and my best regards
-- 
Mihai Gata
[EMAIL PROTECTED]
IS Manager @ Mill-Rose Company
Member of The Institute of Electrical and Electronics Engineers
Member of The Association for Computing Machinery

Linux version 2.4.5-Mihai-1 (root@mr-test-1) (gcc version 2.96 2731 
(Linux-Mandrake 8.0 2.96-0.48mdk)) #4 Sun Jun 17 05:00:08 EST 2001
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 0400 (usable)
 BIOS-e820:  - 0001 (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c009fc00 for 4096 bytes.
On node 0 totalpages: 16384
zone(0): 4096 pages.
zone(1): 12288 pages.
zone(2): 0 pages.
mapped APIC to e000 (0000)
Kernel command line: 
Initializing CPU#0
Detected 451.030 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 897.84 BogoMIPS
Memory: 61796k/65536k available (1239k kernel code, 3352k reserved, 467k data, 240k 
init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2
CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line)
CPU: L2 Cache: 256K (32 bytes/line)
CPU: After vendor init, caps: 008021bf 808029bf  0002
CPU: After generic, caps: 008021bf 808029bf  0002
CPU: Common caps: 008021bf 808029bf  0002
CPU: AMD-K6(tm) 3D+ Processor stepping 01
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: AMD K6
PCI: PCI BIOS revision 2.10 entry at 0xfb480, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Disabled enhanced CPU to PCI posting #2
PCI: Using IRQ router VIA [1106/0586] at 00:07.0
Activating ISA DMA hang workarounds.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd v1.8
Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
Winbond chip at EFER=0x3f0 key=0x87 devid=fc devrev=21 oldid=8c
Winbond chip type 83877TF
SMSC Super-IO detection, now testing Ports 2F0, 370 ...
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 16
0x378: readIntrThreshold is 16
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: ECP port cfgA=0x10 cfgB=0x4b
0x378: ECP settings irq=7 dma=3
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,EPP,ECP]
parport0: irq 7 detected
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
pty: 256 Unix98 ptys configured
lp0: using parport0 (polling).
Serial driver version 5.05a (2001-03-20) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
block: queued sectors max/low 40978kB/13659kB, 128 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c586b (rev 47) IDE UDMA33 controller on pci00:07.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:pio, hdd:pio
hda: WDC AC36400L, ATA DISK drive
hdb: CD-540E, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 12594960 sectors (6449 MB) w/256KiB Cache, CHS=784/255/63, UDMA(33)
hdb: ATAPI 40X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12

Re: [PATCH] wrong disk index in /proc/stat

[Guest section DW]

On Tue, Jun 26, 2001 at 06:55:54PM +0200, Martin Wilck wrote:

> I (being new to kernel hacking) have yet to understand what needs
> to happen for patches to enter the main branches.

You mail them to Linus, with a cc to linux-kernel.
If he likes the patch it will be part of the next (pre)release.
Since your patch is short and corrects an actual bug,
your chances may be good.
If Linus starts 2.5 and Alan takes 2.4 the patch may be
relevant to both branches.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] HotPlug CPU patch against 2.4.5

[Greg KH]

On Sat, Jun 16, 2001 at 11:29:00PM +1000, Rusty Russell wrote:
> Hi all,
> 
>   http://sourceforge.net/projects/lhcs/
> 
>   Version 0.3 (untested) of the HotPlug CPU Patch is out, with
> ia64 and x86 support.

Here's a patch to the patch that adds /sbin/hotplug support (sorry, I
couldn't resist...)

It also fixes a '}' problem in fs/proc/proc_misc.c

thanks,

greg k-h


diff -Naur -X /home/greg/linux/dontdiff linux-2.4.5-hotplug/fs/proc/proc_misc.c 
linux-2.4.5-hotplug-greg/fs/proc/proc_misc.c
--- linux-2.4.5-hotplug/fs/proc/proc_misc.c Tue Jun 26 09:23:00 2001
+++ linux-2.4.5-hotplug-greg/fs/proc/proc_misc.cTue Jun 26 09:43:57 2001
@@ -295,6 +295,7 @@
jif - (  kstat.per_cpu_user[i] \
   + kstat.per_cpu_nice[i] \
   + kstat.per_cpu_system[i]));
+   }
len += sprintf(page + len,
"page %u %u\n"
 "swap %u %u\n"
diff -Naur -X /home/greg/linux/dontdiff linux-2.4.5-hotplug/kernel/cpu.c 
linux-2.4.5-hotplug-greg/kernel/cpu.c
--- linux-2.4.5-hotplug/kernel/cpu.cTue Jun 26 09:23:00 2001
+++ linux-2.4.5-hotplug-greg/kernel/cpu.c   Tue Jun 26 10:00:45 2001
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include /* for hotplug_path */
 #include 
 #include 
 
@@ -17,6 +18,38 @@
 
 static struct notifier_block *cpu_chain = NULL;
 
+#ifdef CONFIG_HOTPLUG
+/* Notify userspace when a cpu event occurs,
+ * by running '/sbin/hotplug cpu' with certain
+ * environment variables set.
+ */
+static int cpu_run_sbin_hotplug(unsigned int cpu, char *action)
+{
+   char *argv[3], *envp[5], cpu_str[12], action_str[32];
+   int i;
+
+   sprintf(cpu_str, "CPU=%d", cpu);
+   sprintf(action_str, "ACTION=%s", action);
+
+   i = 0;
+   argv[i++] = hotplug_path;
+   argv[i++] = "cpu";
+   argv[i] = 0;
+
+   i = 0;
+   /* minimal command environment */
+   envp [i++] = "HOME=/";
+   envp [i++] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin";
+   envp [i++] = cpu_str;
+   envp [i++] = action_str;
+   envp [i] = 0;
+
+   return call_usermodehelper(argv [0], argv, envp);
+}
+#else
+#define cpu_run_sbin_hotplug(cpu, action) ({ 0; })
+#endif
+
 /* Should really be in a header somewhere. */
 asmlinkage long sys_sched_get_priority_max(int policy);
 
@@ -120,6 +153,8 @@
/* Die, CPU, die! */
__cpu_die(cpu);
 
+   cpu_run_sbin_hotplug(cpu, "remove");
+
  out:
up();
return ret;
@@ -145,6 +180,8 @@
/* Friendly to make sure everyone knows it's up before we
   return */
__synchronize_kernel();
+
+   cpu_run_sbin_hotplug(cpu, "add");
 
  out:
up();

[PATCH] proc_file_read() (Was: Re: proc_file_read() question)

[Martin Wilck]

Hi,

> Shhh ;-)  Last time that hack was mentioned, someone wanted to _remove_
> it.  It's a very nice little hack to have around, and IKD uses it.

I am not saying it should be removed. But IMO it is a legitimate (if
not the originally intended) use of "start" to serve as a pointer to
a memory area allocated in the proc_read () function. This use is broken
with this hack in its current form, because reading from such a file
will fail depending on the (random) order of the page and start pointers.

If I understand the "hack" right, legitimate offsets generated for it
are always between 0 and PAGE_SIZE. Therefore the patch below would
not break it, while overcoming the abovementioned problem, because
legitimate page pointers will never be < PAGE_SIZE.

Please correct me if I'm wrong.

Cheers,
Martin

-- 
Martin Wilck <[EMAIL PROTECTED]>
FSC EP PS DS1, Paderborn  Tel. +49 5251 8 15113


--- linux-2.4.5/fs/proc/generic.c   Mon Jun 25 13:46:26 2001
+++ 2.4.5mw/fs/proc/generic.c   Tue Jun 26 20:42:22 2001
@@ -104,14 +104,14 @@
 * return the bytes, and set `start' to the desired offset
 * as an unsigned int. - [EMAIL PROTECTED]
 */
-   n -= copy_to_user(buf, start < page ? page : start, n);
+   n -= copy_to_user(buf, (unsigned long) start < PAGE_SIZE ? page : 
+start, n);
if (n == 0) {
if (retval == 0)
retval = -EFAULT;
break;
}

-   *ppos += start < page ? (long)start : n; /* Move down the file */
+   *ppos += (unsigned long) start < PAGE_SIZE ? (unsigned long) start : 
+n; /* Move down the file */
nbytes -= n;
buf += n;
retval += n;

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: When the FUD is all around (sniff).

[Kip Macy]

It's amazing what masquerades as news. It's also noteworthy that they
didn't bother to have a native speaker of English to edit the article:

An executive of another affiliated company said that he felt the passion
of IBM, which is determined to invest US$1 billion, this year alone, in
Linux. "IBM's passion really dragged us into this movement," he added.

He also said: "I can get a glimpse of the strong will of IBM, which has
recently regained its business strength, with an indication that 'there
shall be no free ride on Linux to be enhanced by IBM investing a huge
amount of money.'

On Tue, 26 Jun 2001, Jonathan Corbet wrote:

> The Repubblica article was bad enough, but if you want serious kernel FUD
> you should see this bit of delight on AsiaBizTech:
> 
>   http://www.nikkeibp.asiabiztech.com/wcs/leaf?CID=onair/asabt/fw/133671
> 
> For example:
> 
> Also, the casual attitude of Torvald [sic], which doesn't meet the
> needs of the market and minds of investors, is one of the reasons that
> investors have rapidly lost interest in Linux distributors and
> Linux-related businesses.
> 
> Cool.  Linus caused the end of the stock bubble...
> 
> jon
> 
> Jonathan Corbet
> Executive editor, LWN.net
> [EMAIL PROTECTED]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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

Re: [PATCH] wrong disk index in /proc/stat

[Martin Wilck]

> [go to ftp://ftp.XX.kernel.org/pub/linux/kernel/people/aeb/ or so
> and get patches 01*, 02*, ... and apply them successively to 2.4.6pre5.
> complain to [EMAIL PROTECTED] if anything is wrong]

I see, you're going for a much deeper patch. No objections whatsoever,
that's certainly a better solution, but I can't start testing it now (my
IA-64 machine has enough other problems to solve yet).

My patch was merely intended to correct the index for disks on the 1st
IDE controller, which is just plain wrong.

I (being new to kernel hacking) have yet to understand what needs
to happen for patches to enter the main branches.

Cheers,
Martin

-- 
Martin Wilck <[EMAIL PROTECTED]>
FSC EP PS DS1, Paderborn  Tel. +49 5251 8 15113



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Problems with 2.4.5ac1[78]

[Meino Christian Cramer]

From: Alan Cox <[EMAIL PROTECTED]>
Subject: Re: Problems with 2.4.5ac1[78]
Date: Tue, 26 Jun 2001 16:04:22 +0100 (BST)
Message-ID: <[EMAIL PROTECTED]>


Thanks a lot, Alan ! :o)

That's it! My build-script only did a make dep _clean_ bzImage modules
modules_install.
With a make distclean before all runs smooth...

  keep hacking on the right site of life ! :-)
  Meino  

> >  I tried to compile linux-2.4.5ac17 with processor type "Athlon"
> >  settings.
> > 
> >  Compilation/Install was successful. But boot produces dozens of
> >  "unresolved symbols" if trying to insmod any of the modules.
> > 
> >  Not one module was insmodded successfully.
> 
> Sounds like your build wasnt clean. Save your .config file and make distclean
> is sometimes needed when changing SMP or CPU types - yes its a bug in the
> config setup really
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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/