PATCH 2.4.0.10 v2: Update hotplug

[Jeff Garzik]

Attached is a revised "hotplug update" patch, against 2.4.0-test10. 
It's looking close to submit-able now.

General change description is the same as the first patch, which can be
found at
http://boudicca.tux.org/hypermail/linux-kernel/this-week/0785.html

Changes since the first patch:
* CONFIG_HOTPLUG and CONFIG_KMOD are now totally independent.  It was an
incestuous relationship anyway.
* exec_usermodehelper and call_usermodehelper are now unconditionally
present
* new file Documentation/networking/netdevices.txt describes
/sbin/network usage, and netdevice locking
* usb supports ACTION=$verb again, for compatibility with existing
implementation
* don't use magic numbers for 'insert' value in code, use TRUE/FALSE
* ditch the sbus slot number
* use '/' separate in PCI environment variables, for consistency with
USB
* eliminate EXPORT_SYMBOL(hotplug_path), modules don't need it
* constify netdev_event_name[] array

Now, time to track down that elusive thing called sleep... :)

-- 
Jeff Garzik | Dinner is ready when
Building 1024   | the smoke alarm goes off.
MandrakeSoft|   -/usr/games/fortune

Index: linux_2_4/Documentation/00-INDEX
diff -u linux_2_4/Documentation/00-INDEX:1.1.1.1 
linux_2_4/Documentation/00-INDEX:1.1.1.1.34.1
--- linux_2_4/Documentation/00-INDEX:1.1.1.1Sun Oct 22 12:47:49 2000
+++ linux_2_4/Documentation/00-INDEXWed Nov  1 22:50:19 2000
@@ -53,6 +53,8 @@
- notes about the floppy tape device driver
 hayes-esp.txt
- info on using the Hayes ESP serial driver.
+hotplug.txt
+   - kernel hotplug support
 i386/
- directory with info about Linux on the intel ix86 architecture.
 ide.txt
Index: linux_2_4/Documentation/hotplug.txt
diff -u /dev/null linux_2_4/Documentation/hotplug.txt:1.1.2.2
--- /dev/null   Fri Nov  3 23:12:53 2000
+++ linux_2_4/Documentation/hotplug.txt Fri Nov  3 23:12:03 2000
@@ -0,0 +1,92 @@
+
+Hot-Plug Devices, the Kernel, and You!
+
+
+Introduction
+
+Kernel version 2.4.0 and later includes native support for hotpluggable
+devices.  This text documents that support.
+
+FIXME: turn this random collection of notes into a real document
+
+Supported hot-plug buses:  CardBus (in the PCI subsystem), USB.
+
+Hot-plug code is conditionally included when CONFIG_HOTPLUG is enabled
+in 'make config'.  CONFIG_HOTPLUG now requires CONFIG_KMOD, so it is
+automatically defined when CONFIG_HOTPLUG is enabled.
+
+
+/sbin/hotplug
+=
+When hotpluggable hardware devices are added or removed, /sbin/hotplug
+is executed by the kernel.  The usage of /sbin/hotplug is as follows:
+
+   /sbin/hotplug [bus] [event]
+
+[bus] - The bus on which the hotpluggable event occurred.  Supported
+bus types are:
+
+   usb - USB
+   pci - PCI-compatible hot-plug:  CardBus
+
+[event] - Type of hot-plug event
+
+   add - Device insertion
+   del - Device removal
+
+In addition to the standard arguments passed to /sbin/hotplug as
+described above, each bus has its own set of environment variables
+which are passed to the program.
+
+hotplug pci env vars
+
+HOME=/
+   Hardcoded value.
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
+   Hardcoded value.
+PCI_CLASS=$CLASS
+   $CLASS - PCI device class, in hexidecimal
+PCI_ID=$VENDOR/$DEVICE
+   $VENDOR - 16-bit PCI device vendor id, in hexidecimal
+   $DEVICE - 16-bit PCI device id, in hexidecimal
+PCI_SUBSYS_ID=$VENDOR/$DEVICE
+   $VENDOR - 16-bit PCI device subsystem vendor id, in hexidecimal
+   $DEVICE - 16-bit PCI device subsystem device id, in hexidecimal
+PCI_BUS_ID=$BUS/$SLOT/$FUNC
+   $BUS- PCI bus number, in decimal
+   $SLOT   - PCI device slot, decoded from devfn, in decimal
+   $FUNC   - PCI device function, decoded from devfn, in decimal
+
+
+hotplug usb env vars
+
+HOME=/
+   Hardcoded value.
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
+   Hardcoded value.
+DEBUG=kernel
+   Hardcoded value.  Only present if USB is in debug mode
+DEVFS=/proc/bus/usb
+   Hardcoded value.  Only present if CONFIG_USB_DEVICEFS is set.
+DEVICE=/proc/bus/usb/$BUS/$DEVICE
+   Indicates the assigned USB device node for the USB device.
+   Only present if CONFIG_USB_DEVICEFS is set.
+   $BUS- USB bus number
+   $DEVICE - USB device number
+PRODUCT=$VENDOR/$PRODUCT/$DEVICE
+   USB device identification info.
+   $VENDOR - USB vendor id, in hexadecimal
+   $PRODUCT- USB product ID, in hexadecimal
+   $DEVICE - Binary-coded decimal device number
+TYPE=$CLASS/$SUB/$PROTO
+   Only present if device class is non-zero.
+   $CLASS  - USB device class.
+   $SUB- USB device sub-class.
+   $PROTO  - USB device protocol number.
+INTERFACE=$CLASS/$SUB/$PROTO
+   Only present if device class is zero.
+   Only the first interface (interface 0) is presented.
+   $CLASS  - USB interface 0 class.
+   $SUB- USB 

Re: Value of TASK_UNMAPPED_SIZE on 2.4

[Josue Emmanuel Amaro]

All,

Additional follow up.

The idea of modifying this variable is to increase the amount of memory that a
process can use.  A database like Oracle can benefit from this because it allows
Oracle to create a bigger data buffer.

An obvious side effect of allocating more physical memory to a process is that there
is less available for other things like the kernel buffer cache.  This brings up a
question.  Would a write of a data block from the Oracle data buffer incur a "read
penalty" if the block is not in the buffer cache?

For example, a data block is read by Oracle into its buffer.  Since it is read
through the file system, this block is now present in the buffer cache too.  After a
while, and since we have allocated most of the memory to Oracle, that block is
removed/replaced from the cache.

Now a transaction modifies that block in Oracle's buffer and Oracle writes it to
disk.  Does the kernel firsts reads that block into the buffer cache, "read
penalty", and then writes it to disk? Or does it just write through the buffer cache
now placing the block in the kernel buffer cache?

Regards,

--
===
  Josue Emmanuel Amaro [EMAIL PROTECTED]
  Linux Products Manager   Phone:   650.506.1239
  Intel and Linux Technologies Group   Fax: 650.413.0167
===



begin:vcard 
n:Amaro;Josue Emmanuel
tel;cell:650-245-5131
tel;fax:650-413-0167
tel;work:650-506-1239
x-mozilla-html:FALSE
url:http://www.oracle.com
org:Intel and Linux Technologies
version:2.1
email;internet:[EMAIL PROTECTED]
title:Sr.Product Manager - Linux
adr;quoted-printable:;;500 Oracle Parkway=0D=0AMS1ip4;Redwood Shores;CA;94065;United States
fn:Josue Emmanuel Amaro
end:vcard

Re: Poll and OSS API

[Jeff Garzik]

Linus Torvalds wrote:
> Considering that about 100% of the sound drivers do not follow that
> particular API damage anyway (they can't, as has been pointed out: the
> driver doesn't even receive enough information to be _able_ to follow the
> documented API), I doubt that there are all that many programs that depend
> on it.

While I'm thinking about the subject..  even after updating the API, the
drivers still need to know what events to poll for.

AFAIK 99% of the drivers currently select to block on
read/write/read+write based on file->f_mode, which works, but isn't
really correct.

Jeff


-- 
Jeff Garzik | Dinner is ready when
Building 1024   | the smoke alarm goes off.
MandrakeSoft|   -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Poll and OSS API

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Sat, 4 Nov 2000, Jeff Garzik wrote:
> > > So fix the stupid API.
> > >
> > > The above is just idiocy.
> >
> > We're pretty much stuck with the API, until we look at merging ALSA in
> > 2.5.x.  Broken API or not, OSS is a mature API, and there are
> > spec-correct apps that depend on this behavior.
> 
> Considering that about 100% of the sound drivers do not follow that
> particular API damage anyway (they can't, as has been pointed out: the
> driver doesn't even receive enough information to be _able_ to follow the
> documented API), I doubt that there are all that many programs that depend
> on it.
> 
> Yes, some drivers apparently _try_ to follow the spec to some degree, but
> we should just change the documentation asap.

Fine with me.  Allows for some driver simplification, and it only
applies to the lesser-used recording stuff at any rate.

Jeff


-- 
Jeff Garzik | Dinner is ready when
Building 1024   | the smoke alarm goes off.
MandrakeSoft|   -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Poll and OSS API

[Linus Torvalds]

On Sat, 4 Nov 2000, Jeff Garzik wrote:
> > So fix the stupid API.
> > 
> > The above is just idiocy.
> 
> We're pretty much stuck with the API, until we look at merging ALSA in
> 2.5.x.  Broken API or not, OSS is a mature API, and there are
> spec-correct apps that depend on this behavior.

Considering that about 100% of the sound drivers do not follow that
particular API damage anyway (they can't, as has been pointed out: the
driver doesn't even receive enough information to be _able_ to follow the 
documented API), I doubt that there are all that many programs that depend
on it.

Yes, some drivers apparently _try_ to follow the spec to some degree, but
we should just change the documentation asap.

Linus

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

Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strange performance behavior of 2.4.0-test9)

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
Andrew Morton  <[EMAIL PROTECTED]> wrote:
>
>neither flock() nor fcntl() serialisation are effective
>on linux 2.2 or linux 2.4.  This is because the file
>locking code still wakes up _all_ waiters.  In my testing
>with fcntl serialisation I have seen a single Apache
>instance get woken and put back to sleep 1,500 times
>before the poor thing actually got to service a request.

Indeed.

flock() is the absolute worst case, and always has been.  I guess nobody
every actually bothered to benchmark it.

>For kernel 2.2 I recommend that Apache consider using
>sysv semaphores for serialisation. They use wake-one. 
>
>For kernel 2.4 I recommend that Apache use unserialised
>accept.

No.

Please use unserialized accept() _always_, because we can fix that. 

Even 2.2.x can be fixed to do the wake-one for accept(), if required. 
It's not going to be any worse than the current apache config, and
basically the less games apache plays, the better the kernel can try to
accomodate what apache _really_ wants done.  When playing games, you
hide what you really want done, and suddenly kernel profiles etc end up
being completely useless, because they no longer give the data we needed
to fix the problem. 

Basically, the whole serialization crap is all about the Apache people
saying the equivalent of "the OS does a bad job on something we consider
to be incredibly important, so we do something else instead to hide it".

And regardless of _what_ workaround Apache does, whether it is the sucky
fcntl() thing or using SysV semaphores, it's going to hide the real
issue and mean that it never gets fixed properly.

And in the end it will result in really really bad performance. 

Instead, if apache had just done the thing it wanted to do in the first
place, the wake-one accept() semantics would have happened a hell of a
lot earlier. 

Now it's there in 2.4.x. Please use it. PLEASE PLEASE PLEASE don't play
games trying to outsmart the OS, it will just hurt Apache in the long run.

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

Re: Sample device driver - 2.2 and 2.4 support?

[Jeff Garzik]

Richard A Nelson wrote:
> I've been assigned a device driver that uses the old (2.0) PCI
> support APIs - and is still working on 2.2.
> 
> I need to get this driver working on 2.2 and 2.4, I'm assuming I'll
> need to go switch to the newer PCI stuff - but am curious about the
> toleration support in later 2.2 kernels; is it complete enough that
> I can migrate to 2.4, and still compile on 2.2?

You can still use the 2.0.x PCI functions on 2.4.x.  They are slower
than the 'struct pci_dev' versions of the functions, because each
pcibios_xxx call incurs a call to pci_find_slot().
> 
> The device:
>   1-2 DMA
>   1   IRQ
> 
> The driver:
>   mkalloc
>   __get_free_pages
>   virt_to_bus
>   request_irc
>   wake_up
> 
> The driver has similiar functionality to a sound card:
>   Send/Receive (possibly large) data to device via DMA (page fixing, etc)
> 
> Is there a cononical example (esp. wrt 2.2 <-> 2.4 changes) I should look
> at ?

That depends on both the changes and your driver...  Every driver is
different, so nothing is really canonical WRT driver API changes.  If
your driver is similar to a sound card, then look at drivers/sound/*.c
...

Jeff


-- 
Jeff Garzik | Dinner is ready when
Building 1024   | the smoke alarm goes off.
MandrakeSoft|   -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Poll and OSS API

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Thu, 2 Nov 2000, Thomas Sailer wrote:
> >
> > The OSS API (http://www.opensound.com/pguide/oss.pdf, page 102ff)
> > specifies that a select _with the sounddriver's filedescriptor
> > set in the read mask_ should start the recording.
> 
> So fix the stupid API.
> 
> The above is just idiocy.

We're pretty much stuck with the API, until we look at merging ALSA in
2.5.x.  Broken API or not, OSS is a mature API, and there are
spec-correct apps that depend on this behavior.

(FWIW, ALSA nicely marginalizes its OSS support into a single module, so
that ALSA drivers aren't affected by OSS' ugliness)

Jeff


-- 
Jeff Garzik | Dinner is ready when
Building 1024   | the smoke alarm goes off.
MandrakeSoft|   -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Russ Allbery]

Tim Riker <[EMAIL PROTECTED]> writes:

> Agreed. C99 does not replace all the needed gcc features. We should
> start using the ones that make sense, and push for
> standardization/documentation on the rest.

> I'm perfectly happy with this as a long term goal. I'll put what effort
> I can into moving that direction without breaking the existing world as
> we know it.

May I tentatively suggest that one point at which your resources could
productively be applied is towards improving the C99 compliance in gcc?
Clearly for the near to medium future the compiler that everyone will use
to build the Linux kernel will be gcc, which means that in order to use
any C99 syntax, it first has to be solid in gcc.  That means the best way
of introducing such things into the Linux kernel is to *first* get the C99
support solid, reliable, and efficient in gcc, then once a version of gcc
is released with that support, help get Linux compiling with that version
of gcc.

*Then*, when that version of gcc can be made a prerequisite for the
kernel, you can start switching constructs over to the C99 syntax that gcc
supports.

This is obviously a slow and drawn-out process, but in the end the free
software community not only gets a better-documented syntax in the Linux
kernel code that's more likely to be clearly supported and not broken by
gcc in the future, but the broader community also gets a more closely
conforming compiler that supports the latest C features.

 has the current status of the
development versions of gcc.  There are a lot of items listed as Broken or
Missing that I'm sure the gcc developers would welcome volunteer help
with.

(Note that there is not and quite likely never will be any standard syntax
for in-line assembly, as the standardization committee considers it to be
outside their scope, so I doubt you'll ever be completely successful.  But
I think your goal is one that can reap benefits even when only partially
accomplished.)

-- 
Russ Allbery ([EMAIL PROTECTED]) 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Oops when loading 3c509-module in test10

[Jeff Garzik]

Håvard Garnes wrote:
> 
> This occurs when the 3c509-module is being loaded at startup, and in
> /proc/modules it is listed as (initialising). It it worth mentioning
> that I have two 3c509-cards in my computer. This worked in test8.

Oops.  This is one of the newer (and better) ISA modules, which actually
does allocate its device structure correctly.

Please apply this patch...

Jeff


-- 
Jeff Garzik | Dinner is ready when
Building 1024   | the smoke alarm goes off.
MandrakeSoft|   -/usr/games/fortune

Index: linux_2_4/drivers/net/3c509.c
diff -u linux_2_4/drivers/net/3c509.c:1.1.1.5 linux_2_4/drivers/net/3c509.c:1.1.1.3
--- linux_2_4/drivers/net/3c509.c:1.1.1.5   Tue Oct 31 13:21:47 2000
+++ linux_2_4/drivers/net/3c509.c   Sun Oct 22 13:29:58 2000
@@ -434,6 +436,13 @@
/* Free the interrupt so that some other card can use it. */
outw(0x0f00, ioaddr + WN0_IRQ);
  found:
+   if (dev == NULL) {
+   dev = init_etherdev(dev, sizeof(struct el3_private));
+   if (dev == NULL) {
+   release_region(ioaddr, EL3_IO_EXTENT);
+   return -ENOMEM;
+   }
+   }
memcpy(dev->dev_addr, phys_addr, sizeof(phys_addr));
dev->base_addr = ioaddr;
dev->irq = irq;

Re: [BUG] /proc//stat access stalls badly for swapping process,2.4.0-test10

[Mike Galbraith]

On Fri, 3 Nov 2000, Jens Axboe wrote:

> On Fri, Nov 03 2000, Mike Galbraith wrote:
> > > I very much agree.  Kflushd is still hungry for free write
> > > bandwidth here.
> > 
> > In the LKML tradition of code talks and silly opinions walk...
> > 
> > Attached is a diagnostic patch which gets kflushd under control,
> > and takes make -j30 bzImage build times down from 12 minutes to
> > 9 here.  I have no more massive context switching on write, and
> > copies seem to go a lot quicker to boot.  (that may be because
> > some of my failures were really _really_ horrible)
> > 
> > Comments are very welcome.  I haven't had problems with this yet,
> > but it's early so...  This patch isn't supposed to be pretty either
> > (hw techs don't do pretty;) it's only supposed to say 'Huston...'
> > so be sure to grab a barfbag before you take a look. 
> 
> Super, looks pretty good from here. I'll give it a go when I get back.
> In addition, here's a small patch that disables the read stealing
> of requests from the write list -- does that improve behaviour
> when we are busy flushing?

Yes.  I've done this a bit differently here, and have had good
results.  I only disable stealing when I need flush throughput.

Now that the box isn't biting off more than it can chew quite
as often, I'll try this again.  I'm pretty darn sure that I can
get more throughput, but :> I've learned that getting too much
can do really OOGLY things. (turns box into single user single
tasking streaming IO monster from hell)

-Mike

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

Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)

[Aaron Sethman]

On Thu, 2 Nov 2000, Andi Kleen wrote:

> On Thu, Nov 02, 2000 at 07:07:12PM +, Alan Cox wrote:
> > > 1. There are architectures where some other compiler may do better
> > > optimizations than gcc. I will cite some examples here, no need to argue
> > 
> > I think we only care about this when they become free software.
> 
> SGI's pro64 is free software and AFAIK is able to compile a kernel on IA64.
> It is also not clear if gcc will ever produce good code on IA64.

Well if its compiling the kernel just fine without alterations to the
code, then fine. If not, if the SGI compiler is GPL'd pillage its sources
and get that code working in gcc. Otherwise, trying to get linux to work
with other C compilers doesn't seem worth the effort. 

Aaron

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

Re: [patch] NE2000

[Andrew Morton]

Jorge Nerin wrote:
> 
> ...
> So I think that it could be a little window near sock_wait_for_wmem that
> could be SMP insecure wich is affecting me.
> 
> The code of sock_wait_for_wmem in 2.4.0-test10 is this:
> 
> static long sock_wait_for_wmem(struct sock * sk, long timeo)
> {
> DECLARE_WAITQUEUE(wait, current);
> 
> clear_bit(SOCK_ASYNC_NOSPACE, >socket->flags);
> add_wait_queue(sk->sleep, );
> for (;;) {
> if (signal_pending(current))
> break;
> set_bit(SOCK_NOSPACE, >socket->flags);
> set_current_state(TASK_INTERRUPTIBLE);
> if (atomic_read(>wmem_alloc) < sk->sndbuf)
> break;
> if (sk->shutdown & SEND_SHUTDOWN)
> break;
> if (sk->err)
> break;
> timeo = schedule_timeout(timeo);
> }
> __set_current_state(TASK_RUNNING);
> remove_wait_queue(sk->sleep, );
> return timeo;
> }
> 
> Does someone see something SMP insecure? Perhaps I'm totally wrong, this
> could also be somewhere in the interrupt handling, don't know.

No, that code is correct, provided (current->state == TASK_RUNNING)
on entry.  If it isn't, there's a race window which can cause
lost wakeups.   As a check you could add:

if ((current->state & (TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE)) == 0)
BUG();

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

Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was:Strange performance behavior of 2.4.0-test9)

[Andrew Morton]

dean gaudet wrote:
> 
> On Tue, 31 Oct 2000, Andrew Morton wrote:
> 
> > Dean,  it looks like the same problem will occur with flock()-based
> > serialisation.  Does Apache/Linux ever use that option?
> 
> from apache/src/include/ap_config.h in the linux section there's
> this:
> 
> /* flock is faster ... but hasn't been tested on 1.x systems */
> /* PR#3531 indicates flock() may not be stable, probably depends on
>  * kernel version.  Go back to using fcntl, but provide a way for
>  * folks to tweak their Configuration to get flock.
>  */
> #ifndef USE_FLOCK_SERIALIZED_ACCEPT
> #define USE_FCNTL_SERIALIZED_ACCEPT
> #endif
> 
> so you should be able to -DUSE_FLOCK_SERIALIZED_ACCEPT to try it.
> 

Dean,

neither flock() nor fcntl() serialisation are effective
on linux 2.2 or linux 2.4.  This is because the file
locking code still wakes up _all_ waiters.  In my testing
with fcntl serialisation I have seen a single Apache
instance get woken and put back to sleep 1,500 times
before the poor thing actually got to service a request.

For kernel 2.2 I recommend that Apache consider using
sysv semaphores for serialisation. They use wake-one. 

For kernel 2.4 I recommend that Apache use unserialised
accept.

This means that you'll need to make a runtime decision
on whether to use unserialised, serialised with sysv or
serialised with fcntl (if sysv IPC isn't installed).


In my testing I launched 3, 10, 30 or 150 Apache instances and then used

httperf --num-conns=2000 --num-calls=1 --uri=/index.html

to open, use and close 2000 connections.

Here are the (terrible) results on 2.4 SMP with fcntl
serialisation:

fcntl accept, 3 servers, vanilla: 938.0 req/s
fcntl accept, 30 servers, vanilla: 697.1 req/s
fcntl accept, 150 servers, vanilla: 99.9 req/s (sic)

2.4 SMP with no serialisation:

unserialised accept, 3 servers, vanilla: 1049.0 req/s
unserialised accept, 10 servers, vanilla: 968.8 req/s
unserialised accept, 30 servers, vanilla: 1040.2 req/s
unserialised accept, 150 servers, vanilla: 1091.4 req/s

2.4 SMP with no serialisation and my patch to the
wakeup and waitqueue code:

unserialised accept, 3 servers, task_exclusive: 1117.4 req/s
unserialised accept, 10 servers, task_exclusive: 1118.6 req/s
unserialised accept, 30 servers, task_exclusive: 1105.6 req/s
unserialised accept, 150 servers, task_exclusive: 1077.1 req/s

2.4 SMP with sysv semaphore serialisation:

sysvsem accept, 3 servers: 1001.2 req/s
sysvsem accept, 10 servers: 1061.0 req/s
sysvsem accept, 30 servers: 1021.2 req/s
sysvsem accept, 150 servers: 943.6 req/s

2.2.14 SMP with fcntl serialisation:

fcntl accept, 3 servers: 1053.8 req/s
fcntl accept, 10 servers: 996.2 req/s
fcntl accept, 30 servers: 934.3 req/s
fcntl accept, 150 servers: 141.4 req/s(sic)

2.2.14 SMP with no serialisation:

unserialised accept, 3 servers: 1039.9 req/s
unserialised accept, 10 servers: 983.1 req/s
unserialised accept, 30 servers: 775.7 req/s
unserialised accept, 150 servers: 220.7 req/s (sic)

2.2.14 SMP with sysv sem serialisation:

sysv accept, 3 servers: 932.2 req/s
sysv accept, 10 servers: 910.6 req/s
sysv accept, 30 servers: 1026.6 req/s
sysv accept, 150 servers: 927.2 req/s


Note that the first test (2.4 with fcntl serialisation) was
with an unpatched 2.4.0-test10-pre5.  Once the simple
flock.patch is applied, the performance with 150 servers
doubles.  But it's still sucky.  The flock.patch change
is effective in increasing scalability wiht a large number
of CPUs, not a large number of httpd's.

Here's the silly patch I used to turn on sysv sem serialisation
in Apache.  There's probably a better way than this :)

--- apache_1.3.14.orig/src/main/http_main.c Fri Sep 29 00:32:36 2000
+++ apache_1.3.14/src/main/http_main.c  Sat Nov  4 15:01:41 2000
@@ -172,6 +172,13 @@
 
 #include "explain.h"
 
+/* AKPM */
+#if 1
+#define NEED_UNION_SEMUN
+#define USE_SYSVSEM_SERIALIZED_ACCEPT
+#define USE_FCNTL_SERIALIZED_ACCEPT
+#endif
+
 #if !defined(max)
 #define max(a,b)(a > b ? a : b)
 #endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: Negative scalability by removal of lock_kernel()?(Was: Strange performance behavior of 2.4.0-test9)

[Andrew Morton]

[EMAIL PROTECTED] wrote:
> 
> Andrew Morton writes:
>  > This patch is a moderate rewrite of __wake_up_common.  I'd be
>  > interested in seeing how much difference it makes to the
>  > performance of Apache when the file-locking serialisation is
>  > disabled.
>  > - It implements last-in/first-out semantics for waking
>  >   TASK_EXCLUSIVE tasks.
>  > - It fixes what was surely a bug wherein __wake_up_common
>  >   scans the entire wait queue even when it has found the
>  >   task which it wants to run.
> 
> We've measured Apache w/ and w/o serialize_accept on
> several kernel configurations.
> 
> Apache compilation settings are those two:
> * without option (conventional setting)
>   (w/ serialize)
> * with -DSINGLE_LISTEN_UNSERIALIZED_ACCEPT
>   (w/o serialize)
> 
> We compared the performance of distributed binary and our binary with
> default setting, the performance is almost equivalent. All following
> data are based on our binaries.
> 
> w/ serializew/o serialize
> 2.40-t10-pre5   22375358
> 2.40-t10-pre5+P252535355**
> 2.40-t10-pre5+P3--- NG
> 
> ** with this configuration, once we observed the machine completely
> deadlocked with the following message:
> 
> Unable to handle kernel NULL pointer dereferenceNMI watchdog detected LOCKUP on CPU1.

That's not good.  `P2' just puts a couple of lock_kernel's into
the file locking code, and apache wasn't using that code when
your machine died.  So it looks like dropping the serialisation
has tickled a problem in test10-pre5.

> 
> 2.4.0-test10-pre5 with the LIFO patch (P3), we can't get the values.
> It always deadlock with same manner.  Perhaps, it failed to get
> console lock then deadlock.

mm..  Relying on the task_struct.state value in __wake_up_common() is
tricky - I guess you hit some races.  Sorry.  I ended up having to
rewrite the guts of the waitqueue and wakeup code to be able to
reliably avoid scanning the entire wait queue every time we wake an
exclusive task.

There are two patches attached here.

flock.patch: this simply puts the lock_kernel calls around the
file locking code.  We already have figures for that (it doubles
Apache's connection rate on uniprocessor, but it's still
_terrible_ when you have 100 servers).

task_exclusive.patch:  this is a redesign of the current waitqueue
and wakeup code.  Again, it provides LIFO handling of exclusive
tasks and avoids a scan of the entire waitqueue.  Hopefully it won't
lock up your machine this time!

I'd be interested in seeing the results on both serialised and
unserialised Apache when these are applied, please.

Here are my numbers.  This is with
httperf --num-conns=2000 --num-calls=1 --uri=/index.html
Basically, there's not a lot of difference here because
the test machine only has 2 CPUs.

   #Serversunpatched   patched
   conn/secconn/sec

2xCPU, serialised

3 938.0 956.2
10  943.2
30697.1 737.9
150   99.9  196.2(sic)

2xCPU, unserialised

3 1049.01117.4
10 968.81118.6
301040.21105.6
150   1091.41077.1

--- linux-2.4.0-test10-pre5/fs/fcntl.c  Sun Oct 15 01:27:45 2000
+++ linux-akpm/fs/fcntl.c   Fri Nov  3 20:42:47 2000
@@ -254,11 +254,15 @@
unlock_kernel();
break;
case F_GETLK:
+   lock_kernel();
err = fcntl_getlk(fd, (struct flock *) arg);
+   unlock_kernel();
break;
case F_SETLK:
case F_SETLKW:
+   lock_kernel();
err = fcntl_setlk(fd, cmd, (struct flock *) arg);
+   unlock_kernel();
break;
case F_GETOWN:
/*





--- linux-2.4.0-test10-pre5/include/linux/wait.hSun Oct 15 01:27:46 2000
+++ linux-akpm/include/linux/wait.h Fri Nov  3 21:14:30 2000
@@ -14,45 +14,24 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 
 /*
- * Temporary debugging help until all code is converted to the new
- * waitqueue usage.
+ * Debugging control.  Slow and useful.
  */
 #define WAITQUEUE_DEBUG 0
 
-#if WAITQUEUE_DEBUG
-extern int printk(const char *fmt, ...);
-#define WQ_BUG() do { \
-   printk("wq bug, forcing oops.\n"); \
-   BUG(); \
-} while (0)
-
-#define CHECK_MAGIC(x) if (x != (long)&(x)) \
-   { printk("bad magic %lx (should be %lx), ", (long)x, (long)&(x)); WQ_BUG(); }
-
-#define CHECK_MAGIC_WQHEAD(x) do { \
-   if (x->__magic != (long)&(x->__magic)) { \
-   printk("bad magic %lx (should be %lx, creator %lx), 

Re: 2.2.x BUG & PATCH: recvmsg() does not check msg_controllen correctly

[David S. Miller]

   From: Philippe Troin <[EMAIL PROTECTED]>
   Date: 03 Nov 2000 19:53:04 -0800

   Yes I agree, mixing signed and unsigned arithmetic is evil... Doesn't
   gcc have a flag for unsafe signed/unsigned mixtures ?

   Would you consider this patch (or a variant) for inclusion ?

I would accept a patch which made the code set fdmax <= 0 when
(msg->msg_controllen < (sizeof(struct cmsghdr) + sizeof(int)))
because it is the sole reason this bug exists at all.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

non-gcc linux?

[Bryan Sparks]

Let me see if I understand you correctly. Metrowerks (Motorola) makes a 
twenty something million dollar investment in your little company, and as 
part of the agreement (not to mention Metrowerk's sole motivation) you are 
required to create a version of Linux that compiles under their ANSI c tool 
chain. Furthermore, you are attempting to lobby the community into helping 
your effort under the pretense that it is for the good of Linux? Survey 
says...bzzzsst. Wrong answer Chuck, but for your consolation prize you get 
your own non-standard, divergent Linux.

Thanks for playing!
Bryan


Tim Riker wrote:

All,

Alright, I've been lurking long enough on this thread. What say we
consider the option of building the kernel with a compiler other than
gcc? This would imply a slightly different structure to the makefiles
and code.

There are two immediate reasons I can come up with for this:

1. There are architectures where some other compiler may do better
optimizations than gcc. I will cite some examples here, no need to argue
out the point unless you disagree with the POSSIBILITY that this may be
true on at least one architecture. Anyway, possibilities include
Compaq's compiler on alpha, HP's compiler on hppa, Intel's compiler (or
rather plugins to another vendors compiler) on ia64, Metrowerk's
compiler on PPC, etc.

2. There are architectures where gcc is not yet available, but vendor C
compilers are.

I suggest that we avoid gcc extensions as much as possible, barring
performance hits. When there is an ANSI way of doing things we should
choose that route. Where there is not, then isolate the gcc way such
that compiler vendors can either:

1. implement the gcc way and conditional compile that code.

2. implement some other way and easily add that conditional code.

I've been looking into this here at Lineo for some of these vendors.
Here is a brief list of things I've come across:

1. C++ style comments

Occurs in over 4000 lines of source and header files. :-( Should be
converted to ansi c comments? We will probably want to just skirt this
issue for now as the next rev of ANSI C is likely to include ANSI C++
style comments.

2. Inline assembly statements

mostly in arch/ tree. Frequently used in macros as well. Much of this
will incur performance penalties if moved to external assembly files.
Some would require moving supported C code over as well. Hence many of
these will probably translate into conditional compilation based on the
compiler to avoid and performance hit for the mainstream case.

3. Declaring attributes of functions

The __attribute__ options: noreturn, const, format, section,
constructor, destructor, unused, and weak. weak and section are needed.
The rest can be ignored? These might want to be converted to #defines
such that alternative compilers can implement them differently.

4. Specifying attributes of variables

The __attribute__ options: aligned, packed, section and weak. As above
these will likely be #defines to handle different compiler syntax.

5. Conditionals with omitted operands

The missing operands should just be added into the mainstream source.

6. Referring to a type with typeof

no recommendation yet.

7. Macros with variable numbers of arguments

no recommendation yet.

8. Inquiring on alignment of types or variables (__alignof__)

no recommendation yet.

Well, I got a bit more long winded than I planned, but there it is.
Thoughts?

"H. Peter Anvin" wrote:
>
>Followup to: <[EMAIL PROTECTED]> By author: "David S. 
>Miller" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > We already 
>know we are a bunch of pinheads wrt. the userland compiler > issue, full 
>stop. It need not be restated several hundred more times. > Believe me, 
>after such a large fiasco, we have listened :-) > > But, on the other hand, 
>to say that "kgcc" comceptually is something > only Red Hat has ever done 
>is a factual error, that is all I am trying > to state, nothing more. >
>
>I think at least supporting a "kgcc" compiler makes sense, conceptually 
>(although it probably should have been called "kcc", but it's too late 
>now.)
>
>The kernel uses a lot of gcc extensions, and history shows that these 
>extensions aren't as stable as the compiler system as a whole.
>
>-hpa

--
Tim Riker - http://rikers.org/ - short SIGs! 
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

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

Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land

[Theodore Y. Ts'o]

   Date:Fri, 03 Nov 2000 14:44:17 -0500
   From: [EMAIL PROTECTED]

   My problem is that pthread_create (glibc 2.1.3, kernel 2.2.17 i686) is
   failing because, deep inside glibc somewhere, nanosleep() is returning
   EINTR.

Sounds like it might be a bug in pthread_create although that's not
clear.  You haven't given enough information to be sure.

   My code is not using signals.  The threading library is, and there is
   obviously some subtle bug going on here.  Ever wonder why when browsing
   with Netscape and you click on a link and it says "Interrupted system
   call."?  This is it.  I'm arguing that the default behaviour should be
   SA_RESTART, and if some programmer is so studly that they actually know
   what the hell they are doing by disabling SA_RESTART, then they can do
   it explicitly.

Ok first of all, the behaviour of sigaction is specified by the POSIX
standards.  To quote from the POSIX Rationale for section 3.3 (B.3.3):

"Unlike all previous historical implementations, 4.2 BSD
restarts some interrupted system calls rather than returning on
error with errno set to [EINTR] after the signal-catching
function returns.  THIS CHANGE CAUSED PROBLEMS FOR SOME
APPLICATION CODE.  (Emphasis mine.)  4.3 BSD and other systems
derived from 4.2BSD allow the application to choose whether
system calls are to be restarted.   POSIX.1 (in 3.3.4) does not
require restart of functions because it was not clear that the
semantics of system-call restart in any historical
implementation to be of value in a standard.  Implementors are
free to add such mechanisms as extensions."

In Linux, we (well, actually I) added this extension as the SA_RESTART
flag.  However, other parts of POSIX make it very clear that in absence
of any extension such as SA_RESTART, "If the signal catching function
executes a return, the behaviour of the interrupted function shall be as
described individually for that function" (POSIX.1, 3.3.1.4).  And for
most functions, it is specified that they return EINTR if they are
interrupted by a signal.

So the answer is that if you want this behaviour, you have to call
sigaction with the appropriate flags --- namely SA_RESTART.

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

Re: 255.255.255.255 won't broadcast to multiple NICs

[Rob Landley]

--- Philippe Troin <[EMAIL PROTECTED]> wrote:
> Rob Landley <[EMAIL PROTECTED]> writes:

> The source IP address (as returned by getsockname())
> is only set when
> the socket is connected... It follows the same
> logic: for a multihomed
> machine, we know which interface will be used only
> when we know who
> we'll be talking to...

I know, it does make sense.  I'm not really blaming
Java for that one.  It's just yet another thing I
tried that didn't work.  The lack of a way to query
what the current addresses are directly is the only
reason I tried that as a potential workaround.  (If
it's going to return 0 unless you told it what the
address was in the first place, why do they have a
query address method on a server socket anyway?  Does
it serve a purpose?  Right...)

This isn't the most egregious oversight in java, by
the way.  The list is pretty long, but my vote goes
for being unable to truncate a file before Java 1.2. 
(There was no API for it.  Couldn't be done.  Period. 
getLength() was there, but setLength() wasn't.  And I
had to email them more than once before they'd admit
it was a bug...)

> You could use SIOGIFCONF (from C) to get the address
> list.

See "avoidance of native code" under the heading
"configuration details I don't want them to have to
deal with".  When I make platform specific installers
(which there will be for both Linux and NT/2000), i'll
throw a shell around it and feed info in on the
command line.  But a better solution is not having to
do it at all, which is the case for machines with one
NIC.

> I'm not sure is java has the equivalent...

It doesn't.

> Or maybe a very small native method...

Querying the system when it first runs and passing the
data onthe command line, maybe.  Running platform
specific native code during execution, no.

> > > Broadcast is ugly anyways, why don't you use
> > > multicast ?

Having looked into this question a bit more, I can now
answer:

Because broadcast is, in this case, a more elegant
solution, which requires less configuration (even NOT
working the way I expected), and (as far as I can
tell) is actually more efficient (in this case) in
terms of utilizing network resources, and has no known
scalability problems as used here, either. 
(Especially for the server, which is the most likely
bottleneck.)

The most common case here is that the server
broadcasts to all clients (either during boot or after
a period of inactivity).  In either case, when this
happens all clients are interested in hearing what the
server has to say.

The only time where this isn't the case is when an
individual client is rebooted and has to look for its
server.  This case is relatively rare (not a
scalability issue from a network traffic standpoint,
anyway, even Google only reboots around a hundred
boxen a day).  Only the server would respond to the
traffic here, so there's no broadcast storm.  (The
initial boot case is closer to that, but the response
is via TCP, not UDP.)  And I fail to see how multicast
improves the client reboot case.  If multicast ISN'T,
underneath it all, doing a broadcast at the MAC level,
then how is it supposed to find the server if it
doesn't know where it is?  So what have we gained?

And in any case, as long as the broadcast mechanism's
already been implemented for the first paragraph,
implementing a gratuitous second mechanism for a
fairly rare case is a gratuitous source of complexity
and potential bugs for no apparent reason.

> Sounds like a good job for multicast... It's fairly
> simple to use,
> but:

I still don't understand why you consider broadcast a
bad solution here.  (Other than aesthetic reasons.) 
If multicast requires configuration and the whole
point of the broadcast packets in the first place was
to AVOID configuration...  I missed something.

>   1) I'm not sure if java gives you access to the
> required ioctls
>  (there's only five of them).

It does (or at least claims to), but you still haven't
explained WHY multicast is a more elegant solution in
this case than broadcast.  Broadcast is actually the
same mechanism as sending targeted UDP packets to
hosts to wake them up, except the list I iterate
through is one address long.  Multicast is a
completely different mechanism.

You want to explain how multicast works to me down at
the MAC layer?  Is the server sending a small number
of broadcast MAC packets, or a large number of
individually MAC addressed packets to each host that
has registered itself as interested in these
broadcasts.  If the former, what's really changed?  If
the latter, how did they register themselves as
interested in the first place?

How about compatability?  Will it work on the various
flavors of windows box?  Will it work on an Irix box? 
Would it conceivably work on a power Mac?  I know
broadcast is at least theoretically present in every
networking stack there is, whereas multicast is an
option that has to be complied into the Linux kernel,
so I can't even count on it being there 

Re: linux-2.4.0-test9

[Jeff Garzik]

"Richard B. Johnson" wrote:
> On Fri, 3 Nov 2000, Jeff Garzik wrote:
> > "Richard B. Johnson" wrote:
> > > (3)  With the new kernel, I can't access screen memory anymore. When
> > > testing software drivers for hardware that I don't have, I usually use
> > > the screen-regen buffer to emulate the shared memory window.
> > >
> > > Here is a snippet of code:
> > >
> > > //info->mem = 0xb8000 what they actually are
> > > //info->mem_len = 0x4000
> > >
> > > if((info->vxi_iomem = ioremap(info->mem, info->mem_len)) == NULL)
> > > {
> > > printk(KERN_ALERT "%s: Can't allocate shared memory\n", devname);
> > > (void)unregister_chrdev(info->major, info->dev);
> > > kfree(info->tmp_buf);
> > > kfree(info);
> > > return -ENOMEM;
> > > }
> > > info->vxi_base   = (UNIV *) bus_to_virt(UL info->vxi_iomem);
> > > ||
> > > This pointer should point to the beginning of the screen buffer.
> > > It always has before.
> > >
> > > When accessing this from a module, I get;
> > > Unable to handle kernel paging requist at virtual address 800b8304.
> >
> > bug 1) ioremap returns a cookie, not a bus address.  therefore, calling
> > ioremap output to bus_to_virt is incorrect.
> >
> 
> So explain??  What do you mean a cookie?

ioremap returns a value that ideally should only be passed on to other
MMIO functions:  iounmap, readb, readw, readl, writeb, writew, writel,
memcpy_toio, memcpy_fromio, etc.

Think of ioremap as returning a token which can be passed back into the
above list of functions.  You should never dereference ioremap'd memory
directly...


> > bug 2) what are you doing with vxi_base?  I don't have the rest of your
> > code here, but I'm willing to bet that you are directly de-referencing
> > memory, instead of using {read,write}[bwl] / memcpy_{to,from}io.  Read
> > linux/Documentation/IO-mapping.txt for more info.
> >
> 
> Nope. It's copied, using memcpy_to/from_io, into a kmalloc()ed buffer.

As long as you are passing ioremap'd address to memcpy_to/from_io,
that's ok.


> However, there is a section, of 0x800 dwords that are accessed as
> registers (directly).
> 
> This will be a real bitch, if necessary, with the real device because
> I have to reference 0x800 dwords as device registers.

> And if I can't do that, I am totally screwed, and will have to stay
> with a version that allows it. I can just imagine code that references
> these registers using an obscure macro. It just won't be maintainable
> and I don't intend to live with the code for the product lifetime.

Well, ioremap returns a virtual address, which is directly accessible to
the local CPU.  Maybe (as a hack) you can completely ignore what I said
above, and directly de-reference the ioremap'd memory.  ie. eliminate
info->vxi_base altogether.

But if you are going to eliminate info->vxi_base, it seems like that
would flush out all direct de-refs, whether they are buried in an
obscure macro or not.  And if you find all that crap, you might as well
use readb/writel at that point...

info->registers[0x7FF] = newvalue;
becomes
writel(newvalue, >registers[0x7FF]);
and
regval = info->registers[0x7FF];
becomes
regval = readl(>registers[0x7FF]);

-- 
Jeff Garzik | Dinner is ready when
Building 1024   | the smoke alarm goes off.
MandrakeSoft|   -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land programmer...

[David Feuer]

I seem to recall when reading about sigaction in APUE, that while sigaction 
solves many of the races that can come up with various "signal" 
implementations, there were still some cases where there was no way to do 
what was desired without races.  Is there ANY way (in theory, at least) to 
create a race-free signalling system?

--
This message has been brought to you by the letter alpha and the number pi.
David Feuer
[EMAIL PROTECTED]

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

Re: linux-2.4.0-test9

[Richard B. Johnson]

On Fri, 3 Nov 2000, Jeff Garzik wrote:

> "Richard B. Johnson" wrote:
> > I have, again, tried to use a new kernel. It is linux-2.4.0-test9
> > Apparently a newer version was just put up while downloading this
> > one. This is possible because it took a day to download it );
> 
> If you could download patch-2.4.0-test10, and try out test10-final, that
> would be awesome...
> 
I will do that Monday.

> 
> > (3)  With the new kernel, I can't access screen memory anymore. When
> > testing software drivers for hardware that I don't have, I usually use
> > the screen-regen buffer to emulate the shared memory window.
> > 
> > Here is a snippet of code:
> > 
> > //info->mem = 0xb8000 what they actually are
> > //info->mem_len = 0x4000
> > 
> > if((info->vxi_iomem = ioremap(info->mem, info->mem_len)) == NULL)
> > {
> > printk(KERN_ALERT "%s: Can't allocate shared memory\n", devname);
> > (void)unregister_chrdev(info->major, info->dev);
> > kfree(info->tmp_buf);
> > kfree(info);
> > return -ENOMEM;
> > }
> > info->vxi_base   = (UNIV *) bus_to_virt(UL info->vxi_iomem);
> > ||
> > This pointer should point to the beginning of the screen buffer.
> > It always has before.
> > 
> > When accessing this from a module, I get;
> > Unable to handle kernel paging requist at virtual address 800b8304.
> 
> bug 1) ioremap returns a cookie, not a bus address.  therefore, calling
> ioremap output to bus_to_virt is incorrect.
> 

So explain??  What do you mean a cookie?


> bug 2) what are you doing with vxi_base?  I don't have the rest of your
> code here, but I'm willing to bet that you are directly de-referencing
> memory, instead of using {read,write}[bwl] / memcpy_{to,from}io.  Read
> linux/Documentation/IO-mapping.txt for more info.
> 

Nope. It's copied, using memcpy_to/from_io, into a kmalloc()ed buffer.

However, there is a section, of 0x800 dwords that are accessed as
registers (directly).

This will be a real bitch, if necessary, with the real device because
I have to reference 0x800 dwords as device registers.

And if I can't do that, I am totally screwed, and will have to stay
with a version that allows it. I can just imagine code that references
these registers using an obscure macro. It just won't be maintainable
and I don't intend to live with the code for the product lifetime.

> 
> > (4) More name-space polution. Somebody added another macro called
> > get_page(). When, if ever, will we start using the good-old
> > convention of defining macros in upper-case?
> > 
> > The name-space polution has really gotten out-of-hand. You
> > can't write code using ordinary symbol names anymore. You
> > need to make variables have names like:
> > 
> > int LoopCounterForOutSideLoop;
> > char *UserInputAndOutputBufferForWednesday;
> > 
> > This is NotGood(tm)
> 
> I guess it should probably have been named "page_get"?  I looked through
> 'nm vmlinux' output at the public symbols, and there are definitely a
> ton of them.
> 
> Though it is definitely C convention that macros are in all uppercase
> (gcc is good about this), the kernel has never really been good about
> that...
> 
>   Jeff
 

Cheers,
Dick Johnson

Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[David Ford]

Alan Cox wrote:

> > > Not unless it was fixed in test10 release.  I have a PC LinkSys dual 10/100 and
> > > 56K card that will kill the machine if you physically pull it out no matter what
> Linksys rings a bell with an outstandng 2.2 lockup on pcmcia. I think this might
> be a driver bug ?

I suspect it might be, I also think it may be getting the wrong voltage or it's poorly
designed hardware.  It gets hot enough to make a blister if you don't handle it
carefully.

It works fine all the while installed, goes for days on end, even tho it gets
incredibly hot. :)

-d

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."




begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;-12480
fn:David Ford
end:vcard

Re: [BUG REPORT] TCP/IP weirdness in 2.2.15

[Thomas Pollinger]

Hi Stephen

I've been experiencing similar problems with what would seem at first a 
completely unrelated problem. To make things short:

I have the following configuration:
- CVS server (vers. 1.10.4) running on HPUX B.11.00
- different CVS clients (running different cvs client versions: 1.10.4/7/8):
  - Win NT (PIII, 512MB, 3c905 10/100)
  - Debian 2.2.17 (PII, 256MB, 3c905, main client tester)
  - Mandrake 2.2.x (3c905)
  - RedHat 6.2 (Laptop, different Ethernet card)
  - SuSE 2.2.10 (PII, 256MB, 3c905)

Running a 'cvs get' on the Linux clients of a larger source tree eventually 
hangs the client in the middle of the get process. The hang is *always* 
reproduceable (however it does not always hang at the same place, sometimes 
after 1', sometimes after 5' to 10'). Several runs on Win NT did not show 
this problem.

Running a strace on the client and server reveals that the client gets 
stuck in a read(3, resp. recv(3, call (a recompiled the cvs client to not 
use file descriptors for an additional test) and blocks forever (I left it 
once during one night). The server tries first to send to the client, but 
gets an EWOULDBLOCK error back. The server tries to send to the client for 
about 5' during which no packets are accepted by the client. tcpdump 
revealed that after the hang, sometimes the client did not accept any 
packets (ack 0), sometimes it replied . ack 7678261 back (this will go 
forever if the client won't be killed). The server replies: P 
7678261:76784009 (1448) ack 612 win 32768 ... indefinitely.

To keep the mail short, I can run a test and send all related logs if needed.

I first thought that I got not a recent network driver and compiled a more 
recent one (v0.99H 12Jun00 was old, new: 16Aug00 <2.2.17-pre17>) - but the 
behaviour was the same.

At last, I tried to do the same on another HP-UX box and there was no 
blocking at all.
What is interesting to know is that between the HP-UX server and the HP 
client is a Linux router with a 3c905 card, 2.2.14 kernel.

Regards,
Pollinger Thomas


--
Below the original mail from Stephen (as it has been a while ago this 
message was posted):

Hi Folks,
I'm seeing some very strange behaviour here with TCP/IP connections
(or at least, it looks strange to me) - under heavy load, it appears
connections are spuriously dropped.
Bear with me while I give a little background...
...I'm actually trying to perform some SPECweb99 benchmarking; I have
a test bed of 5 clients and 1 server. For those of you who are not
familiar with SPECweb99, let's just say that it tries to simulate
'real world' traffic - a mixture of HTTP GET, POST, static and dynamic
GET, keepalive connections, non-keepalive connections... basically
hammer the server as hard as you can until it grinds to a halt. Each
client has one controlling (parent) process which forks off N children
to generate the HTTP load. One client is a designated 'prime client'
which synchronises the rest of the clients. If you're interested in
more SPEC info, there's a very informative whitepaper on their
website, have a look at http://www.spec.org/osg/web99
The "dropped connection" manifests itself by the SPEC run 'hanging' -
at the end of the test there is one or more child processes on one or
more clients stuck in a read(2), trying to read from a
socket. (usually, one child process on one client).
If I do a netstat on the client I see an ESTABLISHED connection:
[stephenl@spec1 stephenl]$ netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
[...]
tcp 0 0 spec1.specweb.zeus:6426 spec6.specweb.zeus.:www ESTABLISHED
[...]
[stephenl@spec1 stephenl]$
(spec1 is the client, spec6 is the server. As it happens, spec1 is
also my prime client - this is just a coincidence in this particular
lockup)
If I hop over to the server and do a netstat there, I
see... nothing. No ESTABLISHED connection, no TIME_WAIT, no
CLOSE_WAIT. Nothing.
Question: is this valid? (I think it may be, if the server
crashed. Which it didn't - all machines have enjoyed a nice long
uptime :-)
I've done more digging. I captured tcpdumps of the entire SPEC run, on
all machines. I added lots of extra debugging logs to the client code,
I ran 'netstat -tn' every 10 seconds on all machines for the duration
of the test. Oh yes, and the webserver logs.
Here is what I've found...
Debugging logfile
-
The client creates a socket, binds a port to it and connects to the
webserver. It write()s a HTTP GET request, and read()s a file back. So
far so good. Without closing the socket, another request is sent and
another file is received (on keepalives, there are a random number of
HTTP requests performed - on average, 10). Now here is where it gets
interesting... still without closing the socket, write() another HTTP
request and go to read() the file... the read() sits there and this
child 

Re: asm/resource.h

[Peter Samuelson]

[Jeff Merkey]
> Is this what is causing the lockup problems on 2.4.0-pre-10 with
> PPro, or something else.  Looks like something else.

Yeah, it does, doesn't it.  If this particular patch cured a
kernel-side lockup I would be very surprised.  Because the only effect
this patch is *supposed* to have is the visibility of certain kernel
header code when compiling userspace programs.

HPA, for what it's worth, which isn't much, I think your patch is
spot-on..

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

What's causing my kernel Oops

[David Won]

I posted a few of my oops here last week and received a few helpfull replys. 
I have modified my logging so my ksymoops should be more readable. It looksed 
to me that it was mostly esd and emu10k1 that were causing my greif. I have 
since tried recompiling esound from srs and grabbing the latest SB live 
drivers. I also tried it as a module and in the kernel. I'm running the atest 
kernel and patch, RH 7 and compiled using kgcc. 
One further question. Do I compile the modules with kgcc as well? I get the 
Oops either way but was curious none the less.
Thanks for any help.

Nov  1 14:09:33 phlegmish kernel: Unable to handle kernel paging request at 
virtual address 20c337ad
Nov  1 14:09:33 phlegmish kernel: c0143ab6
Nov  1 14:09:33 phlegmish kernel: *pde = 
Nov  1 14:09:33 phlegmish kernel: Oops: 0002
Nov  1 14:09:33 phlegmish kernel: CPU:0
Nov  1 14:09:33 phlegmish kernel: EIP:0010:[]
Nov  1 14:09:33 phlegmish kernel: EFLAGS: 00010206
Nov  1 14:09:33 phlegmish kernel: eax: c3377cd9   ebx: c78253a0   ecx: 
c78253a0   edx: 20c3377d
Nov  1 14:09:33 phlegmish kernel: esi:    edi: c58c9fa4   ebp: 
1000   esp: c58c9f5c
Nov  1 14:09:33 phlegmish kernel: ds: 0018   es: 0018   ss: 0018
Nov  1 14:09:33 phlegmish kernel: Process ps (pid: 1570, stackpage=c58c9000)
Nov  1 14:09:33 phlegmish kernel: Stack: c78253a0 c01443c4 c78253a0 c58c9f78 
c58c9f7c  c78253a0  
Nov  1 14:09:33 phlegmish kernel: c0134b73 c76536a0 40030f20 
1000 c78253a0 c58c8000 b6f8 
Nov  1 14:09:33 phlegmish kernel:40030f20 b790 c76536a0 c7f3c2a0 
0007 c012d0a7 c3544bc0 0008 
Nov  1 14:09:33 phlegmish kernel: Call Trace: [] [] 
[] [] [] 
Nov  1 14:09:33 phlegmish kernel: Code: ff 42 30 8b 44 24 10 89 10 8b 81 f8 
00 00 00 8b 58 08 85 db 

>>EIP; c0143ab6<=

Trace; c01443c4 
Trace; c0134b73 
Trace; c012d0a7 
Trace; c010a407 
Trace; c010002b 
Code;  c0143ab6 
 <_EIP>:
Code;  c0143ab6<=
   0:   ff 42 30  incl   0x30(%edx)   <=
Code;  c0143ab9 
   3:   8b 44 24 10   mov0x10(%esp,1),%eax
Code;  c0143abd 
   7:   89 10 mov%edx,(%eax)
Code;  c0143abf 
   9:   8b 81 f8 00 00 00 mov0xf8(%ecx),%eax
Code;  c0143ac5 
   f:   8b 58 08  mov0x8(%eax),%ebx
Code;  c0143ac8 
  12:   85 db test   %ebx,%ebx

Nov  1 14:09:40 phlegmish kernel: Unable to handle kernel paging request at 
virtual address d9d9ffcf
Nov  1 14:09:40 phlegmish kernel: c012d006
Nov  1 14:09:40 phlegmish kernel: *pde = 
Nov  1 14:09:40 phlegmish kernel: Oops: 
Nov  1 14:09:40 phlegmish kernel: CPU:0
Nov  1 14:09:40 phlegmish kernel: EIP:0010:[]
Nov  1 14:09:40 phlegmish kernel: EFLAGS: 00210286
Nov  1 14:09:40 phlegmish kernel: eax: d9d9ffbb   ebx: d9d9ffbb   ecx: 
d9d9ffbb   edx: 0400
Nov  1 14:09:41 phlegmish kernel: esi:    edi: c32acc40   ebp: 
0001   esp: c007bee8
Nov  1 14:09:41 phlegmish kernel: ds: 0018   es: 0018   ss: 0018
Nov  1 14:09:41 phlegmish kernel: Process bash (pid: 1395, stackpage=c007b000)
Nov  1 14:09:41 phlegmish kernel: Stack: 0007  c0118c0a d9d9ffbb 
c32acc40 c31903e0 c007a000 0001 
Nov  1 14:09:41 phlegmish kernel:c007bf40 c011920a c32acc40 0001 
c007a000 0001 c010a29c 0001 
Nov  1 14:09:41 phlegmish kernel:c007a000  0001 b6d0 
c007bfc4 c007a550 0001  
Nov  1 14:09:41 phlegmish kernel: Call Trace: [] [] 
[] [] [] [] [] 
Nov  1 14:09:41 phlegmish kernel:[] [] 
Nov  1 14:09:41 phlegmish kernel: Code: 8b 43 14 85 c0 75 13 68 82 4f 22 c0 
e8 b5 9c fe ff 31 c0 83 

>>EIP; c012d006<=

Trace; c0118c0a 
Trace; d9d9ffbb 
Trace; c010a29c 
Trace; c885d100 <[bttv].bss.end+2001/14f61>
Trace;  
Trace; c010994e 
Trace; c010a450 
Code;  c012d006 
 <_EIP>:
Code;  c012d006 http://www.tux.org/lkml/

Re: [PATCH] x86 boot time check for cpu features

[davej]

On Fri, 3 Nov 2000, Brian Gerst wrote:

> > That bug fix is for the earlier Cyrix 6x86 if I'm not mistaken.
> > The MII is a different monster.
> According to the docs on VIA's site, the MII's cpuid can still be turned
> off, but it is on by default at reset.  I wouldn't trust the BIOS to not
> screw it up.

Err, what? If it's on by default...
A old BIOS that doesn't know about it won't switch it off.
A BIOS that does know about it will leave it (or maybe offer an option to
 disable it)

If neither of the above are true (Ie, a BIOS bug) and it's switched off
by the time Linux boots, I think we'd have heard about it by now, as MII
users would notice a lack of features.

regards,

Dave.

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

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

Locking problem in autofs4_expire(), 2.4.0-test10

[Nigel Gamble]

dput() is called with dcache_lock already held, resulting in deadlock.

Here is a suggested fix:

= expire.c 1.3 vs edited =
--- 1.3/linux/fs/autofs4/expire.c   Tue Oct 31 15:14:06 2000
+++ edited/expire.c Fri Nov  3 17:47:47 2000
@@ -223,8 +223,10 @@
mntput(p);
return dentry;
}
+   spin_unlock(_lock);
dput(d);
mntput(p);
+   spin_lock(_lock);
}
spin_unlock(_lock);

Nigel Gamble
MontaVista Software

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

Re: [PATCH] x86 boot time check for cpu features

[Brian Gerst]

[EMAIL PROTECTED] wrote:
> 
> Brian Gerst wrote...
> >> I believe the MII always has CPUID enabled. It was the older Cyrixes
> >> that did not. DaveJ is the guru..
> > Well, according to comments in bugs.h, some broken BIOSes disable cpuid.
> 
> That bug fix is for the earlier Cyrix 6x86 if I'm not mistaken.
> The MII is a different monster.

According to the docs on VIA's site, the MII's cpuid can still be turned
off, but it is on by default at reset.  I wouldn't trust the BIOS to not
screw it up.

--

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

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Keith Owens]

On Fri, 3 Nov 2000 17:10:52 -0800 (PST), 
James Simmons <[EMAIL PROTECTED]> wrote:
>
>>  * VGA Console can cause SMP deadlock when doing printk {CRITICAL}
>>(Keith Owens)
>
>Still not fixed :-( Here is the patch again. Keith give it a try and tell
>me if it solves your problems.

The patch looks OK to me.  I worked around my original problem (screen
deadlock in kdb) by skipping the cli()/restore_flags() when kdb is
active, kdb guarantees that only one cpu at a time is doing any work.

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

Re: [BUG?] two swapping processes freeze 2.4.0-test10 (but not 2.2.18pre19)

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you 
wrote:
> I simultaneously run "top d1" and two of the test computations.  All is
> well (top updates smoothly) until physical RAM is exhausted.  However, as
> soon as swap is touched, then top freezes and does not update.  In this
> state, I can switch virtual consoles but not login to a new one; the
> machine is pingable but does not respond to ssh.  Once swap is exhausted,
> the OOM killer kicks in and kills one of the test computations; then all
> is well and everything works as expected.

Yes, i described the same behaviour. Rick answered, that the swap out
situation is stopping other processes, since the out of free memory
situation will also page out other active processes' pages.

I suggested a fix to actually start to page out only a own process pages if
the system is that short that it starts to page out very recently used
pages.

this will lead to the efect, that as long as there are unused pages on the
system one growing process can page out other pages "idle" pages. But as
soon as the growing process can only page out other processes (which will in
turn page in their own pages, ...) we should chnage page out strategy and
only page out the oldest pages of the growing process. Therefore the swap
penalty is fully on the growing process.

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

Re: 2.4.0-test10 Sluggish After Load

[Peter Samuelson]

[matthew]
> ls /proc > killscript
> added "kill -9" to the beginning and "\" to the end of each line,
> ran it as the database user.  It worked pretty well.

Sounds like a lot of trouble.

  su {oracle} -c 'kill -9 -1'

Or is there some reason that wouldn't have worked in your case?

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

Re: SETFPXREGS fix

[Andrea Arcangeli]

On Sat, Nov 04, 2000 at 12:13:33PM +1100, Gareth Hughes wrote:
> Yes, we can certainly mask out the mxcsr value in both cases.  I just
  ^^^
s/can/must/

> think this makes the code a lot simpler and cleaner as a result - three

I agree about the three vs one copy issue. Anyways my first priority was that
the the code was safe, and the previous one was completly safe too (ok, I admit
I had to check out the asm generated before trusting it 8).

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

Re: 2.2.18pre18: many calls to kwhich

[Peter Samuelson]

[TenThumbs]
> I noticed that kwhich is called a lot:
> 
> make oldconfig:10
> make dep:  65
> make bzImage modules: 142

Yes indeed, I suggested the ':=' when kwhich first went in, for this
reason.  I suspect my mail was either ignored or overlooked.

That whole raft of variables uses '=' instead of ':=' and I've
occasionally wondered if this was intentional.  Possibly so, because
arch/{mips,m68k}/Makefile both set CROSS_COMPILE, which wouldn't work
if the toplevel used ':='.

I don't like it, though.  I think the user should be assumed to either
have a standard toolchain installed, in which case gcc and binutils
should be in the path under standard names --- or the user should know
enough to specify ARCH= and CROSS_COMPILE= on the compile line.


Alan: to avoid the 'CROSS_COMPILE defined too early' problem in the
stable series, I suggest the following, which will at least prevent the
kwhich script from being execed 200 times as reported.

Peter

--- 2.2.18pre19/Makefile~   Fri Nov  3 19:20:31 2000
+++ 2.2.18pre19/MakefileFri Nov  3 19:26:08 2000
@@ -28,8 +28,8 @@
 #  kgcc for Conectiva and Red Hat 7
 #  otherwise 'cc'
 #
-CC =$(shell if [ -n "$(CROSS_COMPILE)" ]; then echo $(CROSS_COMPILE)gcc; else \
-   $(CONFIG_SHELL) scripts/kwhich gcc272 2>/dev/null || $(CONFIG_SHELL) 
scripts/kwhich kgcc 2>/dev/null || echo cc; fi) \
+FOUNDCC := $(shell $(CONFIG_SHELL) scripts/kwhich gcc272 kgcc cc 2>/dev/null)
+CC =$(shell if [ -n "$(CROSS_COMPILE)" ]; then echo $(CROSS_COMPILE)gcc; else 
+echo $(FOUNDCC); fi) \
-D__KERNEL__ -I$(HPATH)
 CPP=$(CC) -E
 AR =$(CROSS_COMPILE)ar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Jeff Garzik]

David Ford wrote:
> The odd part is that it used to work "way back when".  Was this just a fluke?

That may have been back in the legacy days.  Ejecting ne2k should be ok
as long as you are using ne2k-pci or pcnet_cs.  Eject serial looks like
bad news unless you are using serial_cs (which is impossible at the
moment, AFAIK).

-- 
Jeff Garzik | Dinner is ready when
Building 1024   | the smoke alarm goes off.
MandrakeSoft|   -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Jeff Garzik]

Alan Cox wrote:
> 
> > > Not unless it was fixed in test10 release.  I have a PC LinkSys dual 10/100 and
> > > 56K card that will kill the machine if you physically pull it out no matter what
> > > cardctl/module steps are taken.
> > >
> > > It uses the ne2k and serial drivers.
> >
> > Part of that might be that serial doesn't support hotplug without
> > patching.
> 
> Linksys rings a bell with an outstandng 2.2 lockup on pcmcia. I think this might
> be a driver bug ?

On 2.2.x, possibly.

On 2.4.x:  1) insert CardBus serial or modem card, that reports itself
as PCI_CLASS_COMMUNICATION_SERIAL.  2) modprobe serial, it sees and
registers the PCI serial port.  3) eject card, which serial.c doesn't
presently notice.  ...

Jeff


-- 
Jeff Garzik | Dinner is ready when
Building 1024   | the smoke alarm goes off.
MandrakeSoft|   -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: SETFPXREGS fix

[Gareth Hughes]

Andrea Arcangeli wrote:
> 
> On Sat, Nov 04, 2000 at 10:50:00AM +1100, Gareth Hughes wrote:
> >   if ( HAVE_FXSR ) {
> >   if ( __copy_from_user( >thread.i387.fxsave, (void *)buf,
> >   sizeof(struct user_fxsr_struct) ) )
> >   return -EFAULT;
> >   /* bit 6 and 31-16 must be zero for security reasons */
> >   tsk->thread.i387.fxsave.mxcsr &= 0xffbf;
> >   return 0;
> >   }
> 
> The above doesn't fix the security problem. Put the last byte of the userspace
> structure on an unmapped page and it will return -EFAULT lefting the invalid
> mxcsr value that will corrupt the FPU again.
> 
> The right version of the above is just in linux mailbox.
> 
> The reason I did it more complex at first is because I wanted to go safe,
> I wasn't sure if somebody could SIGCONT the traced task while we was copying
> the data so introducing a race where it was still possible to exploit
> the bug; but as Linus pointed out to me the loop in do_signal prevents that, so
> we can do only one large copy and then fixup (fixing up also in the -EFAULT
> case of course).

Yes, we can certainly mask out the mxcsr value in both cases.  I just
think this makes the code a lot simpler and cleaner as a result - three
partial copies seems over the top.

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

Re: SETFPXREGS fix

[Andrea Arcangeli]

On Sat, Nov 04, 2000 at 10:50:00AM +1100, Gareth Hughes wrote:
>   if ( HAVE_FXSR ) {
>   if ( __copy_from_user( >thread.i387.fxsave, (void *)buf,
>   sizeof(struct user_fxsr_struct) ) )
>   return -EFAULT;
>   /* bit 6 and 31-16 must be zero for security reasons */
>   tsk->thread.i387.fxsave.mxcsr &= 0xffbf;
>   return 0;
>   }

The above doesn't fix the security problem. Put the last byte of the userspace
structure on an unmapped page and it will return -EFAULT lefting the invalid
mxcsr value that will corrupt the FPU again.

The right version of the above is just in linux mailbox.

The reason I did it more complex at first is because I wanted to go safe,
I wasn't sure if somebody could SIGCONT the traced task while we was copying
the data so introducing a race where it was still possible to exploit
the bug; but as Linus pointed out to me the loop in do_signal prevents that, so
we can do only one large copy and then fixup (fixing up also in the -EFAULT
case of course).

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

Re: linux-2.4.0-test9

[Jeff Garzik]

"Richard B. Johnson" wrote:
> I have, again, tried to use a new kernel. It is linux-2.4.0-test9
> Apparently a newer version was just put up while downloading this
> one. This is possible because it took a day to download it );

If you could download patch-2.4.0-test10, and try out test10-final, that
would be awesome...


> (3)  With the new kernel, I can't access screen memory anymore. When
> testing software drivers for hardware that I don't have, I usually use
> the screen-regen buffer to emulate the shared memory window.
> 
> Here is a snippet of code:
> 
> //info->mem = 0xb8000 what they actually are
> //info->mem_len = 0x4000
> 
> if((info->vxi_iomem = ioremap(info->mem, info->mem_len)) == NULL)
> {
> printk(KERN_ALERT "%s: Can't allocate shared memory\n", devname);
> (void)unregister_chrdev(info->major, info->dev);
> kfree(info->tmp_buf);
> kfree(info);
> return -ENOMEM;
> }
> info->vxi_base   = (UNIV *) bus_to_virt(UL info->vxi_iomem);
> ||
> This pointer should point to the beginning of the screen buffer.
> It always has before.
> 
> When accessing this from a module, I get;
> Unable to handle kernel paging requist at virtual address 800b8304.

bug 1) ioremap returns a cookie, not a bus address.  therefore, calling
ioremap output to bus_to_virt is incorrect.

bug 2) what are you doing with vxi_base?  I don't have the rest of your
code here, but I'm willing to bet that you are directly de-referencing
memory, instead of using {read,write}[bwl] / memcpy_{to,from}io.  Read
linux/Documentation/IO-mapping.txt for more info.


> (4) More name-space polution. Somebody added another macro called
> get_page(). When, if ever, will we start using the good-old
> convention of defining macros in upper-case?
> 
> The name-space polution has really gotten out-of-hand. You
> can't write code using ordinary symbol names anymore. You
> need to make variables have names like:
> 
> int LoopCounterForOutSideLoop;
> char *UserInputAndOutputBufferForWednesday;
> 
> This is NotGood(tm)

I guess it should probably have been named "page_get"?  I looked through
'nm vmlinux' output at the public symbols, and there are definitely a
ton of them.

Though it is definitely C convention that macros are in all uppercase
(gcc is good about this), the kernel has never really been good about
that...

Jeff


-- 
Jeff Garzik | Dinner is ready when
Building 1024   | the smoke alarm goes off.
MandrakeSoft|   -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] x86 boot time check for cpu features

[davej]

Brian Gerst wrote...
>> I believe the MII always has CPUID enabled. It was the older Cyrixes
>> that did not. DaveJ is the guru..
> Well, according to comments in bugs.h, some broken BIOSes disable cpuid.

That bug fix is for the earlier Cyrix 6x86 if I'm not mistaken.
The MII is a different monster.

d.

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

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

Re: [PATCH] x86 boot time check for cpu features

[davej]

Alan Cox wrote..

> > Hmm, after a bit more investigation, it appears that the Cyrix MII
> > processors support cmov instructions, even though we currently don't
> > compile for that processor with -march=i686.  Please ignore this patch
> > until I can come up with something better.

> I believe the MII always has CPUID enabled. It was the older Cyrixes
> that did not.

That was my understanding also.

d.

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

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

Re: Value of TASK_UNMAPPED_SIZE on 2.4

[Andrea Arcangeli]

On Sat, Nov 04, 2000 at 01:09:42AM +, Julian Anastasov wrote:
>   Something like the attached old patch for 2.2. It is very

It's not ok for 64bit archs.

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

Re: [PATCH] x86 boot time check for cpu features

[Brian Gerst]

Alan Cox wrote:
> 
> > Alan Cox wrote:
> > > Q:  are any of the things you test present in processors only after we
> > > do magic 'cpuid' enable invocations ?
> >
> > Hmm, after a bit more investigation, it appears that the Cyrix MII
> > processors support cmov instructions, even though we currently don't
> > compile for that processor with -march=i686.  Please ignore this patch
> > until I can come up with something better.
> 
> I believe the MII always has CPUID enabled. It was the older Cyrixes that did
> not. DaveJ is the guru..

Well, according to comments in bugs.h, some broken BIOSes disable cpuid.

--

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

Re: [PATCH] x86 boot time check for cpu features

[Alan Cox]

> Alan Cox wrote:
> > Q:  are any of the things you test present in processors only after we
> > do magic 'cpuid' enable invocations ?
> 
> Hmm, after a bit more investigation, it appears that the Cyrix MII
> processors support cmov instructions, even though we currently don't
> compile for that processor with -march=i686.  Please ignore this patch
> until I can come up with something better.

I believe the MII always has CPUID enabled. It was the older Cyrixes that did
not. DaveJ is the guru..

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

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Alan Cox]

> } Andi, neither you nor me nor Alan nor anyone are able to audit
> } all this unnevessarily overcomplicated code. It was buggy, is buggy
> } and will be buggy. It is inavoidable, as soon as you have hundreds
> } of drivers.
> } 
> If they are buggy and unsupported, why aren't they being expunged from
> the main source tree and placed into a ``contrib'' directory or something
> for people who may want those drivers?

Because by 2.4.5 it will be working ;). Pain power 8)

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

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Alan Cox]

> > Not unless it was fixed in test10 release.  I have a PC LinkSys dual 10/100 and
> > 56K card that will kill the machine if you physically pull it out no matter what
> > cardctl/module steps are taken.
> > 
> > It uses the ne2k and serial drivers.
> 
> Part of that might be that serial doesn't support hotplug without
> patching.

Linksys rings a bell with an outstandng 2.2 lockup on pcmcia. I think this might
be a driver bug ?

> 

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

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Jeff Garzik]

Andi Kleen wrote:
> de4x5 is stable, but tends to perform badly under load, mostly because
> it doesn't use rx_copybreak and overflows standard socket buffers with its
> always MTU sized skbuffs.

One of the reasons that de4x5 isn't gone already is that I get reports
that de4x5 performs better than the tulip driver for their card.

Jeff


-- 
Jeff Garzik | Dinner is ready when
Building 1024   | the smoke alarm goes off.
MandrakeSoft|   -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: SETFPXREGS fix

[Gareth Hughes]

Andrea Arcangeli wrote:
> 
> --- 2.4.0-test10/arch/i386/kernel/i387.cThu Nov  2 20:58:58 2000
> +++ PIII/arch/i386/kernel/i387.cThu Nov  2 18:44:36 2000
> @@ -440,8 +436,25 @@
>  int set_fpxregs( struct task_struct *tsk, struct user_fxsr_struct *buf )
>  {
> if ( HAVE_FXSR ) {
> -   __copy_from_user( >thread.i387.fxsave, (void *)buf,
> - sizeof(struct user_fxsr_struct) );
> +   long mxcsr;
> +
> +   if (__copy_from_user(>thread.i387.fxsave, (void *)buf,
> +(long) &((struct user_fxsr_struct *)
> + 0)->mxcsr))
> +   return -EFAULT;
> +   if (__get_user(mxcsr,
> +  &((struct user_fxsr_struct *) buf)->mxcsr))
> +   return -EFAULT;
> +   /* bit 6 and 31-16 must be zero for security reasons */
> +   mxcsr &= 0xffbf;
> +   tsk->thread.i387.fxsave.mxcsr = mxcsr;
> +   if (__copy_from_user(>thread.i387.fxsave.reserved,
> +&((struct user_fxsr_struct *)
> +  buf)->reserved,
> +sizeof(struct user_fxsr_struct)-
> +(long) &((struct user_fxsr_struct *)
> + 0)->reserved))
> +   return -EFAULT;
> return 0;
> } else {
> return -EIO;

Why do all three copies?  Why not copy it once and mask out the mxcsr
value when it's in tsk->thread.i387.fxsave.mxcsr?  Seems to be an overly
complex fix.

if ( HAVE_FXSR ) {
if ( __copy_from_user( >thread.i387.fxsave, (void *)buf,
sizeof(struct user_fxsr_struct) ) )
return -EFAULT;
/* bit 6 and 31-16 must be zero for security reasons */
tsk->thread.i387.fxsave.mxcsr &= 0xffbf;
return 0;
}

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

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Andi Kleen]

On Fri, Nov 03, 2000 at 05:30:26PM -0500, Jeff Garzik wrote:
> Bill Wendling wrote:
> > 
> > Also sprach [EMAIL PROTECTED]:
> > } > de4x5 is probably also buggy in regard to this.
> > }
> > } de4x5 is hopeless. I added nice comment in softnet to it.
> > } Unfortunately it was lost. 8)
> > }
> > } Andi, neither you nor me nor Alan nor anyone are able to audit
> > } all this unnevessarily overcomplicated code. It was buggy, is buggy
> > } and will be buggy. It is inavoidable, as soon as you have hundreds
> > } of drivers.
> > }
> > If they are buggy and unsupported, why aren't they being expunged from
> > the main source tree and placed into a ``contrib'' directory or something
> > for people who may want those drivers?
> 
> de4x5 is stable.  Its hopeless to add stuff to it, or try to any fix of
> the (IMHO small) issues, but its fine as is.  For maintenance issues,
> its PCI support will be eliminated in 2.5.x because it is a duplicate of
> support in the tulip driver.

de4x5 is stable, but tends to perform badly under load, mostly because
it doesn't use rx_copybreak and overflows standard socket buffers with its
always MTU sized skbuffs.


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

Re: working userspace nfs v3 for linux?

[Horst von Brand]

Michael Rothwell <[EMAIL PROTECTED]> said:
> Andi Kleen wrote:
> > On Wed, Nov 01, 2000 at 02:59:05PM -0500, Michael Rothwell wrote:
> > > Is there a working userspace nfs v3 server for linux?

> > Yes, just install user mode linux and use its v3 knfsd server.

> Does anyone have any suggestions that aren't jokes, don't require a 2.4
> kernel and will work?

2.2.18pre18 in-kernel NFSv3 (client and server) appears to work against
Solaris 2.6 (light testing with nfs-utils-2.1.1)
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] x86 boot time check for cpu features

[Brian Gerst]

Alan Cox wrote:
> Q:  are any of the things you test present in processors only after we
> do magic 'cpuid' enable invocations ?

Hmm, after a bit more investigation, it appears that the Cyrix MII
processors support cmov instructions, even though we currently don't
compile for that processor with -march=i686.  Please ignore this patch
until I can come up with something better.

-- 

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

linux-2.4.0-test9

[Richard B. Johnson]

I have, again, tried to use a new kernel. It is linux-2.4.0-test9
Apparently a newer version was just put up while downloading this
one. This is possible because it took a day to download it );

The following problems exist:

(1) I have SCSI modules that have to be installed upon boot
from initrd. Insmod failed with "Can't find the kernel version that
this module was compiled with..." Yes, I have the latest and greatest
modutils, downloaded and installed today. Also `insmod -f` doesn't
work (not a kernel problem, yes, I know).

The only fix I could come up with was to remove EXTRAVERSION=test9 in
the top-level Makefile (actually set it to nothing), then recompile
the whole kernel. This problem will get others, I am sure.


(2) Samba fails to start (seg-faults). I'll look into this later.
Maybe I have to re-compile it (I shouldn't, it uses standard
socket interfaces).

(3)  With the new kernel, I can't access screen memory anymore. When
testing software drivers for hardware that I don't have, I usually use
the screen-regen buffer to emulate the shared memory window.

Here is a snippet of code: 

//info->mem = 0xb8000 what they actually are
//info->mem_len = 0x4000

if((info->vxi_iomem = ioremap(info->mem, info->mem_len)) == NULL)
{
printk(KERN_ALERT "%s: Can't allocate shared memory\n", devname);
(void)unregister_chrdev(info->major, info->dev);
kfree(info->tmp_buf);
kfree(info);
return -ENOMEM;
}
info->vxi_base   = (UNIV *) bus_to_virt(UL info->vxi_iomem);
||
This pointer should point to the beginning of the screen buffer.
It always has before.

When accessing this from a module, I get;
Unable to handle kernel paging requist at virtual address 800b8304.

Access fails at 0x304 (772 d) bytes into the page.

Perhaps, the bus_to_virt() macro or something else has changed??
I tried to use the result of ioremap() directly, but just before
the seg-fault, the kernel message warned that it was not a correct
address.

(4) More name-space polution. Somebody added another macro called
get_page(). When, if ever, will we start using the good-old
convention of defining macros in upper-case?

The name-space polution has really gotten out-of-hand. You
can't write code using ordinary symbol names anymore. You
need to make variables have names like:

int LoopCounterForOutSideLoop;
char *UserInputAndOutputBufferForWednesday;

This is NotGood(tm)

(5) More stuff added to 'struct file_operations', a new member
at the beginning, forcing obsolescence of previous
versions -- and now different for non-module drivers.
Fortunately a macro was defined (in upper-case!), called
THIS_MODULE, so modifying my current 11 drivers wasn't
too bad.


Presently this kernel is running here, fingers crossed. I need to
resolve the screen access problem. Anybody got any hints?


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

linux support for TCP/IP Task Offload ....

[sunol_handa]

Hi all,

Does Linux have any TCP/IP Task Offload support ? 

If a network adapter can offload some of the TCP/IP tasks, is there a
support from Linux for such activity ?

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

2.4.0test10 not booting on 486 laptop

[FORT David]

When 2.4.0test10 bootup, i got the "Loading" message, then "Uncompressing

kernel...", i can see quickly "Booting.", and it does it: it reboots.

My last kernel was 2.4.0test7, and was not exibiting the problem. I've

recheck my .config, but it's the same as for 2.4.0test7.

My gcc:

[root@Djinn linux]# gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
[root@Djinn linux]#

according to Changes may be good.

The laptop is a 486dx2@40 compaq contura 400cx, two thing that may be

important: it has early cpuid support(many changes occured in this

area recently), and it doesn't have any PCI bus(but kernel is compiled

with it, in order to have Card drivers).

--
%-%
% FORT David, %
% 7 avenue de la morvandière   0240726275 %
% 44470 Thouare, France[EMAIL PROTECTED] %
% ICU:78064991   AIM: enlighted popo [EMAIL PROTECTED] %
%--LINUX-HTTPD-PIOGENE%
%  -datamining <-/|   .~. %
%  -networking/flashed PHP3 coming soon   |   /V\L  I  N  U  X%
%  -opensource|  // \\ >Fear the Penguin< %
%  -GNOME/enlightenment/GIMP  | /(   )\   %
%   feel enlighted|  ^^-^^%
%   http://ibonneace.dnsalias.org/ when connected %
%-%



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

Re: Value of TASK_UNMAPPED_SIZE on 2.4

[Josue Emmanuel Amaro]

Andrea,

We will give it a try.

How difficult would it be to move that patch to 2.4?

It would be great if it could be a kernel configuration time option.

Regards,

Andrea Arcangeli wrote:

> On Fri, Nov 03, 2000 at 09:27:07PM +0100, Kai Harrekilde-Petersen wrote:
> > Is this available as a patch, or preferably as a compilation option to
>
> They're available here:
>
> 
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.14/bigmem-large-mapping-1.bz2
> 
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.14/bigmem-large-task-1.bz2
>
> But they're against 2.2.x + bigmem. The first one is still valid (and it's
> similar to the one discussed here). The second one doesn't apply to 2.4.x
> and both vmlinux.lds and PAGE_OFFSET should be changed that way to
> make it to work there.
>
> Andrea
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

--
===
  Josue Emmanuel Amaro [EMAIL PROTECTED]
  Linux Products Manager   Phone:   650.506.1239
  Intel and Linux Technologies Group   Fax: 650.413.0167
===



begin:vcard 
n:Amaro;Josue Emmanuel
tel;cell:650-245-5131
tel;fax:650-413-0167
tel;work:650-506-1239
x-mozilla-html:FALSE
url:http://www.oracle.com
org:Intel and Linux Technologies
version:2.1
email;internet:[EMAIL PROTECTED]
title:Sr.Product Manager - Linux
adr;quoted-printable:;;500 Oracle Parkway=0D=0AMS1ip4;Redwood Shores;CA;94065;United States
fn:Josue Emmanuel Amaro
end:vcard

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Jeff Garzik]

Bill Wendling wrote:
> 
> Also sprach [EMAIL PROTECTED]:
> } > de4x5 is probably also buggy in regard to this.
> }
> } de4x5 is hopeless. I added nice comment in softnet to it.
> } Unfortunately it was lost. 8)
> }
> } Andi, neither you nor me nor Alan nor anyone are able to audit
> } all this unnevessarily overcomplicated code. It was buggy, is buggy
> } and will be buggy. It is inavoidable, as soon as you have hundreds
> } of drivers.
> }
> If they are buggy and unsupported, why aren't they being expunged from
> the main source tree and placed into a ``contrib'' directory or something
> for people who may want those drivers?

de4x5 is stable.  Its hopeless to add stuff to it, or try to any fix of
the (IMHO small) issues, but its fine as is.  For maintenance issues,
its PCI support will be eliminated in 2.5.x because it is a duplicate of
support in the tulip driver.

Jeff


-- 
Jeff Garzik | Dinner is ready when
Building 1024   | the smoke alarm goes off.
MandrakeSoft|   -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Compiling 2.4.0-test10 on PPC

[Cort Dougan]

} 2.4.0-test10 doesn't compile correctly on a mac.
} Only 2 changes are necessary to make it work.
} Or are there any bigger problems with the ppc arch?
} 
} the 2 changes:
} in ./include/asm-ppc/param.h the following lines have to be added
} right before the last #endif:
} 
} #ifdef __KERNEL__
} # define CLOCKS_PER_SEC 100 /* frequency at which times() counts */
} #endif
} 
} in ./drivers/input/keybdev.c the second #elif (CONFIG_ADB) or
} something like that should be changed to #else or the correct #elif
} statement.
} 
} I don't know who's the maintainer of the ppc arch - i think ibm has
} taken it over or am i wrong about that?

No, that's not right :)

Grab the latest ppc tree from www.fsmlabs.com/linuxppcbk.html.  The fixes
are there and the main kernel.org tree will be brought up to speed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: blk-8 oopses at boot (was: blk-7 fails to boot)

[David Mansfield]

> On Fri, Nov 03 2000, David Mansfield wrote:
> > Hi Jens.
> >
> > I've tried your blk-8 patch and it oopses during boot.  I only hand
> > copied the stack trace, and ran it through ksymoops:
> >
 >
> > I'm going to try taking MSDOS out of my .config to try to work around
> > this.  I'll keep you posted as to my progress.
>
> Thanks, I think this is a generic msdos problem though. If it still
> oopses without blk-8, could you send the complete oops please?

Actually, it has nothing to do with MSDOS fs, per-se.  I misread the
trace. In fact, it's just an MSDOS style *partition table*, i.e. normal
Linux on a PC partition table.

I have here the bootup messages of 2.4.0-test10 + blk-8, along with a
ksymoops of the oops, and a gdb disassemble of __wait_on_buffer:

Linux version 2.4.0-test10 (kernel@mercury) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #18 Fri Nov 3 11:01:28 EST 2000
BIOS-provided physical RAM map:
 BIOS-e820: 0009fc00 @  (usable)
 BIOS-e820: 0400 @ 0009fc00 (reserved)
 BIOS-e820: 0001 @ 000f (reserved)
 BIOS-e820: 0001 @  (reserved)
 BIOS-e820: 0fef @ 0010 (usable)
 BIOS-e820: d000 @ 0fff3000 (ACPI data)
 BIOS-e820: 3000 @ 0fff (ACPI NVS)
On node 0 totalpages: 65536
zone(0): 4096 pages.
zone(1): 61440 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=linux ro root=812 mem=256m
console=ttyS0,115200n8
Initializing CPU#0
Detected 698.665 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1392.64 BogoMIPS
Memory: 255508k/262144k available (1360k kernel code, 6248k reserved,
99k data, 196k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: L1 I Cache: 64K  L1 D Cache: 64K (64 bytes/line)
CPU: L2 Cache: 512K
CPU: AMD-K7(tm) Processor stepping 02
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED])
PCI: PCI BIOS revision 2.10 entry at 0xfb460, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.13)
ACPI: "AWARD" found at 0x000f6340
ACPI: unreserved table memory @ 0x0fff3000!
ACPI: missing RSDT at 0x0fff3000
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
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
AMD7409: IDE controller on PCI bus 00 dev 39
AMD7409: chipset revision 3
AMD7409: not 100% native mode: will probe irqs later
AMD7409: disabling single-word DMA support (revision < C4)
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
hda: CREATIVE CD5230E, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: ATAPI 52X CD-ROM drive, 128kB Cache, DMA
Uniform CD-ROM driver Revision: 3.11
LVM version 0.8final  by Heinz Mauelshagen  (15/02/2000)
lvm -- Driver successfully initialized
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
SCSI subsystem driver Revision: 1.00
(scsi0)  found at PCI 0/11/0
(scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 392 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
   
(scsi0:0:0:0) Synchronous at 80.0 Mbyte/sec, offset 15.
  Vendor: SEAGATE   Model: ST39102LW Rev: 0006
  Type:   Direct-Access  ANSI SCSI revision: 02
(scsi0:0:2:0) Synchronous at 80.0 Mbyte/sec, offset 31.
  Vendor: IBM   Model: DNES-318350W  Rev: SA30
  Type:   Direct-Access  ANSI SCSI revision: 03
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
Detected scsi disk sdb at scsi0, channel 0, id 2, lun 0
SCSI device sda: 17783240 512-byte hdwr sectors (9105 MB)
Partition check:
 sda:<1>Unable to handle kernel NULL pointer dereference at virtual
address 0010
 printing eip:
0010
*pde = 
Oops: 
CPU:0
EIP:0010:[<0010>]
EFLAGS: 00010202
eax: c15da9e4   ebx: c023c7ea   ecx: c1591800   edx: 0010
esi: c1582240   edi: c15fe000   ebp: c15ffe70   esp: c15ffe50
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, stackpage=c15ff000)
Stack: c01310e0 c1591800 0800  0800 c15da980 c1591800
c1582288 
   01234567 c15fe000 c158228c c158228c c0131f55 c1582240 c1582240
c014c88e 
   0800  0400 0800 c0259b04 

Re: non-gcc linux?

[D. Hugh Redelmeier]

| From: Jeff Garzik <[EMAIL PROTECTED]>
| Subject: Re: non-gcc linux?
| 
| "D. Hugh Redelmeier" wrote:
| > Being GCC-dependent is rather parochial.  Being GCC-version-dependent
| > is downright embarrassing.
| > 
| > Summary: spurious GCC-isms are a bad thing.
| 
| Summary:  You have no clue about kernel<->gcc interdependencies and
| issues.

Not a very informative summary.  It may be true, but you ought to
help the reader learn.  A pointer is welcome.

| > - use ISO C 89 when possible (without undue pain)
| > 
| > - use IOS C 99 when advantageous
| > 
| > - use GCCisms for the remainder of appropriate things BUT embed them
| >   in macros defined in header so that they can be systematically
| >   replaced.  Using these macros probably makes the code more readable.
| >   Use of any GCCism should probably be justified in commentary.
| > 
| > This would improve the code *and* make it more portable.
| 
| Why does this improve the code?

In any environment, there are things that accidentally work.  Porting
the code finds those accidents and forces you to make them
intentionally work.

For example, my compiler is intended to find questionable code.  It
finds lots of things that GCC doesn't (or didn't use to -- I haven't
checked recently).  A few years ago, I pushed Midnight Commander
through my compiler and fed a number of suggestions back to Miguel.

|  It gets slower and uglier and more
| difficult to maintain.

I never asked for slower.  If a GCCism is faster, in a way that
matters (and lots of manual optimizations are not worthwhile), then
that is a justification.  So my suggestion allows it.

Well-designed macros improve maintainability.  They make the code more
readable.  And macro expansion happens at compile time, not run time.

| Why does this make the code more portable?  gcc is already highly
| portable, and so it the kernel.  This too gains us nothing.

The word "portable" has several meanings.  Tim clearly would not be
doing this if Lineo didn't think that it would get the kernel
somewhere that GCC didn't go, or at least didn't go as well as some
other compiler.

In the C standard, "maximally portable" is a higher level of language
conformance.

When I use portable, I also mean "avoiding exploitation of arbitrary
characteristics of the particular environment".  This kind of
portability increases robustness in the face of change.
w
Even though the vast majority of LINUX systems run on the x86
architecture, don't you think that we've all been enriched by what has
been learned porting to SPARC, Power PC, 68k, Alpha, HPPA, 390, ARM,
etc.?

Similarly, we'd all benefit by the changes suggested by the experience
of porting the kernel to another compiler.

If you think that the kernel is welded to GCC, it really ought to be
called the GNU/LINUX kernel-and-C-compiler :-)

| Removing gcc-isms without a pragmatic reason -- and no, ISO C compliancy
| is not a pragmatic reason -- is silly, extra work for little or no
| value.

Why?  Conforming to a standard is a Good Thing.  The ISO process of
making a standard is normally more careful, far sighted, and inclusive
than the extensions a particular implementor puts in their compiler.
A standard is a contract between language implementors and users.  We
don't have such a contract with GCC.

There are many resources for C programmers that don't cover GCC
extensions.  For example, course, books, and the ISO Standard itself.
Oh, and other compilers.

As HPA alluded to, the GCC extensions are not the most exercised parts
of the compiler.  They are thus more likely to contain bugs.

Hugh Redelmeier
[EMAIL PROTECTED]  voice: +1 416 482-8253


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

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Bill Wendling]

Also sprach [EMAIL PROTECTED]:
} > de4x5 is probably also buggy in regard to this.
} 
} de4x5 is hopeless. I added nice comment in softnet to it.
} Unfortunately it was lost. 8)
} 
} Andi, neither you nor me nor Alan nor anyone are able to audit
} all this unnevessarily overcomplicated code. It was buggy, is buggy
} and will be buggy. It is inavoidable, as soon as you have hundreds
} of drivers.
} 
If they are buggy and unsupported, why aren't they being expunged from
the main source tree and placed into a ``contrib'' directory or something
for people who may want those drivers?

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

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[David Ford]

The odd part is that it used to work "way back when".  Was this just a fluke?

-d

Jeff Garzik wrote:

> > Not unless it was fixed in test10 release.  I have a PC LinkSys dual 10/100 and
> > 56K card that will kill the machine if you physically pull it out no matter what
> > cardctl/module steps are taken.
> >
> > It uses the ne2k and serial drivers.
>
> Part of that might be that serial doesn't support hotplug without
> patching.

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."




begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;-12480
fn:David Ford
end:vcard

Compiling 2.4.0-test10 on PPC

[Thomas Kotzian]

2.4.0-test10 doesn't compile correctly on a mac.
Only 2 changes are necessary to make it work.
Or are there any bigger problems with the ppc arch?

the 2 changes:
in ./include/asm-ppc/param.h the following lines have to be added
right before the last #endif:

#ifdef __KERNEL__
# define CLOCKS_PER_SEC 100 /* frequency at which times() counts */
#endif

in ./drivers/input/keybdev.c the second #elif (CONFIG_ADB) or
something like that should be changed to #else or the correct #elif
statement.

I don't know who's the maintainer of the ppc arch - i think ibm has
taken it over or am i wrong about that?

Thomas Kotzian

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

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Jeff Garzik]

Alan Cox wrote:
> >  * Check all devices use resources properly (Everyone now has to use
> >request_region and check the return since we no longer single
> >thread driver inits in all module cases. Also memory regions are
> >now requestable and a lot of old drivers dont know this yet. --
> >Alan Cox)
> 
> Folks have done most of the common drivers. So its not really a show stopper
> now just a 'clean up'

s/check_region/request_region/ is moving along, but there is still a
ways to go.  I agree with "folks have done most of the common drivers"

I have seen very few additions of request_mem_region, though.


> >  * Issue with notifiers that try to deregister themselves? (lnz;
> >notifier locking change by Garzik should backed out, according to
> >Jeff)
> 
> and according to Alan

Fixed for a couple versions now.


> >  * Spin doing ioctls on a down netdeice as it unloads == BOOM
> >(prumpf, Alan Cox) Possible other net driver SMP issues (andi
> >kleen)
> 
> Turns out to be safe according to Jeff and ANK

To avoid Andi confusing the issue :) ...

1) The first item listed does not exist

2) the second item listed exists -- many net drivers are not SMP.  They
are most of the way there, but there are still small races which exist
in some drivers.

Jeff



-- 
Jeff Garzik | Dinner is ready when
Building 1024   | the smoke alarm goes off.
MandrakeSoft|   -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land programmer...

[dean gaudet]

On Fri, 3 Nov 2000 [EMAIL PROTECTED] wrote:

> I don't mean this to sound like a rant.  It's just that I can't possibly
> ascertain why someone in their right mind would want any behaviour
> different than SA_RESTART.

study apache 1.3's child_main code, you'll see an example of EINTR in use.  
it's used to get out of accept() -- most specifically when the child needs
to die off (because the parent has determined that there's either too many
children, or because a shutdown/restart is occuring).

apache 1.3's BUFF code also uses EINTR for timeouts.

i eliminated signals in the 2.0 design... so it doesn't use EINTR any
more, but it restarts in userland because that's the most portable thing
to do.



On Fri, 3 Nov 2000 [EMAIL PROTECTED] wrote:

> After reading about SA_RESTART, ok.  However, couldn't those
> applications that require it enable this behaviour explicitly?

anyone sane writing modern applications will use sigaction().  signal() is
legacy.

-dean

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

Re: asm/resource.h

[Jeff V. Merkey]

hpa,

Is this what is causing the lockup problems on 2.4.0-pre-10 with PPro,
or something else.  Looks like something else.

Jeff

"H. Peter Anvin" wrote:
> 
> Hello friends,
> 
> Attached is a patch against 2.4.0-test10 that changes asm/resource.h to
> define RLIM_INFINITY insite the #ifdef __KERNEL__ on all architectures;
> previously, this was inconsistent between architecures.  This breaks
> compilation with -Werror at least on i386 since 
> includes , at least on glibc-2.1.2.
> 
> I have only been able to test this on i386 and glibc 2.1.2.  If there are
> any places where this change is *not* appropriate, now would be a good
> time to holler...
> 
> -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
> 
>   
> diff -ur linux-2.4.0-test10-orig/include/asm/resource.h 
>linux-2.4.0-test10/include/asm/resource.h
> --- linux-2.4.0-test10-orig/include/asm/resource.h  Fri Sep 22 14:21:19 2000
> +++ linux-2.4.0-test10/include/asm/resource.h   Fri Nov  3 13:11:12 2000
> @@ -19,13 +19,13 @@
> 
>  #define RLIM_NLIMITS   11
> 
> +#ifdef __KERNEL__
> +
>  /*
>   * SuS says limits have to be unsigned.
>   * Which makes a ton more sense anyway.
>   */
>  #define RLIM_INFINITY  (~0UL)
> -
> -#ifdef __KERNEL__
> 
>  #define INIT_RLIMITS   \
>  {  \
> diff -ur linux-2.4.0-test10-orig/include/asm-alpha/resource.h 
>linux-2.4.0-test10/include/asm-alpha/resource.h
> --- linux-2.4.0-test10-orig/include/asm-alpha/resource.hWed Sep 27 13:39:23 
>2000
> +++ linux-2.4.0-test10/include/asm-alpha/resource.h Fri Nov  3 13:11:30 2000
> @@ -19,14 +19,14 @@
> 
>  #define RLIM_NLIMITS   11
> 
> +#ifdef __KERNEL__
> +
>  /*
>   * SuS says limits have to be unsigned.  Fine, it's unsigned, but
>   * we retain the old value for compatibility, especially with DU.
>   * When you run into the 2^63 barrier, you call me.
>   */
>  #define RLIM_INFINITY  0x7ffful
> -
> -#ifdef __KERNEL__
> 
>  #define INIT_RLIMITS   \
>  {  \
> diff -ur linux-2.4.0-test10-orig/include/asm-i386/resource.h 
>linux-2.4.0-test10/include/asm-i386/resource.h
> --- linux-2.4.0-test10-orig/include/asm-i386/resource.h Fri Sep 22 14:21:19 2000
> +++ linux-2.4.0-test10/include/asm-i386/resource.h  Fri Nov  3 13:11:12 2000
> @@ -19,13 +19,13 @@
> 
>  #define RLIM_NLIMITS   11
> 
> +#ifdef __KERNEL__
> +
>  /*
>   * SuS says limits have to be unsigned.
>   * Which makes a ton more sense anyway.
>   */
>  #define RLIM_INFINITY  (~0UL)
> -
> -#ifdef __KERNEL__
> 
>  #define INIT_RLIMITS   \
>  {  \
> diff -ur linux-2.4.0-test10-orig/include/asm-ia64/resource.h 
>linux-2.4.0-test10/include/asm-ia64/resource.h
> --- linux-2.4.0-test10-orig/include/asm-ia64/resource.h Fri Sep 22 14:21:19 2000
> +++ linux-2.4.0-test10/include/asm-ia64/resource.h  Fri Nov  3 13:11:04 2000
> @@ -22,13 +22,13 @@
> 
>  #define RLIM_NLIMITS   11
> 
> +# ifdef __KERNEL__
> +
>  /*
>   * SuS says limits have to be unsigned.
>   * Which makes a ton more sense anyway.
>   */
>  #define RLIM_INFINITY  (~0UL)
> -
> -# ifdef __KERNEL__
> 
>  #define INIT_RLIMITS   \
>  {  \
> diff -ur linux-2.4.0-test10-orig/include/asm-m68k/resource.h 
>linux-2.4.0-test10/include/asm-m68k/resource.h
> --- linux-2.4.0-test10-orig/include/asm-m68k/resource.h Fri Sep 22 14:21:20 2000
> +++ linux-2.4.0-test10/include/asm-m68k/resource.h  Fri Nov  3 13:10:54 2000
> @@ -19,13 +19,13 @@
> 
>  #define RLIM_NLIMITS   11
> 
> +#ifdef __KERNEL__
> +
>  /*
>   * SuS says limits have to be unsigned.
>   * Which makes a ton more sense anyway.
>   */
>  #define RLIM_INFINITY  (~0UL)
> -
> -#ifdef __KERNEL__
> 
>  #define INIT_RLIMITS   \
>  {   \
> diff -ur linux-2.4.0-test10-orig/include/asm-mips/resource.h 
>linux-2.4.0-test10/include/asm-mips/resource.h
> --- linux-2.4.0-test10-orig/include/asm-mips/resource.h Fri Sep 22 14:21:20 2000
> +++ linux-2.4.0-test10/include/asm-mips/resource.h  Fri Nov  3 13:10:44 2000
> @@ -26,13 +26,13 @@
> 
>  #define RLIM_NLIMITS 11/* Number of limit flavors.  */
> 
> +#ifdef __KERNEL__
> +
>  /*
>   * SuS says limits have to be unsigned.
>   * Which makes a ton more sense anyway.
>   */
>  #define RLIM_INFINITY  0x7fffUL
> -
> -#ifdef __KERNEL__
> 
>  #define INIT_RLIMITS   \
>  {  \
> diff -ur linux-2.4.0-test10-orig/include/asm-mips64/resource.h 

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Jeff Garzik]

[EMAIL PROTECTED] wrote:
> 
> Hello!
> 
> > that does hardware register access without protecting against interrupts
> > or checking if the interface is up.
> 
> This issue is not that issue. It is separate issue and in fact
> it is private problem of driver and its author, what is safe,
> what is not safe.
> 
> F.e. I see no cathastrophe even if MII registers are accessed without
> any protections. Diag utilities do this from user space. 8)8)

It depends on the hardware...  For the ioctl-only case, you are
correct.  rtnl_lock protects us there.  But when the timer and ioctl
both call mdio_xxx, you need SMP protection, otherwise you corrupt the
multi-step MDIO read/write found in many drivers.

IMNSHO the timer routines found in net drivers should all be converted
to kernel threads.  There are too many limitations placed on you by
timers.


> > de4x5 is probably also buggy in regard to this.
> 
> de4x5 is hopeless. I added nice comment in softnet to it.
> Unfortunately it was lost. 8)
> 
> Andi, neither you nor me nor Alan nor anyone are able to audit
> all this unnevessarily overcomplicated code. It was buggy, is buggy
> and will be buggy. It is inavoidable, as soon as you have hundreds
> of drivers.

de4x5 is becoming EISA-only in 2.5.x too, since its PCI support is
duplicated now in tulip driver.

Jeff


-- 
Jeff Garzik | Dinner is ready when
Building 1024   | the smoke alarm goes off.
MandrakeSoft|   -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:[EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
> 
> Thanks for the info.
> 
> After looking at it, let me modify my position a bit.
> 
> My problem is that pthread_create (glibc 2.1.3, kernel 2.2.17 i686) is
> failing because, deep inside glibc somewhere, nanosleep() is returning
> EINTR.
> 
> My code is not using signals.  The threading library is, and there is
> obviously some subtle bug going on here.  Ever wonder why when browsing
> with Netscape and you click on a link and it says "Interrupted system
> call."?  This is it.  I'm arguing that the default behaviour should be
> SA_RESTART, and if some programmer is so studly that they actually know
> what the hell they are doing by disabling SA_RESTART, then they can do
> it explicitly.
> 

They do so explicitly by not specifying SA_RESTART.  It's a bitmask,
and the behaviour of each bit is specified by POSIX.

> I don't mean this to sound like a rant.

It does... it sounds like a rant someone who hasn't even bothered
looking up the relevant standards and interfaced.

> It's just that I can't possibly ascertain why someone in their right
> mind would want any behaviour different than SA_RESTART.

Synchronous post-processing of signals.   Too many things cannot be
safely done in a signal handler context.

-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]
Please read the FAQ at http://www.tux.org/lkml/

Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land programmer...

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:[EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
>
> Hello!
> 
> > > Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do
> > > what BSD does:  re-start the interrupted call?
> > 
> > This is crap.  Returning EINTR is necessary for many applications.
> 
> Just reminder: this "crap" is default behaviour of Linux nowadays. 8)8)
> 

signal() is crap... I personally think it was a major lose to have
signal() change to BSD behaviour by default (an unexpected change for
most applications!!)

For sigaction() you must choose behaviour explicitly anyway, by either
specifying or not specifying SA_RESTART.

Applications should use sigaction().  Period.  Full stop.  signal() is
so unpredictable these days as to be practically unusable.

-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]
Please read the FAQ at http://www.tux.org/lkml/

asm/resource.h

[H. Peter Anvin]

Hello friends,

Attached is a patch against 2.4.0-test10 that changes asm/resource.h to
define RLIM_INFINITY insite the #ifdef __KERNEL__ on all architectures;
previously, this was inconsistent between architecures.  This breaks
compilation with -Werror at least on i386 since 
includes , at least on glibc-2.1.2.

I have only been able to test this on i386 and glibc 2.1.2.  If there are
any places where this change is *not* appropriate, now would be a good
time to holler...

-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

diff -ur linux-2.4.0-test10-orig/include/asm/resource.h 
linux-2.4.0-test10/include/asm/resource.h
--- linux-2.4.0-test10-orig/include/asm/resource.h  Fri Sep 22 14:21:19 2000
+++ linux-2.4.0-test10/include/asm/resource.h   Fri Nov  3 13:11:12 2000
@@ -19,13 +19,13 @@
 
 #define RLIM_NLIMITS   11
 
+#ifdef __KERNEL__
+
 /*
  * SuS says limits have to be unsigned.
  * Which makes a ton more sense anyway.
  */
 #define RLIM_INFINITY  (~0UL)
-
-#ifdef __KERNEL__
 
 #define INIT_RLIMITS   \
 {  \
diff -ur linux-2.4.0-test10-orig/include/asm-alpha/resource.h 
linux-2.4.0-test10/include/asm-alpha/resource.h
--- linux-2.4.0-test10-orig/include/asm-alpha/resource.hWed Sep 27 13:39:23 
2000
+++ linux-2.4.0-test10/include/asm-alpha/resource.h Fri Nov  3 13:11:30 2000
@@ -19,14 +19,14 @@
 
 #define RLIM_NLIMITS   11
 
+#ifdef __KERNEL__
+
 /*
  * SuS says limits have to be unsigned.  Fine, it's unsigned, but
  * we retain the old value for compatibility, especially with DU. 
  * When you run into the 2^63 barrier, you call me.
  */
 #define RLIM_INFINITY  0x7ffful
-
-#ifdef __KERNEL__
 
 #define INIT_RLIMITS   \
 {  \
diff -ur linux-2.4.0-test10-orig/include/asm-i386/resource.h 
linux-2.4.0-test10/include/asm-i386/resource.h
--- linux-2.4.0-test10-orig/include/asm-i386/resource.h Fri Sep 22 14:21:19 2000
+++ linux-2.4.0-test10/include/asm-i386/resource.h  Fri Nov  3 13:11:12 2000
@@ -19,13 +19,13 @@
 
 #define RLIM_NLIMITS   11
 
+#ifdef __KERNEL__
+
 /*
  * SuS says limits have to be unsigned.
  * Which makes a ton more sense anyway.
  */
 #define RLIM_INFINITY  (~0UL)
-
-#ifdef __KERNEL__
 
 #define INIT_RLIMITS   \
 {  \
diff -ur linux-2.4.0-test10-orig/include/asm-ia64/resource.h 
linux-2.4.0-test10/include/asm-ia64/resource.h
--- linux-2.4.0-test10-orig/include/asm-ia64/resource.h Fri Sep 22 14:21:19 2000
+++ linux-2.4.0-test10/include/asm-ia64/resource.h  Fri Nov  3 13:11:04 2000
@@ -22,13 +22,13 @@
 
 #define RLIM_NLIMITS   11
 
+# ifdef __KERNEL__
+
 /*
  * SuS says limits have to be unsigned.
  * Which makes a ton more sense anyway.
  */
 #define RLIM_INFINITY  (~0UL)
-
-# ifdef __KERNEL__
 
 #define INIT_RLIMITS   \
 {  \
diff -ur linux-2.4.0-test10-orig/include/asm-m68k/resource.h 
linux-2.4.0-test10/include/asm-m68k/resource.h
--- linux-2.4.0-test10-orig/include/asm-m68k/resource.h Fri Sep 22 14:21:20 2000
+++ linux-2.4.0-test10/include/asm-m68k/resource.h  Fri Nov  3 13:10:54 2000
@@ -19,13 +19,13 @@
 
 #define RLIM_NLIMITS   11
 
+#ifdef __KERNEL__
+
 /*
  * SuS says limits have to be unsigned.
  * Which makes a ton more sense anyway.
  */
 #define RLIM_INFINITY  (~0UL)
-
-#ifdef __KERNEL__
 
 #define INIT_RLIMITS   \
 {   \
diff -ur linux-2.4.0-test10-orig/include/asm-mips/resource.h 
linux-2.4.0-test10/include/asm-mips/resource.h
--- linux-2.4.0-test10-orig/include/asm-mips/resource.h Fri Sep 22 14:21:20 2000
+++ linux-2.4.0-test10/include/asm-mips/resource.h  Fri Nov  3 13:10:44 2000
@@ -26,13 +26,13 @@
 
 #define RLIM_NLIMITS 11/* Number of limit flavors.  */
 
+#ifdef __KERNEL__
+
 /*
  * SuS says limits have to be unsigned.
  * Which makes a ton more sense anyway.
  */
 #define RLIM_INFINITY  0x7fffUL
-
-#ifdef __KERNEL__
 
 #define INIT_RLIMITS   \
 {  \
diff -ur linux-2.4.0-test10-orig/include/asm-mips64/resource.h 
linux-2.4.0-test10/include/asm-mips64/resource.h
--- linux-2.4.0-test10-orig/include/asm-mips64/resource.h   Fri Sep 22 14:21:20 
2000
+++ linux-2.4.0-test10/include/asm-mips64/resource.hFri Nov  3 13:10:30 2000
@@ -27,13 +27,13 @@
 
 #define RLIM_NLIMITS 11/* Number of limit flavors.  */
 
+#ifdef __KERNEL__
+
 /*
  * SuS says limits have to be unsigned.
  * Which makes a ton more sense anyway.
  */
 #define RLIM_INFINITY  (~0UL)
-
-#ifdef __KERNEL__
 
 #define 

Small fix

[Jan Kara]

  Hello.

  I've got a report that some people using quotas for lots of
users are experiencing being out of dquots. The problem is
that we have quota structs bound in unused inodes and we are not
aggressive enough to get it back. The following patch should
fix it (OK, more proper would be to make quota cache dynamic
as inode cache is but that wouldn't definitely pass over you :)).

Honza


--- linux/fs/dquot.cFri Oct  6 00:18:14 2000
+++ linux/fs/dquot.cFri Nov  3 21:10:51 2000
@@ -522,7 +522,7 @@
 struct dquot *get_empty_dquot(void)
 {
struct dquot *dquot;
-   int shrink = 1; /* Number of times we should try to shrink dcache and icache */
+   int shrink = 16;/* Number of times we should try to shrink dcache and 
+icache */
 
 repeat:
dquot = find_best_free();

Re: panic in reiserfs on test-2.4.0-test9/10

[Hans Reiser]

We'll try to reproduce this when the guys get in for work this morning, thanks for the 
bug report.

Elena, add symlink testing to mongo.sh so that it gets tested by our regression tests.

Hans

Andy Robinson wrote:
> 
> Hi,
> 
> I tried the linux-2.4.0-test9-resiserfs-3.6.18-patch on both 2.4.0-test9
> and test2.4.0-test10
> and got the following PANIC I originally saw this PANIC when doing a 'cp
> -a / /reiserfs'.
> I narrowed it done to a simple symlink 
> 
> Andy
> 
> [root@client19 /reiserfs]# ln -s foo.tar foo
> Unable to handle kernel NULL pointer dereference at virtual address
> 0010
>  printing eip:
> c0185953
> *pde = 
> Oops: 
> CPU:0
> EIP:0010:[]
> EFLAGS: 00010296
> eax: c12a017c   ebx: c12a0060   ecx: 000f   edx: 
> esi: c12a0090   edi: c12a   ebp: 0005   esp: c0c01b60
> ds: 0018   es: 0018   ss: 0018
> Process ln (pid: 928, stackpage=c0c01000)
> Stack: c12a0078 c12a017c c0c01bf8 0001  c0c01be0 c0178dc4
> c058dc00
>c0c01ba4 c0c01b8c  c0182728 c0182736 0001 0130
> 
> c0c01c40 0001  c0c01c28 c0c01bfc 
> 
> Call Trace: [] [] [] []
> [] [] []
>[] [] [] [] []
> Code: 8b 52 10 ff d2 5b 5f 8b 54 24 14 8b 42 34 89 c7 0f b7 47 02
> Segmentation fault
> 
> ksymoops 2.3.4 on i686 2.4.0-test9.  Options used
>  -V (default)
>  -k /proc/ksyms (default)
>  -l /proc/modules (default)
>  -o /lib/modules/2.4.0-test9/ (default)
>  -m /boot/System.map-test9 (specified)
> 
> No modules in ksyms, skipping objects
> Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid
> lsmod file?
> Unable to handle kernel NULL pointer dereference at virtual address
> 0010
> c0185953
> *pde = 
> Oops: 
> CPU:0
> EIP:0010:[]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010296
> eax: c12a017c   ebx: c12a0060   ecx: 000f   edx: 
> esi: c12a0090   edi: c12a   ebp: 0005   esp: c0c01b60
> ds: 0018   es: 0018   ss: 0018
> Process ln (pid: 928, stackpage=c0c01000)
> Stack: c12a0078 c12a017c c0c01bf8 0001  c0c01be0 c0178dc4
> c058dc00
>c0c01ba4 c0c01b8c  c0182728 c0182736 0001 0130
> 
> c0c01c40 0001  c0c01c28 c0c01bfc 
> 
> Call Trace: [] [] [] []
> [] [] []
>[] [] [] [] []
> Code: 8b 52 10 ff d2 5b 5f 8b 54 24 14 8b 42 34 89 c7 0f b7 47 02
> 
> >>EIP; c0185953<=
> Trace; c0178dc4 
> Trace; c0182728 
> Trace; c0182736 
> Trace; c018ede7 
> Trace; c017d3a3 
> Trace; c017d842 
> Trace; c017a5f2 
> Trace; c0230f99 
> Trace; c0239e3a 
> Trace; c0139892 
> Trace; c0139951 
> Trace; c010a717 
> Code;  c0185953 
>  <_EIP>:
> Code;  c0185953<=
>0:   8b 52 10  mov0x10(%edx),%edx   <=
> Code;  c0185956 
>3:   ff d2 call   *%edx
> Code;  c0185958 
>5:   5bpop%ebx
> Code;  c0185959 
>6:   5fpop%edi
> Code;  c018595a 
>7:   8b 54 24 14   mov0x14(%esp,1),%edx
> Code;  c018595e 
>b:   8b 42 34  mov0x34(%edx),%eax
> Code;  c0185961 
>e:   89 c7 mov%eax,%edi
> Code;  c0185963 
>   10:   0f b7 47 02   movzwl 0x2(%edi),%eax
> 
> 1 warning issued.  Results may not be reliable.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Jeff Garzik]

David Ford wrote:
> 
> Alan Cox wrote:
> 
> > > 10. To Do But Non Showstopper
> > >  * PCMCIA/Cardbus hangs (Basically unusable - Hinds pcmcia code is
> > >reliable)
> > >   + PCMCIA crashes on unloading pci_socket
> >
> > The pci_socket crash is fixed it seems
> 
> Not unless it was fixed in test10 release.  I have a PC LinkSys dual 10/100 and
> 56K card that will kill the machine if you physically pull it out no matter what
> cardctl/module steps are taken.
> 
> It uses the ne2k and serial drivers.

Part of that might be that serial doesn't support hotplug without
patching.

-- 
Jeff Garzik | Dinner is ready when
Building 1024   | the smoke alarm goes off.
MandrakeSoft|   -/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: celeron-class misdetected as 486

[davej]

Pavel Machek wrote..

> pavel@bug:~$ cat /proc/cpuinfo
> processor   : 0
> vendor_id   : GenuineIntel
> cpu family  : 4
^^^
Since when were there family 4 Celerons ?

> model   : 0
> model name  : 486 DX-25/33
> stepping: 0
> cache size  : 128 KB

Though a 486 with 128K cache is also unlikely.
(Although some of the wierd overdrives had such added fun iirc)

> that's wrong. Older kernels detect it correctly as:
>May 10 21:39:04 bug kernel: Pentium-III serial number disabled.
>May 10 21:39:04 bug kernel: CPU: Intel Celeron (Mendocino) stepping 0a

Which older kernel detected this ?

This is really bizarre, as there are cpuid capable 486s with the
family/vendor IDs reported above. I do hope we don't have to add
more cachesize checking. That part of setup.c is ugly enough
already.

Can you open up and find out if it really is a Celeron in that box
before such code gets added ?

regards,

Dave.

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

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

Re: how to get IP address of current machine from C++ code?

[David Ford]

Christopher Friesen wrote:

> I would like to get the IP address of one of the interfaces of the
> machine that I'm currently on from within some C++ code.  It looks like
> I should be able to do this by doing an
>
> ioctl(atoi(fd, SIOCGIFADDR, )
>
> with the interface name set in the appropriate field in ifr, but I'm not
> sure how I should be getting the proper value for fd.  I would
> appreciate some help on this, or if there is a better way then I'd love
> to hear it.

This isn't c++, it's plain c, but it's easy to grok.  Called as: gi
[interface]

-d

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."




/*
 * short hack to grab interface information
 * gcc -o gi gi.c; strip gi
 *
 * Blu3, Jan 1999
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define SIOCGIFCONF0x8912  /* get iface list   */

int main(int argc, char *argv[])
{
int numreqs = 30, sd, n, search, tick, found=0;
struct ifconf ifc;
struct ifreq *ifr;
struct in_addr *ia;

//
// if there is an arg on the command line, print out the ip of that device
// only.  note the numreqs in the above, modify that as is desired.

search= (argc>1);
if(search && strlen(argv[1]) > 64) {
  fprintf(stderr, "specified device name too large, ignoring\n");
  search=0;
}

sd=socket(AF_INET, SOCK_STREAM, 0);
ifc.ifc_buf = NULL;
ifc.ifc_len = sizeof(struct ifreq) * numreqs;
ifc.ifc_buf = realloc(ifc.ifc_buf, ifc.ifc_len);
if (ioctl(sd, SIOCGIFCONF, ) < 0) {
perror("SIOCGIFCONF");
}
 
ifr = ifc.ifc_req;
for (n = 0; n < ifc.ifc_len; n += sizeof(struct ifreq)) {
ia= (struct in_addr *) ((ifr->ifr_ifru.ifru_addr.sa_data)+2);
if(search)
tick= strcmp(ifr->ifr_ifrn.ifrn_name, argv[1]);

if(!search)
fprintf(stdout, "%6s %-15s\n", ifr->ifr_ifrn.ifrn_name, 
inet_ntoa(*ia));
  
if (search && (tick==0)) {
fprintf(stdout, "%s\n", inet_ntoa(*ia));
found=1;
}
ifr++;
}

free(ifc.ifc_buf);
fprintf(stderr, "exiting with %i\n", found);
exit(found);
}


begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;-12480
fn:David Ford
end:vcard

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[David Ford]

Alan Cox wrote:

> > 10. To Do But Non Showstopper
> >  * PCMCIA/Cardbus hangs (Basically unusable - Hinds pcmcia code is
> >reliable)
> >   + PCMCIA crashes on unloading pci_socket
>
> The pci_socket crash is fixed it seems

Not unless it was fixed in test10 release.  I have a PC LinkSys dual 10/100 and
56K card that will kill the machine if you physically pull it out no matter what
cardctl/module steps are taken.

It uses the ne2k and serial drivers.

-d

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."




begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;-12480
fn:David Ford
end:vcard

Re: Looking for better 2.2-based VM (do_try_to_free_pages fails,machine hangs)

[Marcelo Tosatti]

On Fri, 3 Nov 2000, Ingo Oeser wrote:

> On Wed, Nov 01, 2000 at 10:03:27PM +0100, Yann Dirson wrote:
> > On Wed, Nov 01, 2000 at 02:59:01PM -0200, Rik van Riel wrote:
> > > it appears there has been amazingly little research on this
> > > subject and it's completely unknown which approach will work
> > > "best" ... or even, what kind of behaviour is considered to
> > > be best by the users...
> > 
> > Sounds to me like a good point to favour a config-time selection of
> > OOM killers.
> 
> Better yet: Apply my OOM-Killer-API-Patch[1] and build your own
> OOM-Killer!
> 
> Just lock your module into memory, supply an function to
> install_oom_killer(), save the old one (you get it as return if
> installing it went ok) and be happy.
> 
> And now have fun bringing your machine into OOM situations.
> 
> Want to change it back? No problem. Just get signaled somehow[2],
> reinstall the old one, unlock your module and wait to be cleaned
> up.
> 
> I never tried it above Riks 2.2.x-OOM-Killer-Patch, but it should
> work on top of it, because oom_kill.c isn't all that different.

Ingo,

Maybe you could change Rik's oom killer to be a "module" of your OOM
killer API?

With this in place, its easier for people to compare Rik's OOM killer
with other possible new algorithms. 




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

celeron-class misdetected as 486

[Pavel Machek]

Hi!

In 2.4.0-test10, I get

pavel@bug:~$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 4
model   : 0
model name  : 486 DX-25/33
stepping: 0
cache size  : 128 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : no
cpuid level : 3
wp  : yes
use_tsc : no


 that's wrong. Older kernels detect it correctly as:

May 10 21:39:04 bug kernel: Pentium-III serial number disabled.
May 10 21:39:04 bug kernel: CPU: Intel Celeron (Mendocino) stepping 0a

Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

ne2k pcmcia problem

[Pavel Machek]

Hi!

When I unplug pcmcia ne2k (without  stopping card, just uplug), it
oopses. In earlier kernels, it gave few error messages but more or
less worked.

I get 

invalid operand 

fault is in __wake_up

stack trace contains
c027... (bogus)
c0279978 (bogus)
c01a5e08 ei_receive
c0115994 process_timeout
c01ef18a cs_sleep
c01ef4fa do_shutdown
...

Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Value of TASK_UNMAPPED_SIZE on 2.4

[Andrea Arcangeli]

On Fri, Nov 03, 2000 at 09:27:07PM +0100, Kai Harrekilde-Petersen wrote:
> Is this available as a patch, or preferably as a compilation option to

They're available here:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.14/bigmem-large-mapping-1.bz2

ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.14/bigmem-large-task-1.bz2

But they're against 2.2.x + bigmem. The first one is still valid (and it's
similar to the one discussed here). The second one doesn't apply to 2.4.x
and both vmlinux.lds and PAGE_OFFSET should be changed that way to
make it to work there.

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

2.2.x BUG & PATCH: recvmsg() does not check msg_controllen correctly

[Philippe Troin]

I found this in all 2.2.x kernels, and it might possibly be present in
2.4.x too...

When receiving file descriptors via recvmsg(), scm_detach_fds() in
net/core/scm.c can overflow user space data at msg_control if
msg_controllen is less than sizeof(struct cmsghdr).

This is a security problem.

Attached is a patch to fix the problem and a little program to
demonstrate the problem.

Phil.

 linux-2.2.17-8-scmrights.patch
 check-anc.c

Re: [patch] NE2000

[Jorge Nerin]

Paul Gortmaker wrote:
> 
> Jorge Nerin wrote:
> 
> >
> > Ok, I reported it several times, but it gets ignored. I have a Realtek
> > 8029 (ne2k-pci), and with both drivers ne and ne2k-pci I can easily get
> > it stuck by doing a ping -f to a host in the local net, and sometimes it
> > happens doing copies to/from nfs shared resources.
> >
> > rmmod & insmod don't cure the problem, it seems that no interrupts are
> > delivered from the card, and there are no log messages, so a reboot is
> > needed to restore net access.
> >
> > System is dual 2x200mmx 96Mb ide discs no interrupts shared, and as far
> > as I can remember all kernel from 2.2.x, 2.3.x up to 2.4.0-testx exhibit
> > this problem.
> 
> Any messages from the driver whatsoever?   Does running a non-SMP
> kernel make the problem go away?
> 
> Paul.
> 

Well, I have tried it with 2.4.0-test10, both SMP and non-SMP, and the
result is a little confusing.

Under SMP a ping -s 5 -f other_host takes down the network access
with no messages (ne2k-pci), and no possibility of being restored
without a reboot.

Under UP the same command works ok, but after a while the dots stop for
30sec, then ping prints an 'E' and the dots continue. strace revealed
this:

sendmsg(4, {msg_name(16)={sin_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("192.168.1.20")}},
msg_iov(1)=[{"\10\0\305~|\23\231\0\v\317\2:\177\236\r\0\10\t\n\v\f\r"...,
50008}], msg_controllen=0, msg_flags=0}, 0x800) = 50008 <30.016855>

ping has been waiting for sendmsg to end for 30 seconds! I don't know if
this could be caused by filling the network buffers, and then waiting a
while while the nic sends it out. As the packet size increases (the -s
option) the stops are more frequent, there is still activity on the
network, but I don't know if they are my packets or the replies.

When ping is stopped it's stuck in sock_wait_for_wmem, and when it's
running it's (usually) in wait_for_packet.

So I think that it could be a little window near sock_wait_for_wmem that
could be SMP insecure wich is affecting me.

The code of sock_wait_for_wmem in 2.4.0-test10 is this:

static long sock_wait_for_wmem(struct sock * sk, long timeo)
{
DECLARE_WAITQUEUE(wait, current);

clear_bit(SOCK_ASYNC_NOSPACE, >socket->flags);
add_wait_queue(sk->sleep, );
for (;;) {
if (signal_pending(current))
break;
set_bit(SOCK_NOSPACE, >socket->flags);
set_current_state(TASK_INTERRUPTIBLE);
if (atomic_read(>wmem_alloc) < sk->sndbuf)
break;
if (sk->shutdown & SEND_SHUTDOWN)
break;
if (sk->err)
break;
timeo = schedule_timeout(timeo);
}
__set_current_state(TASK_RUNNING);
remove_wait_queue(sk->sleep, );
return timeo;
}

Does someone see something SMP insecure? Perhaps I'm totally wrong, this
could also be somewhere in the interrupt handling, don't know.

-- 
Jorge Nerin
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

include fb.h from userland?

[Chris Swiedler]

I understand that the headers in /usr/include/linux shouldn't be overwritten
by new kernel installs. But can someone elaborate on Linus's original
admonition
(http://kernelnotes.org/lnxlists/linux-kernel/lk_0007_04/msg00881.html)? Am
I never, ever, ever allowed to update my system headers for the rest of my
life, or is it only if I follow some particular procedure, such as
recompiling glibc?

The reason I want to upgrade my system headers is that framebuffer
development requires linux/fb.h to be included from userland (I see no way
around that). The version of fb.h in my system headers is 2.2.5, the distro
version I originally installed. I'm running 2.2.17 kernel now, which has
much newer fb.h which I need.

chris

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

Re: Thrash reduction & RE: 2.4.0-test10 Sluggish After Load

[Christoph Rohland]

Hi Jonathan,

On Fri, 3 Nov 2000, Jonathan George wrote:
> I wonder how much of that memory is actually being used by your
> processes.  My guess is that it's not the whole thing (unless you
> are running on a 64bit architecture).

Yes of course it is using the whole memory. That's what the highmem
stuff is all about.

Greetings
Christoph

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

Re: Value of TASK_UNMAPPED_SIZE on 2.4

[Kai Harrekilde-Petersen]

Andrea Arcangeli <[EMAIL PROTECTED]> writes:

> On Fri, Nov 03, 2000 at 11:15:46AM -0800, Josue Emmanuel Amaro wrote:
> > (page.h).  This works out to be a value of 0x400.
> ^ one more zero here
> > Are there any negative side effects in defining TASK_UNMAPPED_SIZE to 0x100?
> 
> I guess you mean 0x1000. There's no risk in doing that. I also did another
> patch that moves the kernel away and allows 3.5G per process on IA32 via plain
> mmap or shmat, but it has the downside of reducing a lot the ZONE_NORMAL where
> on IA32 buffercache and skb still lives.

Is this available as a patch, or preferably as a compilation option to
the standard kernel?

The ASIC tools that we use wants all the memory they can grab, and the
extra few hundred megs can sometimes be _very_ critical.  On Solaris,
Synopsys' Design Compiler can allocate 3.8Gig and we've hit that limit
hard when working with toplevel netlists and SDF databases.

Thanks in advance,


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

2.2.18pre19 RPC NFS Errors/2.4.0 Lockup

[Jeff V. Merkey]

Alan,

The 2.2.18pre-19 build does not reproduce this problem with NFS RPC
timeouts, and Andre has merged his patches for our next release, and I
am unable to reproduce it.  In fact, it's running great.   I did have
NDS eDirectory installed on this box when I saw the problem, and without
this software loaded, it seems to be gone.  I think it may be related to
eDirectory in some way (top is reporting some busy process in
eDirectory).  I held off posting the release to reverify the 2.2.18pre18
problems, and to get Andre's patches into the release.   We will go out
with 2.2.18pre-19 at this point.   

Also, I am seeing a lockup on 2.4.0-10 with uniprocessor PPro systems
with SMP enabled, but it runs great on a 4xPPro system with SMP (???). 
I rebuilt with SMP=N and it also ran great.  One for H. Peter Anvin I
think 

:-)

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

Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land programmer...

[Richard B. Johnson]

On Fri, 3 Nov 2000 [EMAIL PROTECTED] wrote:

> Considering that the threading library for Linux uses signals to make it
> work, would it be possible to change the Linux kernel to operate the way
> BSD does--instead of returning EINTR, just restart the interrupted
> primitive?
> 
It's just how the default for signal() is set up by the 'C' runtime
library. Instead of using signal, use sigaction(), set the SA_RESTART
flag and you have BSD action.

It is also possible to compile existing applications using

-D_BSD_SIGNALS  (this is from memory, it might not be exactly correct).

New applications should not use signal(), then should use sigaction()
which gives POSIX-defined fine control over the signal handler.


Cheers,
Dick Johnson

Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


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

Re: 255.255.255.255 won't broadcast to multiple NICs

[Philippe Troin]

Rob Landley <[EMAIL PROTECTED]> writes:
> --- Philippe Troin <[EMAIL PROTECTED]> wrote:
> > All the code I've encountered which actually needed
> > to perform
> > broadcast on all interfaces was sending
> > subnet-directed broadcasts by
> > hand on all interfaces.
> 
> Bind to a socket to a local port and query that
> address you say?  Nope, too easy.  The address
> returned when I query a socket (rather than a
> connection) is 0.0.0.0 on any machine with multiple
> interfaces (even loopback), since the socket is bound
> to that port on ALL the interfaces.  Each incoming or
> outgoing connection does have a valid "from" IP
> address, but I have to wait for a connection to come
> in to get that.  (Unless I explicitly specify which IP
> to bind to when I create the socket, but if I knew
> that I'd already be there.)
> 
> Nope, making my own connection to a port on the same
> machine just means 127.0.0.1 is talking to 127.0.0.1. 
> Tried it.  Didn't work.
> 
> Nope, feeding the loopback address to getAllByName()
> doesn't help either.  I tried that too, it just
> returns a length 1 array containing just the loopback
> address.

The source IP address (as returned by getsockname()) is only set when
the socket is connected... It follows the same logic: for a multihomed
machine, we know which interface will be used only when we know who
we'll be talking to...

> Now you know why I'm resorting to 255.255.255.255. 
> I'm sort of faking things: when the server broadcasts
> to clients they know who it is, and when they
> broadcast to it, it knows who THEY are (it says in the
> UDP datagram header info).  And the way I've written
> it, that's all they really need to know (although when
> we reply to each other we can each find out the info
> we don't know: who WE are.  But by that point, we no
> longer need it. :)
> 
> I may just document "if you run this on a machine with
> more than one network card, you have to specify the
> broadcast addresses on the command line".  It's
> configuration, but the only machine likely to HAVE
> multiple interfaces is the server (which could be
> serving multiple subnets in a really BIG render farm),
> so I suppose it's tolerable...

You could use SIOGIFCONF (from C) to get the address list. I'm not
sure is java has the equivalent... Or maybe a very small native
method...

> > Broadcast is ugly anyways, why don't you use
> > multicast ?
> 
> I'm only passingly familiar with it, does it map well
> to this problem?
> 
> The only data I'm trying to transmit is "where is
> everybody", or "wake up".  The broadcast packets are
> only needed for clients to find the server on bootup
> (and vice versa if the server is rebooted).  They're
> also used to wake up clients if they go to sleep
> because the server has nothing for them to do at the
> moment, but that second part's a convenience, really. 
> The server could loop through and address them
> individually instead since it knows where they are by
> that point.
> 
> The actual heavy lifting of data is done by TCP/IP
> streams.  UDP broadcast is just for figuring out where
> to open the TCP/IP connections to.

Sounds like a good job for multicast... It's fairly simple to use,
but:

  1) I'm not sure if java gives you access to the required ioctls
 (there's only five of them).

  2) You may need to run mrouted on all your gateways.

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

Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land programmer...

[kuznet]

Hello!

> > Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do
> > what BSD does:  re-start the interrupted call?
> 
> This is crap.  Returning EINTR is necessary for many applications.

Just reminder: this "crap" is default behaviour of Linux nowadays. 8)8)

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

Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land programmer...

[george]

Ulrich Drepper wrote:
> 
> [EMAIL PROTECTED] writes:
> 
> > Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do
> > what BSD does:  re-start the interrupted call?
> 
> This is crap.  Returning EINTR is necessary for many applications.
> 
> --
> ---.  ,-.   1325 Chesapeake Terrace
> Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
> Red Hat  `--' drepper at redhat.com   `

After reading about SA_RESTART, ok.  However, couldn't those
applications that require it enable this behaviour explicitly?

The problem I'm having right now is with pthread_create() failing
because deep somewhere in either the kernel or glibc, nanosleep()
returns EINTR during said pthread_create() and pthread_create() fails.

I've got a multithreaded program written using gcc (2.95.2) and glibc
(2.1.3), and it's talking to a natively threaded Java program (tried
both Sun & Blackdown ports, both 1.2.2 and 1.3) on a 2.2.17 kernel.  The
C program is listening for incoming socket connections, and the Java
program is hammering on it with many parallel connect() calls.  After a
short, a bit random interval, pthread_create() will fail in either my
program, or deep in the Java VM.  I assume that the Java VM is using
pthread_create().

I don't mean to sound like a psycho on this, but I can't see why
SA_RESTART isn't the default behavior.  Maybe I'm missing something
somewhere.
--
George T. Talbot

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

Re: 255.255.255.255 won't broadcast to multiple NICs

[Rob Landley]

--- Paul Flinders <[EMAIL PROTECTED]> wrote:
> 
> Rob Landley <[EMAIL PROTECTED]> writes:
> > 3) Java sucks in many ways.  Today's way is that
...
> > There is no way to query the current machine's
> > interfaces without resorting to
> > native code.
> 
> I faced this problem a while ago - in the end I
> cheated and put this bit of code in a shell script
> used to start the application

I've considered it.  Counts as "native code", but
thanks for the script anyway. :)

For my current app, I've pretty much decided that for
the boxes where broadcasting 255.255.255.255, they
have to supply it on the command line.  Maybe I'll
have the script supply it on the command line for them
since I'll probably offer an RPM or linux-specific tar
as an install option.  I need to potentially install
the JRE for them (assuming licensing issues work out
ok there, which I'm 99% certain is fine but want to
double check), and should have a shell script to
encapsulate the "jre -cp myjar.jar runthisclass" part
anyway into "runclient" or "runserver".  (Possibly
starting from the init scripts, or with a nice Gnome
icon.  Depends how industrious I feel when I'm done,
and/or what my boss wants. :)

The larger question of "should the Linux kernel's IP
stack behavior be fixed, documented, or left alone" is
what I'm interested in now.  If people agree that
255.255.255.255 should go out to multiple interfaces,
I'd be willing to try my hand at a patch to route.c
(be afraid, be very afraid), but I'm still waiting to
hear from on high (higher than me anyway) about
whether or not the current behavior is something
they're happy with.  (My app will NOT require a custom
kernel to function properly, that's not an option. :)

> including ${NET_ADDRESSES} in the java command line
> sets
> up a set of defines, one per interface. For example
> 
> -Dethaddr.172.16.1.1=00:00:0A:BC:CD:78
> -Dnetmask.172.16.1.1=255.255.0.0
> 
> which you can use via System.getProperty() and
> System.getProperties()

If I go with a script I'll just have it spit the IP
broadcast addresses one after the other to stdout, and
then call it from the command line with back quotes as
some variant of:

./myprog broadcast `./findbroadcasts`

Encased in the platform-specific launch shell script,
of course. :)

Why on earth would my app need the ethernet address? 
If the stack didn't abstract that away, there would be
a much bigger problem than global broadcasts not
really being global...

Rob

__
Do You Yahoo!?
>From homework help to love advice, Yahoo! Experts has your answer.
http://experts.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land

[george]

Tim Hockin wrote:
> 
> > Considering that the threading library for Linux uses signals to make it
> > work, would it be possible to change the Linux kernel to operate the way
> > BSD does--instead of returning EINTR, just restart the interrupted
> > primitive?
> 
> man sigaction, look for SA_RESTART

Thanks for the info.

After looking at it, let me modify my position a bit.

My problem is that pthread_create (glibc 2.1.3, kernel 2.2.17 i686) is
failing because, deep inside glibc somewhere, nanosleep() is returning
EINTR.

My code is not using signals.  The threading library is, and there is
obviously some subtle bug going on here.  Ever wonder why when browsing
with Netscape and you click on a link and it says "Interrupted system
call."?  This is it.  I'm arguing that the default behaviour should be
SA_RESTART, and if some programmer is so studly that they actually know
what the hell they are doing by disabling SA_RESTART, then they can do
it explicitly.

I don't mean this to sound like a rant.  It's just that I can't possibly
ascertain why someone in their right mind would want any behaviour
different than SA_RESTART.
--
George T. Talbot

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

Re: Can EINTR be handled the way BSD handles it? -- a plea from a user-land programmer...

[Ulrich Drepper]

[EMAIL PROTECTED] writes:

> Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do
> what BSD does:  re-start the interrupted call?

This is crap.  Returning EINTR is necessary for many applications.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Value of TASK_UNMAPPED_SIZE on 2.4

[Andrea Arcangeli]

On Fri, Nov 03, 2000 at 11:15:46AM -0800, Josue Emmanuel Amaro wrote:
> (page.h).  This works out to be a value of 0x400.
  ^ one more zero here
> Are there any negative side effects in defining TASK_UNMAPPED_SIZE to 0x100?

I guess you mean 0x1000. There's no risk in doing that. I also did another
patch that moves the kernel away and allows 3.5G per process on IA32 via plain
mmap or shmat, but it has the downside of reducing a lot the ZONE_NORMAL where
on IA32 buffercache and skb still lives.

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

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[kuznet]

Hello!

> that does hardware register access without protecting against interrupts
> or checking if the interface is up.

This issue is not that issue. It is separate issue and in fact
it is private problem of driver and its author, what is safe,
what is not safe.

F.e. I see no cathastrophe even if MII registers are accessed without
any protections. Diag utilities do this from user space. 8)8)


> de4x5 is probably also buggy in regard to this.

de4x5 is hopeless. I added nice comment in softnet to it.
Unfortunately it was lost. 8)

Andi, neither you nor me nor Alan nor anyone are able to audit
all this unnevessarily overcomplicated code. It was buggy, is buggy
and will be buggy. It is inavoidable, as soon as you have hundreds
of drivers.

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

hardware lock-up with 2.4.0-test10

[Ethan C. Baldridge]

on my box at work, which is a Pentium 200 with 64 megs of ram.

no strange messages in /var/log/messages, no commonality I've found
between the lockups.  This doesn't happen if I go back to 2.2.16 (which
I'm in right now).

Twice the lock-up occurred while initscripts were running on boot-up (at
different places in the initscripts).  Twice now it has happened while
I've been away from my computer for a while, both times apparently after
the screensaver has come on (black screen).

I'm running with DevFS and devfsd, IDE hard drive (Intel 82371SB PIIX3
controller), 3com 3C905 ethernet card, Intel 82439HX Triton II chipset
motherboard, Pentium with F00F bug.

Has anyone else seen this, and can you give me any suggestions?

Thanks,
Ethan Baldridge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: ext3 vs. JFS file locations...

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Andreas Dilger <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Michael Boman writes:
> > It seems like both IBM's JFS and ext3 wants to use fs/jfs .. IMHO that
> > is like asking for problem.. A more logic location for ext3 should be
> > fs/ext3, no?
> 
> Actually, if you would look in linux/fs, you will see that ext3 IS in
> linux/fs/ext3.  However, there is a second component to ext3, which is
> a generic block journalling layer which is called jfs.  This journal
> layer is designed so that it isn't ext3 specific, so it would be
> _possible_ for other journalling filesystems to use it.  Whether non-ext3
> filesystems will actually use it is another question (actually the
> InterMezzo distributed filesystem uses the ext3-jfs functionality to
> do compound transactions on disk to ensure cluster coherency).
> 
> I think that Stephen at one time said he would change the name, but I
> guess he has not done so yet.
> 

How about naming it something that doesn't end in -fs, such as
"journal" or "jfsl" (Journaling Filesystem Layer?)

-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]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Andi Kleen]

On Fri, Nov 03, 2000 at 10:03:48PM +0300, [EMAIL PROTECTED] wrote:
> Hello!
> 
> > It is not safe, just not worse than 2.2.
> 
> Andi.. 8)
> 
> That issue, which was meant here, it is 100% safe.
> 
> I start to suspect you did not look into this code since 2.2.

I actually did, and that is when all this started. I found lots of code
that does hardware register access without protecting against interrupts
or checking if the interface is up.

Tulip, eepro100 seem to be ok.
3c59x seems to be buggy
de4x5 is probably also buggy in regard to this.
It also does this:
   case DE4X5_GET_STATS:/* Get the driver statistics */
ioc->len = sizeof(lp->pktStats);
spin_lock_irqsave(>lock, flags);
if (copy_to_user(ioc->data, >pktStats, ioc->len)) return -EFAULT; 
spin_unlock_irqrestore(>lock, flags);
break;
rrunner does GFP_KERNEL kmallocs and copy_to_user with a spin lock held. The
hardware register access is probably also racy with interrupts (not 100% sure)
depca seems to be buggy too.

... [this was just a 5 minutes grep session. I suspect most of these bugs
were also in 2.2]

Of course the window is very small because nobody really uses these interrupts
regularly.

> I acn assume that nothing has changed in ISDN,
> in other drivers big changes happened. 8)

ISDN syncppp seems to be slightly buggy (module unload race with slhc, compressor
init dubious, racy device management that could be cured by the kernel lock),
non PPP ISDN does not have a network ioctl.


-Andi

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

Can EINTR be handled the way BSD handles it? -- a plea from a user-land programmer...

[george]

Considering that the threading library for Linux uses signals to make it
work, would it be possible to change the Linux kernel to operate the way
BSD does--instead of returning EINTR, just restart the interrupted
primitive?

For example, if I'm using read(2) to read data from a file descriptor,
and a signal happens, the signal handler runs, and read(2) returns EINTR
after the system call finishes.  Then I'm supposed to catch this and
re-try the system call.

I assume that this is true for _any_ system call which makes the process
block, right?

Can we _PLEASE_PLEASE_PLEASE_ not do this anymore and have the kernel do
what BSD does:  re-start the interrupted call?

Please?  If this is something that would be acceptable for integration
into a mainline kernel, I would do my best to help with a patch.

If I'm wrong about this, please enlighten me.  Also, please cc: me off
the list, as I don't get the list directly.

Thank you for your consideration.
--
George T. Talbot

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

conflicting types for `mktime' is userspave programs using libc5

[Kurt Roeckx]

When trying to compile something using libc5, with the
2.4.0-test10 kernel, I get this:

/usr/include/time.h:85: conflicting types for `mktime'
/usr/include/linux/time.h:69: previous declaration of `mktime'

A simple diff is attached



--- include/linux/time.h~   Fri Nov  3 20:22:14 2000
+++ include/linux/time.hFri Nov  3 20:21:22 2000
@@ -46,6 +46,7 @@
value->tv_sec = jiffies / HZ;
 }
 
+#ifdef __KERNEL__
 /* Converts Gregorian date to seconds since 1970-01-01 00:00:00.
  * Assumes input in normal date format, i.e. 1980-12-31 23:59:59
  * => year=1980, mon=12, day=31, hour=23, min=59, sec=59.
@@ -78,6 +79,7 @@
  )*60 + min /* now have minutes */
)*60 + sec; /* finally seconds */
 }
+#endif
 
 
 struct timeval {

Value of TASK_UNMAPPED_SIZE on 2.4

[Josue Emmanuel Amaro]

All,

TASK_UNMAPPED_SIZE is defined in include/asm-i386/processor.h as:

#define TASK_UNMAPPED_SIZE(TASK_SIZE / 3)

The value of TASK_SIZE is defined as PAGE_OFFSET which is set to 0xC000
(page.h).  This works out to be a value of 0x400.

The question is:
Are there any negative side effects in defining TASK_UNMAPPED_SIZE to 0x100?

By doing this we allow a process to access more memory.  On Oracle it allows us
to grow our buffer size from 1.7 GB to 2.4 GB improving overall performance by
reducing I/O.

Thanks in advance,

--
===
  Josue Emmanuel Amaro [EMAIL PROTECTED]
  Linux Products Manager   Phone:   650.506.1239
  Intel and Linux Technologies Group   Fax: 650.413.0167
===



begin:vcard 
n:Amaro;Josue Emmanuel
tel;cell:650-245-5131
tel;fax:650-413-0167
tel;work:650-506-1239
x-mozilla-html:FALSE
url:http://www.oracle.com
org:Intel and Linux Technologies
version:2.1
email;internet:[EMAIL PROTECTED]
title:Sr.Product Manager - Linux
adr;quoted-printable:;;500 Oracle Parkway=0D=0AMS1ip4;Redwood Shores;CA;94065;United States
fn:Josue Emmanuel Amaro
end:vcard