Re: light weight user level semaphores

[Ulrich Drepper]

Alan Cox <[EMAIL PROTECTED]> writes:

> mknod foo p. Or use sockets (although AF_UNIX sockets are higher latency)
> Thats why I suggested using flock - its name based. Whether you mkstemp()
> stuff and pass it around isnt something I care about
> 
> Files give you permissions for free too

I don't want nor need file permissions.  A program would look like this:


  process 1:


   fd = open("somefile")
   addr = mmap(fd);
   
   pthread_mutexattr_init();
   pthread_mutexattr_setpshared(, PTHREAD_PROCESS_SHARED);

   pthread_mutex_init ((pthread_mutex_t *) addr, );

   pthread_mutex_lock ((pthread_mutex_t *) addr);

   pthread_mutex_destroy((pthread_mutex_t *) addr);

  process 2:

   fd = open("somefile")
   addr = mmap(fd);

   pthread_mutex_lock ((pthread_mutex_t *) addr);


The shared mem segment can be retrieved in whatever way.  The mutex in
this case is anonymous.  Everybody who has access to the shared mem
*must* have access to the mutex.


For semaphores it looks similarly.  First the anonymous case:

 process 1:


   fd = open("somefile")
   addr = mmap(fd);

   sem_init ((sem_t *) addr, 1, 10);// 10 is arbitrary

   sem_wait ((sem_t *) addr);

   sem_destroy((sem_t *) addr);


  process 2:

   fd = open("somefile")
   addr = mmap(fd);

   sem_wait ((sem_t *) addr);

Note that POSIX semaphores could be implemented with global POSIX
mutexes.


Finally, named semaphores:

   semp = sem_open("somefile", O_CREAT|O_EXCL, 0600)

   sem_wait (semp);

   sem_close(semp);
   sem_unlink(semp);


This is the only semaphore kind which maps nicely to a pipe or socket.
All the others don't.  And even for named semaphores it is best to
have a separate name space like the shmfs.

> So you have unix file permissions on them ?

See above.  Permissions are only allowed for named semaphores.

-- 
---.  ,-.   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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dead symbol elimination, stage 1

[rmk]

Eric,

Please apply this patch before doing anything in the ARM tree.

What you will find is that most of your symbols in these files were due
to it being out of date.  However, I'd say the bigger problem is the
symbols that don't exist.

Also, you may not have the full story of the Config.in files - another
reason why you should not touch the architecture specific files.  For
instance, a quick scan of my latest ARM patch reveals:

src@raistlin:[2]:<1009> grep 'diff.*Config.in' rmk1
diff -urN linux-orig/drivers/char/Config.in linux/drivers/char/Config.in
diff -urN linux-orig/drivers/media/video/Config.in linux/drivers/media/video/Config.in
diff -urN linux-orig/drivers/mtd/Config.in linux/drivers/mtd/Config.in
diff -urN linux-orig/drivers/net/Config.in linux/drivers/net/Config.in
diff -urN linux-orig/drivers/net/irda/Config.in linux/drivers/net/irda/Config.in
diff -urN linux-orig/drivers/pcmcia/Config.in linux/drivers/pcmcia/Config.in
diff -urN linux-orig/drivers/sound/Config.in linux/drivers/sound/Config.in
diff -urN linux-orig/drivers/ssi/Config.in linux/drivers/ssi/Config.in
diff -urN linux-orig/drivers/video/Config.in linux/drivers/video/Config.in

So you're probably removing some of the valid symbols in the defconfig
files.  Without going through your changes with a toothpick...

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

diff -urN linux-orig/arch/arm/def-configs/clps7500 linux/arch/arm/def-configs/clps7500
--- linux-orig/arch/arm/def-configs/clps7500Tue Oct  3 20:08:18 2000
+++ linux/arch/arm/def-configs/clps7500 Tue Feb 13 15:26:10 2001
@@ -2,7 +2,9 @@
 # Automatically generated make config: don't edit
 #
 CONFIG_ARM=y
+# CONFIG_EISA is not set
 # CONFIG_SBUS is not set
+# CONFIG_MCA is not set
 CONFIG_UID16=y
 
 #
@@ -23,6 +25,7 @@
 CONFIG_ARCH_CLPS7500=y
 # CONFIG_ARCH_CO285 is not set
 # CONFIG_ARCH_EBSA110 is not set
+# CONFIG_ARCH_L7200 is not set
 # CONFIG_ARCH_FTVPCI is not set
 # CONFIG_ARCH_TBOX is not set
 # CONFIG_ARCH_SHARK is not set
@@ -30,22 +33,51 @@
 # CONFIG_ARCH_INTEGRATOR is not set
 # CONFIG_ARCH_RPC is not set
 # CONFIG_ARCH_SA1100 is not set
+# CONFIG_ARCH_CLPS711X is not set
+
+#
+# Archimedes/A5000 Implementations
+#
+
+#
+# Footbridge Implementations
+#
+
+#
+# SA11x0 Implementations
+#
+
+#
+# CLPS711X/EP721X Implementations
+#
 # CONFIG_ARCH_ACORN is not set
 # CONFIG_FOOTBRIDGE is not set
 # CONFIG_FOOTBRIDGE_HOST is not set
 # CONFIG_FOOTBRIDGE_ADDIN is not set
 CONFIG_CPU_32=y
 # CONFIG_CPU_26 is not set
+
+#
+# Processor Type
+#
 CONFIG_CPU_32v3=y
-CONFIG_CPU_ARM7=y
+# CONFIG_CPU_32v4 is not set
+# CONFIG_CPU_ARM610 is not set
+CONFIG_CPU_ARM710=y
+# CONFIG_CPU_ARM720T is not set
+# CONFIG_CPU_ARM920T is not set
+# CONFIG_CPU_ARM1020 is not set
+# CONFIG_CPU_SA110 is not set
+# CONFIG_CPU_SA1100 is not set
 # CONFIG_DISCONTIGMEM is not set
-# CONFIG_PCI is not set
-# CONFIG_ISA is not set
-# CONFIG_ISA_DMA is not set
 
 #
 # General setup
 #
+CONFIG_ANGELBOOT=y
+# CONFIG_PCI is not set
+CONFIG_ISA=y
+# CONFIG_ISA_DMA is not set
 # CONFIG_HOTPLUG is not set
 # CONFIG_PCMCIA is not set
 CONFIG_NET=y
@@ -60,7 +92,7 @@
 # CONFIG_BINFMT_MISC is not set
 # CONFIG_PM is not set
 # CONFIG_ARTHUR is not set
-CONFIG_CMDLINE="root=/dev/nfs rw"
+CONFIG_CMDLINE="mem=16M root=nfs"
 # CONFIG_ALIGNMENT_TRAP is not set
 
 #
@@ -81,34 +113,35 @@
 # Memory Technology Devices (MTD)
 #
 CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
 # CONFIG_MTD_DOC1000 is not set
 # CONFIG_MTD_DOC2000 is not set
 # CONFIG_MTD_DOC2001 is not set
 # CONFIG_MTD_DOCPROBE is not set
+
+#
+# RAM/ROM Device Drivers
+#
 # CONFIG_MTD_SLRAM is not set
-# CONFIG_MTD_PMC551 is not set
+# CONFIG_MTD_PMC551_BUGFIX is not set
+# CONFIG_MTD_PMC551_DEBUG is not set
 # CONFIG_MTD_MTDRAM is not set
 
 #
-# MTD drivers for mapped chips
+# Linearly Mapped Flash Device Drivers
 #
 # CONFIG_MTD_CFI is not set
-# CONFIG_MTD_CFI_INTELEXT is not set
-# CONFIG_MTD_CFI_AMDSTD is not set
-# CONFIG_MTD_JEDEC is not set
 # CONFIG_MTD_RAM is not set
 # CONFIG_MTD_ROM is not set
-# CONFIG_MTD_PHYSMAP is not set
+# CONFIG_MTD_JEDEC is not set
 
 #
 # Drivers for chip mappings
 #
-# CONFIG_MTD_MIXMEM is not set
-# CONFIG_MTD_NORA is not set
-# CONFIG_MTD_OCTAGON is not set
-# CONFIG_MTD_PNC2000 is not set
-# CONFIG_MTD_RPXLITE is not set
-# CONFIG_MTD_VMAX is not set
 
 #
 # User modules and translation layers for MTD devices
@@ -122,7 +155,6 @@
 # Plug and Play configuration
 #
 # CONFIG_PNP is not set
-# CONFIG_ISAPNP is not set
 
 #
 # Block devices
@@ -130,20 +162,12 @@
 # CONFIG_BLK_DEV_FD is not set
 # CONFIG_BLK_DEV_XD is not set
 # CONFIG_PARIDE is not set
-# CONFIG_BLK_CPQ_DA is not set
-# CONFIG_BLK_DEV_DAC960 is not set
 # CONFIG_BLK_DEV_LOOP is not set
-# CONFIG_BLK_DEV_NBD is not set
-# CONFIG_BLK_DEV_LVM is not set
-# CONFIG_BLK_DEV_MD is not set
-# CONFIG_MD_LINEAR is not set
-# 

Re: Your message to linux-lvm awaits moderator approval

[Christoph Hellwig]

On Thu, Apr 19, 2001 at 09:56:52PM +0200, [EMAIL PROTECTED] wrote:
> Your mail to 'linux-lvm' with the subject
> 
> Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list
> 
> Is being held until the list moderator can review it for approval.
> 
> The reason it is being held:
> 
> Posting to a restricted list by sender requires approval
> 
> Either the message will get posted to the list, or you will receive
> notification of the moderator's decision.

This doesn't look very open btw.  And I'm a longtime subsriber to linux-lvm...

Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list

[Alan Cox]

> As far as getting patches into the stock kernel, we've been sending patches
> to Linus for over a month now, and none of them have made it in.  Maybe
> someone has some pointers on how we get our code past his filters.

Has it occured to you that some of this might be because the code does stuff
like hide flags in the low bits of addresses and do unchecked kmallocs ?
Things people have tried to send patches for ..

The best way to get stuff to Linus is to feed him changes one at a time and
make them all clean and clearly correct. When I have a big set of changes I
normally start by feeding Linus all the 'fluff' - spelling checks and small
warning fixes. After that its normally easy to pick out changes one at a time
and feed them on.

Given 500 lines of mixed up diff it is very hard to verify the correctness of
anything. 

Alan

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

Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list

[Christoph Hellwig]

On Thu, Apr 19, 2001 at 01:45:20PM -0600, Andreas Dilger wrote:
> I don't think that the subscription is necessarily the only issue.  I'm
> subscribed to all of the LVM mailing lists, and still a lot of what I
> submit (legitimate bug fixes, and not just features/code cleanup) does
> not get added to CVS.

Just alone the fact that you as number one submitter of LVM-bugfixes since
at least 0.8 do not get CVS write access is a sign of closedness for me.

But we discussed that on the sistina list.

> Yes, the no-possible-harm patches like man pages
> went in, but not other stuff.  Also, it doesn't appear that any of the
> LVM changes are making it into the stock kernel, which is basically a
> recepie for disaster.

100% True.  A few days ago I looke at the LVM patches to see what parts
of it could be fed to Linus in small pieces - but it's such a _huge_
mixture of bugfixes, cleanups and move-arounds that it looks pretty
much impossible.

> Basically, I'm at the point where trying to create clean patches from my
> LVM source tree to apply to CVS is so much work it is hardly worth it.

IMHO wou should just put _your_ tree on a sever and submit it (in pieces)
to Linus.  AFAIK all serious users of LVM have used you're patched versions.

Maybe openlvm is a good hood for such a project?

> I'm seriously looking at devoting the time I used to spend on LVM to the
> EVMS project instead.  They (appear to) have in-kernel LVM support working
> already, so no user tools needed for VG/LV activation.  Granted, they don't
> yet have tools to create/modify VG/LVs, but I think I can help them there.

Yes - when looking at what code they produces it looks a _lot_ cleaner than
Linux-LVM and while the papers had serious signs of Overengeering the
actual code looks very good to me - it could just get a little better
integrated with the main kernel, but that's a 2.5 issue.

Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list

[Jens Axboe]

On Thu, Apr 19 2001, AJ Lewis wrote:
> As far as getting patches into the stock kernel, we've been sending patches
> to Linus for over a month now, and none of them have made it in.  Maybe
> someone has some pointers on how we get our code past his filters.

The diff between 2.4.4-pre LVM and your last beta is HUGE. That's a very
good clue why Linus hasn't taken it! Find a bug, fix it, submit diff.
Not find lots of bugs for a month, submit huge diff.

-- 
Jens Axboe

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

Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list

[Rik van Riel]

On Thu, 19 Apr 2001, Andreas Dilger wrote:

> I don't think that the subscription is necessarily the only
> issue.  I'm subscribed to all of the LVM mailing lists, and
> still a lot of what I submit (legitimate bug fixes, and not just
> features/code cleanup) does not get added to CVS.  Yes, the
> no-possible-harm patches like man pages went in, but not other
> stuff.  Also, it doesn't appear that any of the LVM changes are
> making it into the stock kernel, which is basically a recepie
> for disaster.

This is indeed an even bigger problem.  LVM is no longer just
a Sistina product, it is an integrated part of the Linux kernel.

This brings with it the responsability of maintaining the LVM
subsystem which is included in the kernel. I understand that
Sistina may want to do "LVM releases" every once in a while,
but this isn't a development model that makes much sense when
their code has been integrated into the Linux kernel (IMHO).

> The openlvm list may change my mind, I'll see.

If you think any other openly accessible LVM development things
are needed (maybe a CVS tree which can be used by all LVM
developers and not just the Sistina folks?) .. NL.linux.org is
all yours.

regards,

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

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

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

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

Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list

[AJ Lewis]

On Thu, Apr 19, 2001 at 01:45:20PM -0600, Andreas Dilger wrote:
> I don't think that the subscription is necessarily the only issue.  I'm
> subscribed to all of the LVM mailing lists, and still a lot of what I
> submit (legitimate bug fixes, and not just features/code cleanup) does
> not get added to CVS.  Yes, the no-possible-harm patches like man pages
> went in, but not other stuff.  Also, it doesn't appear that any of the
> LVM changes are making it into the stock kernel, which is basically a
> recepie for disaster.

Ok, the issue here is that we're trying to get a release out and so anything
that majorly changes the code is getting shunted aside for the moment.  It
would be stupid to just add everything that comes in on the ML without
review.  Linus does the exact same thing.  I've said this before to you
Andreas, but apparently you feel that you should have final say on whether
your patches go in or not.

As far as getting patches into the stock kernel, we've been sending patches
to Linus for over a month now, and none of them have made it in.  Maybe
someone has some pointers on how we get our code past his filters.

> Basically, I'm at the point where trying to create clean patches from my
> LVM source tree to apply to CVS is so much work it is hardly worth it.
> I'm seriously looking at devoting the time I used to spend on LVM to the
> EVMS project instead.  They (appear to) have in-kernel LVM support working
> already, so no user tools needed for VG/LV activation.  Granted, they don't
> yet have tools to create/modify VG/LVs, but I think I can help them there.
> It appears more likely that EVMS will only support Linux LVM volumes for
> compatibility, and move to a more robust on-disk format for metadata.
>
> The openlvm list may change my mind, I'll see.
> 
> Cheers, Andreas
> -- 
> Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
>  \  would they cancel out, leaving him still hungry?"
> http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
> ___
> linux-lvm mailing list
> [EMAIL PROTECTED]
> http://lists.sistina.com/mailman/listinfo/linux-lvm

-- 
AJ Lewis
Sistina Software Inc.  Voice:  612-379-3951
1313 5th St SE, Suite 111  Fax:612-379-3952
Minneapolis, MN 55414  E-Mail: [EMAIL PROTECTED]
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)

-Begin Obligatory Humorous Quote
Carpe Aptenodytes! (Seize the Penguins!)
-End Obligatory Humorous Quote--

 PGP signature

Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list

[Alan Cox]

> Not to be negative, but isn't Alan the pot calling the kettle black?  You
> use ORBS to block email as well, with no hope of reprieve.  AFAIK, the

I dont stop other people discussing the kernel. Its very very different.

> linux-lvm list has a moderator which _should_ forward legitimate emails
> on to the list.  Maybe they are piling up somewhere, unread?

If they were that would be understandable but they were being rejected. Anyway
it seems to be a finished discussion. 

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

Re: light weight user level semaphores

[Ulrich Drepper]

Alan Cox <[EMAIL PROTECTED]> writes:

> > can libraries use fast semaphores behind the back of the user? They might
> > well want to use the semaphores exactly for things like memory allocator
> > locking etc. But libc certainly cant use fd's behind peoples backs.
> 
> libc is entitled to, and most definitely does exactly that. Take a look at
> things like gethostent, getpwent etc etc.

You are mixing two completely different things.

Functions like gethostent() and catopen() are explicitly allowed to be
implemented using file descriptors.  If this is allowed the standard
contains appropriate wording.

Other functions like setlocale() do use file descriptors, yes, but
these are not kept.  Before the function returns they are closed.
This can cause disruptions in other threads which find descriptors not
allocated sequentially but this has to be taken into account.  Rules
for multi-threaded applications are different.  A single-threaded
application will not see such a difference.

Now, the standards do not allow POSIX mutexes to be implemented using
file descriptors.  The same is true for unnamed POSIX semaphores.  So
Linus is right, though for a different reason than he thought.

The situation is a bit different for named POSIX semaphores.  These
can be implemented using file descriptors.  But they don't have to and
IMO they shouldn't.  A memory reference based semaphore implementation
would allow a named semaphore to be implemented using

  fd = open (name)
  addr = mmap (..fd..)
  close (fd)
  sem_syscall (addr)

i.e., it can be mapped to a memory reference again.

-- 
---.  ,-.   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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list

[Alan Cox]

> All it would have taken was a request and a good reason for doing so, but
> I guess this is one way to do it.  Just don't complain about spam.  :)

I think you'll find several folks who run linux-kernel and other lists like
the linux.nl mailhub more than happy to help there

Alan

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

Re: [repost] Announce: Linux-OpenLVM mailing list

[Martin K. Petersen]

> "Jens" == Jens Axboe <[EMAIL PROTECTED]> writes:

Jens> First one gets a mail saying that the mail sent is queued for
Jens> moderator approval, since I'm not on the list. Then later a
Jens> second mail arrives, saying the mail has been rejected by the
Jens> moderator.

Yep.  Same here.  Latest and greatest...

---8<---
From: [EMAIL PROTECTED]
Subject: Your message to linux-lvm awaits moderator approval
To: [EMAIL PROTECTED]
Date: Tue, 10 Apr 2001 22:02:40 +0200

Your mail to 'linux-lvm' with the subject

Re: [linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 Beta 7 available at
www.sistina.com

Is being held until the list moderator can review it for approval.
---8<---

Now, I held my breath until the following day...

---8<---
From: [EMAIL PROTECTED]
Subject: Request to mailing list linux-lvm rejected
To: [EMAIL PROTECTED]
Date: Wed, 11 Apr 2001 17:32:36 +0200

Your request to the linux-lvm mailing list

Posting of your message titled "Re: [linux-lvm] *** ANNOUNCEMENT
*** LVM 0.9.1 Beta 7 available at www.sistina.com"

has been rejected by the list moderator.  The moderator gave the
following reason for rejecting your request:

"Non-members are not allowed to post messages to this list."
---8<---

Since there is such a long delay between the two mails, it's obvious
that there is human intervention involved.  And when an on-topic mail
is rejected by the moderator, well... go figure.

And this isn't the first time this has happened to me and several
others.  By far...

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
[EMAIL PROTECTED], http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

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

Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list

[Andreas Dilger]

AJ Lewis writes:
> On Thu, Apr 19, 2001 at 08:02:50PM +0100, Alan Cox wrote:
> > Well their approach to patches that fix bugs is to reject emails. They've
> > done that to stuff I've reported any many others. So there is a problem.
> > And it's kind of hard to discuss a problem when you are being moderated
> > out of existance.

Not to be negative, but isn't Alan the pot calling the kettle black?  You
use ORBS to block email as well, with no hope of reprieve.  AFAIK, the
linux-lvm list has a moderator which _should_ forward legitimate emails
on to the list.  Maybe they are piling up somewhere, unread?

> Hmm...i guess there is a communication issue here.  It sounds like the
> message that our ML server was sending was misleading.  We were not
> rejecting mail because of content.  The ML server was rejecting it because
> the address was not subscribed.  Our idea was that we don't want spam. 
> If it's completely unmoderated, then we will get a *lot* of spam.

I don't think that the subscription is necessarily the only issue.  I'm
subscribed to all of the LVM mailing lists, and still a lot of what I
submit (legitimate bug fixes, and not just features/code cleanup) does
not get added to CVS.  Yes, the no-possible-harm patches like man pages
went in, but not other stuff.  Also, it doesn't appear that any of the
LVM changes are making it into the stock kernel, which is basically a
recepie for disaster.

Basically, I'm at the point where trying to create clean patches from my
LVM source tree to apply to CVS is so much work it is hardly worth it.
I'm seriously looking at devoting the time I used to spend on LVM to the
EVMS project instead.  They (appear to) have in-kernel LVM support working
already, so no user tools needed for VG/LV activation.  Granted, they don't
yet have tools to create/modify VG/LVs, but I think I can help them there.
It appears more likely that EVMS will only support Linux LVM volumes for
compatibility, and move to a more robust on-disk format for metadata.

The openlvm list may change my mind, I'll see.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-lvm] Re: [repost] Announce: Linux-OpenLVM mailing list

[AJ Lewis]

The list is now open.  I've talked to our admin and he's opening it up.
Send me e-mail if it doesn't work, 'cause something else is broken.

All it would have taken was a request and a good reason for doing so, but
I guess this is one way to do it.  Just don't complain about spam.  :)

Regards,
AJ Lewis

On Thu, Apr 19, 2001 at 01:29:27PM -0500, AJ Lewis wrote:
> It is unfortunate that this could not have been resolved in a more mature
> manner.  Saying "I don't like the way somebody is doing something.  I won't
> bother to talk to them about it, I'll just flame them and try to undermine
> their work." is not acceptable.  It would have been nice if you'd actually
> tried to work this out instead of handling it this way.
> 
> Regards,
> AJ Lewis
> 
> On Thu, Apr 19, 2001 at 07:51:52PM +0200, Jes Sorensen wrote:
> > Hi
> > 
> > I would like to announce the creation of the openlvm mailing list for
> > discussion about maintenance and further development of the Linux
> > Logical Volume Manager (LVM).
> > 
> > The new mailing list is named linux-openlvm and hosted at
> > nl.linux.org, you can subscribe to the list by posting to
> > [EMAIL PROTECTED] and postings should go to
> > [EMAIL PROTECTED] The list is unmoderated and open to
> > postings from individuals who are not subscribed to the list as it is
> > good practice for all open development lists.
> > 
> > We have found it necessary to create the new list as the current LVM
> > development proces is closed and does not take input from the
> > community. We have experienced numerous incidents of postings to the
> > old mailing list with patches, on topic questions and comments about
> > the LVM code that have been rejected by the list moderator. We find
> > this completely unacceptable just as it is hindering development that
> > a development mailing list is being so mismoderated.
> > 
> > Please welcome the new list and join in on the development and
> > discussions.
> > 
> > Sincerly,
> > Jens Axboe
> > Arjan van de Ven
> > Martin Petersen
> > Rik van Riel
> > Jes Sorensen
> > -
> > Linux-openlvm: open list for LVM on Linux
> > Archive:   http://mail.nl.linux.org/linux-openlvm/
> > 
> 
> 
> -- 
> AJ Lewis
> Sistina Software Inc.  Voice:  612-379-3951
> 1313 5th St SE, Suite 111  Fax:612-379-3952
> Minneapolis, MN 55414  E-Mail: [EMAIL PROTECTED]
> http://www.sistina.com
> 
> Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
> Get my key at: http://www.sistina.com/~lewis/gpgkey
>  (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)
> 
> -Begin Obligatory Humorous Quote
> Error: Keyboard not attached. Press F1 to continue.
> -End Obligatory Humorous Quote--



-- 
AJ Lewis
Sistina Software Inc.  Voice:  612-379-3951
1313 5th St SE, Suite 111  Fax:612-379-3952
Minneapolis, MN 55414  E-Mail: [EMAIL PROTECTED]
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)

-Begin Obligatory Humorous Quote
Your mouse has moved. Windows NT must be restarted for the change to take
effect. Reboot now? [ OK ]
-End Obligatory Humorous Quote--

 PGP signature

Re: [repost] Announce: Linux-OpenLVM mailing list

[Jes Sorensen]

> "AJ" == AJ Lewis <[EMAIL PROTECTED]> writes:

AJ> On Thu, Apr 19, 2001 at 09:17:29PM +0200, Jes Sorensen wrote:
>> This was tried, trust me. We didn't create this list because
>> someone forgot to respond to a single posting. As we wrote in the
>> announcement there has been too many incidents: At least two people
>> got kicked off the old lvm list for posting comments about the
>> latest release using lower bits in pointers to store data. Other
>> people have posted patches for serious bugs like NULL pointer
>> dereferences and the postings were denied. Another person
>> complained about the behavior and got no response.

AJ> What are you talking about???  Got kicked off?  If so, it was not
AJ> intentional, I can assure you.  That would just be stupid.  As far
AJ> as patches being rejected, refer to the e-mail I just sent.

[EMAIL PROTECTED] got unsubscribed when he posted the complaint about
storing data in lower bits of pointers. Riel got bumped when he
followed up on the same topic.

Jens just told me he has at least one denied reponse from the
moderator (just got the below from him):

"Your request to the linux-lvm mailing list
 Posting of your message titled "Re: 2.4.3-ac{6,7} LVM hang"
 has been rejected by the list moderator."

>> For modules included in the Linux kernel, an open development forum
>> is a minimum requirement.

AJ> Who asked for this?  Who did you talk to?  I haven't seen anything
AJ> to this effect for months.

A moderated list is not an open environment. Had this been for a
Sistina only product I wouldn't have any problem with it, but this is
for an integrated part of the Linux kernel.

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

Re: [repost] Announce: Linux-OpenLVM mailing list

[AJ Lewis]

On Thu, Apr 19, 2001 at 09:35:51PM +0200, Jes Sorensen wrote:
> > ">" == AJ Lewis <[EMAIL PROTECTED]> writes:
> >> Hmm...i guess there is a communication issue here.  It sounds like
> >> the message that our ML server was sending was misleading.  We were
> >> not rejecting mail because of content.  The ML server was rejecting
> >> it because the address was not subscribed.  Our idea was that we
> >> don't want spam.  If it's completely unmoderated, then we will get
> >> a *lot* of spam.
> 
> The mail states it's been forwarded to the moderator, yes I just got
> one. Thats another issue here, Cc'ing a closed mailing list when
> posting to an open list like linux-kernel is rude (but thats just a
> minor issue in this discussion).

The list is open now.  Sorry for the inconvenience and misunderstanding.
Hopefully this is a non-issue now.

> >> Did anyone bother to e-mail the list admins?  Perhaps it was too
> >> difficult to figure out who to mail about this, but I know for a
> >> fact that Rik van Riel and Jens Axboe could post to
> >> [EMAIL PROTECTED]  It would have been nice if they had
> >> mentioned something to us.
> 
> I know that Jens posted to linux-lvm-admin two days ago and didn't get
> a response.

Hmm...our admin was testing LVM + GFS on his laptop on linux 2.4 and lost
some mail due to file corruption a couple of days ago...that's probably what
happened to it.  :(

Regards,
-- 
AJ Lewis
Sistina Software Inc.  Voice:  612-379-3951
1313 5th St SE, Suite 111  Fax:612-379-3952
Minneapolis, MN 55414  E-Mail: [EMAIL PROTECTED]
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)

-Begin Obligatory Humorous Quote
Choose a job you love, and you will never have to work a day in your life.
-End Obligatory Humorous Quote--

 PGP signature

Re: [repost] Announce: Linux-OpenLVM mailing list

[Jes Sorensen]

> ">" == AJ Lewis <[EMAIL PROTECTED]> writes:

>> Hmm...i guess there is a communication issue here.  It sounds like
>> the message that our ML server was sending was misleading.  We were
>> not rejecting mail because of content.  The ML server was rejecting
>> it because the address was not subscribed.  Our idea was that we
>> don't want spam.  If it's completely unmoderated, then we will get
>> a *lot* of spam.

The mail states it's been forwarded to the moderator, yes I just got
one. Thats another issue here, Cc'ing a closed mailing list when
posting to an open list like linux-kernel is rude (but thats just a
minor issue in this discussion).

>> Did anyone bother to e-mail the list admins?  Perhaps it was too
>> difficult to figure out who to mail about this, but I know for a
>> fact that Rik van Riel and Jens Axboe could post to
>> [EMAIL PROTECTED]  It would have been nice if they had
>> mentioned something to us.

I know that Jens posted to linux-lvm-admin two days ago and didn't get
a response.

>> The openlvm list is open to existing LVM hackers too..

>> True, but it seems silly to duplicate the load if it's not
>> necessary.

Right now there is no load because the postings aren't getting
through at all.

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

Re: Dead symbol elimination, stage 1

[rmk]

Eric S. Raymond writes:
> > The ones that show up in arch/arm/def-configs are purely because I've been
> > keeping back the updates to these files; each time the config structure
> > changes, I get a nice big patch from people with the new def-configs.  I
> > didn't want to inflict this too regularly on people.
> 
> I read this as "I haven't fixed the problem because..."  not as "Don't
> fix the problem."  Please be more explicit next time so I won't step on
> your toes?

"Keeping back" implies that _I_ have the necessary changes and have not
passed them on.

> I'm rather disturbed by the amount of crap kxref is turning up -- I
> expected dozens of dodgy bits, but I'm finding hundreds.  We need to pay
> better attention to janitorial issues like this if the kernel code
> isn't going to degenerate into an unmaintainable hairball.

The correct thing to do is to ensure that you are starting with an
up to date copy of the defconfig files.  You can do this by passing them
through CML1's 'make oldconfig' before passing them through kxref.

Working with old files does nobody any good.

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

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

Re: light weight user level semaphores

[Alan Cox]

> I fail to see how this works across processes.  How can you generate a
> file descriptor for this pipe in a second process which simply shares
> some memory with the first one?  The first process is passive: no file
> descriptor passing must be necessary.

mknod foo p. Or use sockets (although AF_UNIX sockets are higher latency)
Thats why I suggested using flock - its name based. Whether you mkstemp()
stuff and pass it around isnt something I care about

Files give you permissions for free too

> Note that semaphores need not always be shared between processes.
> This is a property the user has to choose.  So the implementation can
> be easier in the normal intra-process case.

So you have unix file permissions on them ?


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

Re: [repost] Announce: Linux-OpenLVM mailing list

[Jens Axboe]

On Thu, Apr 19 2001, AJ Lewis wrote:
> Did anyone bother to e-mail the list admins?  Perhaps it was too difficult
> to figure out who to mail about this, but I know for a fact that Rik van
> Riel and Jens Axboe could post to [EMAIL PROTECTED]  It would have been
> nice if they had mentioned something to us.

First one gets a mail saying that the mail sent is queued for moderator
approval, since I'm not on the list. Then later a second mail arrives,
saying the mail has been rejected by the moderator.

I then reply to the admin mail listed, in not-so-kind words (yes I was
pissed off). Haven't heard anything.

> > The openlvm list is open to existing LVM hackers too..
> 
> True, but it seems silly to duplicate the load if it's not necessary.

It's necessary in that we need an open list.

-- 
Jens Axboe

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

Re: Oscillations in disk write compaction, poor interactive performance

[Giuliano Pochini]

> The problem is that at the low point in the cycle, the machine is
> unusable.  It is utterly unresponsive until the writes complete, which can
> take a very long time (in the case of the ppc machine, several minutes!)
> Anything that does disk I/O will block for a long time - having 'ls' take
> two minutes is not a good thing.

Can you chack how much cpu time do dbflush and kswapd get ?

> 2.2 does not exhibit this behaviour.

2.2 is much worse IMO.

Bye.

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

Re: Next gen PM interface

[John Fremlin]

Patrick Mochel <[EMAIL PROTECTED]> writes:

[...]

> > > I can see at least two types of events - (forgive the lack of colorful
> > > terminology) passive and active. Passive events are simply providing
> > > status updates, much like the events described above. These are simply so
> > > some UI can notify the user of things like a low battery or detection of
> > > an AC adapter. These can be handled in much the same way as described
> > > above.
> > 
> > No they can't. They only happen once. Battery status exists all the
> > time.
> 
> Yes they can. My point was they can be handled from userspace in the
> same way that battery status does - by doing a select on a file in
> /proc or /dev. Once in a while (or constantly) they get data from
> the kernel - battery status, AC change, etc - that can be then
> translated and displayed in the UI.

I think these events have a generic utility not specific to UIs. In
particular, when ones battery is running out, one would quite like the
event manager to be notified. As is currently the case with e.g. apmd.

Polling on battery charge left or battery voltage/current is different
from this, surely? Why should such programs have to be notified that
the battery was low? The event itself is pretty useless if you're
doing polling but there is no point throwing it away, in case you
aren't.

[...]

-- 

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

Re: light weight user level semaphores

[Ulrich Drepper]

Linus Torvalds <[EMAIL PROTECTED]> writes:

> Looks good to me. Anybody want to try this out and test some benchmarks?

I fail to see how this works across processes.  How can you generate a
file descriptor for this pipe in a second process which simply shares
some memory with the first one?  The first process is passive: no file
descriptor passing must be necessary.

How these things are working elsewhere is that a memory address
(probably a physical address) is used as a token.  The semaphore
object is placed in the memory shared by the processes and the virtual
address is passed in the syscall.

Note that semaphores need not always be shared between processes.
This is a property the user has to choose.  So the implementation can
be easier in the normal intra-process case.

In any case all kinds of user-level operations are possible as well
and all the schemes suggested for dealing with the common case without
syscalls can be applied here as well.

-- 
---.  ,-.   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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [repost] Announce: Linux-OpenLVM mailing list

[AJ Lewis]

On Thu, Apr 19, 2001 at 09:17:29PM +0200, Jes Sorensen wrote:
> This was tried, trust me. We didn't create this list because someone
> forgot to respond to a single posting. As we wrote in the announcement
> there has been too many incidents: At least two people got kicked off
> the old lvm list for posting comments about the latest release using
> lower bits in pointers to store data. Other people have posted patches
> for serious bugs like NULL pointer dereferences and the postings were
> denied. Another person complained about the behavior and got no
> response.

What are you talking about???  Got kicked off?  If so, it was not
intentional, I can assure you.  That would just be stupid.  As far as
patches being rejected, refer to the e-mail I just sent.

> For modules included in the Linux kernel, an open development forum is
> a minimum requirement.

Who asked for this?  Who did you talk to?  I haven't seen anything to this
effect for months.

-- 
AJ Lewis
Sistina Software Inc.  Voice:  612-379-3951
1313 5th St SE, Suite 111  Fax:612-379-3952
Minneapolis, MN 55414  E-Mail: [EMAIL PROTECTED]
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)

-Begin Obligatory Humorous Quote
Over and over I find being redundant is key to success
in the art of redundancy - Jay Armstrong
-End Obligatory Humorous Quote--

 PGP signature

Re: ext2 inode size (on-disk)

[Andreas Dilger]

Al writes:
> > I had always assumed that it would be a power-of-two size, but since it
> > is an undocumented option to mke2fs, I suppose it was never really
> > intended to be used.  It appears, however, that the mke2fs code
> > doesn't do ANY checking on the parameter, so you could concievably make
> > the inode size SMALLER than the current size, and this would DEFINITELY
> > be bad as well.
> 
> In some sense it does - it dies if you've passed it not a power of two ;-)
> I don't think that segfault is a good way to report the problem, though...

Strange, I run "mke2fs -I 192 /dev/hdc2" and do not have a segfault or any
problems with e2fsck or debugfs on the resulting filesystem.  I'm running
1.20-WIP, but I don't think anything was changed in this area for some time.

However, looking at the output from dumpe2fs shows it is packing inodes
across block boundaries (inode_size = 192, inodes_per_group = 16144,
inode_blocks_per_group = 757).  It is also not filling the last inode
table block (which would give us 16149 inodes).

Also, looking at the disk, it shows garbage data in the space after the
end of the normal inode, and ext2 should always zero-fill unused fields.

Basically, packing inodes across block boundaries is TOTALLY broken.
This can lead to all sorts of data corruption issues if one block is
written to disk, and the other is not.  For that matter, the same would
hold true with any not-power-of-two inode size.  In this case, the
inode will still be crossing a hard disk sector boundary, and have the
(small) possibility that part of the inode is written and part is not.

In this light, the safe inode sizes are 128 (current size), 256, and 512.

> > mke2fs will always set up the filesystem this way, and there is no real
> > reason NOT to do that.  If you are using a filesystem block for the inode
> > table, it is pointless to leave part of it empty, because you can't use
> > it for anything else anyways.
> 
> It's not that simple - if you need 160 bytes per inode rounding it up
> to the next power of two will lose a lot. On 4Kb fs it will be
> 16 inodes per block instead of 25 - 36% loss...

What I was getting at, is that no matter what size of inode we are using,
we should ALWAYS fill the last inode table block as full as possible.  Once
you have allocated a block to the inode table, it should be filled with
as many inodes as fit in a single block.  To do anything else is a waste.

For example, with 160 byte inodes, and a 4k inode table block, we can fit

4096 / 160 = 25 inodes into this block (with 96 bytes remaining)

There is no reason to only have 1 or 2 or 17 inodes in this block.  If we
assume we are not crossing a block boundary with the inode, then
inodes_per_group = n * inodes_per_block, where n = number of inode blocks.

Cheers, Andreas

PS - is this a code cleanup issue, or do you have some reason that you want
 to increase the inode size?
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [repost] Announce: Linux-OpenLVM mailing list

[AJ Lewis]

On Thu, Apr 19, 2001 at 08:02:50PM +0100, Alan Cox wrote:
> Well their approach to patches that fix bugs is to reject emails. They've done
> that to stuff I've reported any many others. So there is a problem. And its
> kind of hard to discuss a problem when you are being moderated out of existance.

Hmm...i guess there is a communication issue here.  It sounds like the
message that our ML server was sending was misleading.  We were not
rejecting mail because of content.  The ML server was rejecting it because
the address was not subscribed.  Our idea was that we don't want spam. 
If it's completely unmoderated, then we will get a *lot* of spam.

Did anyone bother to e-mail the list admins?  Perhaps it was too difficult
to figure out who to mail about this, but I know for a fact that Rik van
Riel and Jens Axboe could post to [EMAIL PROTECTED]  It would have been
nice if they had mentioned something to us.

> The openlvm list is open to existing LVM hackers too..

True, but it seems silly to duplicate the load if it's not necessary.

Regards,
-- 
AJ Lewis
Sistina Software Inc.  Voice:  612-379-3951
1313 5th St SE, Suite 111  Fax:612-379-3952
Minneapolis, MN 55414  E-Mail: [EMAIL PROTECTED]
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)

-Begin Obligatory Humorous Quote
Sometimes I have a difficult time handling myself in social situations.
I just start scampering around neurotically, frantically jumping all
over guests. I think it all goes back to when I was raised in the wild
by miniature schnauzers.
-End Obligatory Humorous Quote--

 PGP signature

Re: [repost] Announce: Linux-OpenLVM mailing list

[Martin K. Petersen]

> "AJ" == AJ Lewis <[EMAIL PROTECTED]> writes:

AJ> It is unfortunate that this could not have been resolved in a more
AJ> mature manner.  

Personally, I find it exceedingly immature that my postings get
moderated to the bitbucket every time I report a bug in your code.

This is simply not the way we are working in the Linux community, and
you guys will either have to change your closed development model or
deal with a fork of the LVM tree...

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
[EMAIL PROTECTED], http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

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

Re: [repost] Announce: Linux-OpenLVM mailing list

[Jes Sorensen]

> ">" == AJ Lewis <[EMAIL PROTECTED]> writes:

>> It is unfortunate that this could not have been resolved in a more
>> mature manner.  Saying "I don't like the way somebody is doing
>> something.  I won't bother to talk to them about it, I'll just
>> flame them and try to undermine their work." is not acceptable.  It
>> would have been nice if you'd actually tried to work this out
>> instead of handling it this way.

This was tried, trust me. We didn't create this list because someone
forgot to respond to a single posting. As we wrote in the announcement
there has been too many incidents: At least two people got kicked off
the old lvm list for posting comments about the latest release using
lower bits in pointers to store data. Other people have posted patches
for serious bugs like NULL pointer dereferences and the postings were
denied. Another person complained about the behavior and got no
response.

For modules included in the Linux kernel, an open development forum is
a minimum requirement.

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

Re: Next gen PM interface

[Patrick Mochel]

> > > > (1) Battery status, power status, UPS status polling. It
> > > > should be possible for lots of processes to do this
> > > > simultaneously. [That does not prohibit a single process
> > > > querying the kernel and all the others querying it.]
> > > 
> > > Solution. Have a bunch of procfs or dev nodes each giving info on a
> > > particular power source, like now, but vaguely standardise the output.
> 
> [...]
> 
> > I can see at least two types of events - (forgive the lack of colorful
> > terminology) passive and active. Passive events are simply providing
> > status updates, much like the events described above. These are simply so
> > some UI can notify the user of things like a low battery or detection of
> > an AC adapter. These can be handled in much the same way as described
> > above.
> 
> No they can't. They only happen once. Battery status exists all the
> time.

Yes they can. My point was they can be handled from userspace in the same
way that battery status does - by doing a select on a file in /proc or
/dev. Once in a while (or constantly) they get data from the kernel -
battery status, AC change, etc - that can be then translated and displayed
in the UI.

-pat

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

Re: Next gen PM interface

[John Fremlin]

 Patrick Mochel <[EMAIL PROTECTED]> writes:

[...]

> > Solution. Have a special procfs or dev node that any number of people
> > can select(2) or read(2). Protocol text. Syntax:
> > 
> >  
> > 
> > Where  is one of the strings
> > OFF,SLEEP,WAKE,EMERGENCY,POWERCHANGE,  is a space character,
> >  is a word signifying the kernel pm interface responsible
> > for generating th event,  is an arbitrary string.  is
> > a newline character \n.
> > 
> > This is flexible and simple. It means a reasonable default behaviour
> > can be suggested by the kernel (OFF,SLEEP,etc.) for events that
> > userspace doesn't know about and yet userspace can choose fine grained
> > policy and provide helpful error messages based on the exact event by
> > checking the description.
> 
> First, Is there any reason why the kernel should do more text processing?

Kernel does no text processing. Kernel merely gives text instead of
magic numbers to the stream of bytes.

> It is better left for user space. Besides, enumerated values
> translated by userspace seems more efficient than copying and
> parsing strings.

Oh? Do you honestly believe there will be in any way a detectable
difference?

> Having a daemon that sits in user space and waits for system events
> (denoted by enumerated values in some /proc or /dev file) seems simple
> enough. 

Yes, but text strings are simpler. You don't have to export magic
numbers in some kernel header (causing no end of woe). You can just
cat /proc/pm/events to the console and understand it, and just about
anybody with the rudiments of knowledge about programming in any
language can write an event handler - even without having to know
hardly anything about or look at the kernel source because the
interface is so transparent and simple.

> When it gets the request to power down, it handles calling init and
> whatever else it wants to do. When it gets notification that the
> laptop was plugged into the base station, it can look for new
> devices and load the modules for them.

Exactly. Right. Bang on target - but with text strings you can do it
in a line or two of perl, and the kernel side is not made any more
complex.

> This can also handle the user-dictated policy, which I haven't seen
> discussed yet. For instance, when you close the lid or press the power
> button, the system can enter suspend or it can power off. If the kernel
> simply exported the event, the userspace daemon could simply check its
> config file for the proper thing to do and initiate the transition.

Exactly what I was suggesting. In this case, you'd get the event

SLEEP ACPI Laptop case closed

and your perl script could do something vaguely like

/ACPI Laptop case closed$/ && system "shutdown -p now";

to turn the machine off instead of sleeping.


[...]

> > sleep - writing a number n (text encoded) sends the device to
> > sleep in such a way that it can be back in action in no less
> > than n seconds after a wakeup call on a vague guess
> > basis. Reading from it gets errno.

Probably microseconds would be a more useful unit.

> > off - writing to this node puts device in deepest possible
> > sleep, possibly losing state. Reading gets errno.
> 
> Sure, but does it really make sense for anything but system sleep
> states? ACPI defines a mechnanism for runtime power management,
> where devices will go into sleep states if they're not being
> used. Given proper heuristics for controlling this, user-initiated
> suspension of individual devices doesn't seem necessary. And, given
> a proper abstraction in the PM layer, this should be extendable, to
> some extent, to other low-level PM schemes.


OK, so add another node, something like

boredafter - writing a number of milliseconds tells device to
go to some sort of sleep after that time has elapsed without
activity.

-- 

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

Re: kernel oops

[Ronald Bultje]

On 2001.04.19 21:04:26 +0200 Alan Cox wrote:
> > Is blackbox broken? Or is this a kernel bug? Or a bug in the nvidia
> > drivers?
> > I hope you can fix it (if it is a kernel bug)...
> 
> Only Nvidia can help you. Reproduce the problem from a boot where the
> nvidia
> drivers have never been loaded and then its interesting. Is the box
> stable 
> with 2.2 ?

Yes (i.e. no crashes because of this and never any X-lockup/-crash).
I'll try the non-nvidia boot and send a report to nvidia.

Ronald Bultje

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

Re: SCSI tape test results

[Olaf Titz]

> Still have to test copying from a SCSI disk on the same bus as the
> tape drive.

Done (tar c/tar d), no corruption.

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

Re: light weight user level semaphores

[Olaf Titz]

> problems: just _how_ high woul dyou move it? Would it potentially disturb
> an application that opens thousands of files, and knows that they get
> consecutive file descriptors? Which is _legal_ and well-defined in UNIX.

Only if you close them before. The process may have been started with
arbitrary fds open.

> say "if you use fast semaphores, they use file descriptors and you should
> no longer depend on consecutive fd's".

Which you cannot anyway. Already some library routines can open fds
although they don't explicitly say so and don't have to in all
implementations, like openlog() or all the get*by*() stuff (or even
dlopen()), so you are never sure to know which or how many FDs you
actually have open.

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

Re: [repost] Announce: Linux-OpenLVM mailing list

[Alan Cox]

> It is unfortunate that this could not have been resolved in a more mature
> manner.  Saying "I don't like the way somebody is doing something.  I won't
> bother to talk to them about it, I'll just flame them and try to undermine
> their work." is not acceptable.  It would have been nice if you'd actually
> tried to work this out instead of handling it this way.

Well their approach to patches that fix bugs is to reject emails. They've done
that to stuff I've reported any many others. So there is a problem. And its
kind of hard to discuss a problem when you are being moderated out of existance.

The openlvm list is open to existing LVM hackers too..

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

Re: kernel oops

[Alan Cox]

> Is blackbox broken? Or is this a kernel bug? Or a bug in the nvidia
> drivers?
> I hope you can fix it (if it is a kernel bug)...

Only Nvidia can help you. Reproduce the problem from a boot where the nvidia
drivers have never been loaded and then its interesting. Is the box stable 
with 2.2 ?

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

Re: Next gen PM interface

[John Fremlin]

 Patrick Mochel <[EMAIL PROTECTED]> writes:

> > > IMHO the pm interface should be split up as following:
> > 
> > Nobody has disagreed: therefore this separation must be perfect ;-)
> 
> I once heard that patience is a virtue. :)
> 
> > > (1) Battery status, power status, UPS status polling. It
> > > should be possible for lots of processes to do this
> > > simultaneously. [That does not prohibit a single process
> > > querying the kernel and all the others querying it.]
> > 
> > Solution. Have a bunch of procfs or dev nodes each giving info on a
> > particular power source, like now, but vaguely standardise the output.

[...]

> I can see at least two types of events - (forgive the lack of colorful
> terminology) passive and active. Passive events are simply providing
> status updates, much like the events described above. These are simply so
> some UI can notify the user of things like a low battery or detection of
> an AC adapter. These can be handled in much the same way as described
> above.

No they can't. They only happen once. Battery status exists all the
time.

[...]


-- 

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

Re: [kbuild-devel] Re: Cross-referencing frenzy

[Peter Samuelson]

  [esr]
> > CONFIG_SOUND_YMPCI: arch/ppc/configs/power3_defconfig 
>arch/arm/def-configs/footbridge arch/arm/def-configs/rpc arch/arm/def-configs/lart 
>arch/arm/def-configs/shark

[jgarzik]
> typo, that should be ...YMFPCI.

Actually it's not a typo (although the fix is the same).  The old
"SB-compatible mode" Yamaha driver was indeed CONFIG_SOUND_YMPCI.  That
allowed the two to coexist while the native-mode driver matured.

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

Re: [repost] Announce: Linux-OpenLVM mailing list

[Jens Axboe]

On Thu, Apr 19 2001, AJ Lewis wrote:
> It is unfortunate that this could not have been resolved in a more mature
> manner.  Saying "I don't like the way somebody is doing something.  I won't
> bother to talk to them about it, I'll just flame them and try to undermine
> their work." is not acceptable.  It would have been nice if you'd actually
> tried to work this out instead of handling it this way.

LVM concerns us all now that it is not just an addon, but actually a
part of the kernel. Rejecting mails and reports from users and
developers who just might be able to lend you a hand fixing bugs, is not
just counter productive it's downright rude!

Besides, I didn't think the posting was flame material at all. If
nothing else, it's a wake up call.

-- 
Jens Axboe

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

Re: [repost] Announce: Linux-OpenLVM mailing list

[Rik van Riel]

On Thu, 19 Apr 2001, AJ Lewis wrote:

> It is unfortunate that this could not have been resolved in a more mature
> manner.  Saying "I don't like the way somebody is doing something.  I won't
> bother to talk to them about it, I'll just flame them and try to undermine
> their work." is not acceptable.  It would have been nice if you'd actually
> tried to work this out instead of handling it this way.

We tried, but the last time we had something to say about your
code the message wasn't allowed on your list.

Now that the code is in the kernel, we are of the opinion that
it is no longer acceptable to censor messages when they are too
critical about the LVM source code. This beast is in the kernel,
now we'd better be allowed to talk about the source code and
maintain the thing.

regards,

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

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

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

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

Re: [repost] Announce: Linux-OpenLVM mailing list

[Jeff Garzik]

AJ Lewis wrote:
> It is unfortunate that this could not have been resolved in a more mature
> manner.  Saying "I don't like the way somebody is doing something.  I won't
> bother to talk to them about it, I'll just flame them and try to undermine
> their work." is not acceptable.  It would have been nice if you'd actually
> tried to work this out instead of handling it this way.

Maybe he did, but his attempt got moderated down...  :)

-- 
Jeff Garzik   | "The universe is like a safe to which there is a
Building 1024 |  combination -- but the combination is locked up
MandrakeSoft  |  in the safe."-- Peter DeVries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

kernel oops

[Ronald Bultje]

Hi there,

when I have given my computer a 'quite heavy load' in X, it will sometimes
suddenly, without much reason at that moment itself, stop working... Ie,
the 'stop' itself can happen when the computer isn't even being worked on,
but five minutes after I've done some video editing (using a DC10+ with
Serguei Miridonov's zoran driver)...
Either I get:
- a full computer crash
- or it will segfault everything I try to do
# reboot
Segmentation fault
# ls
Segmentation fault
#
- or the kernel will oops.
Uptimes longer than a few days are usually out of the question. I've
experienced it since I switched over to kernel 2.4.x

I currently use kernel 2.4.3, on a Pentium II 400 MHz, 128 MB RAM, with
redhat 7.0. I also use the nvidia.com drivers for my videocard (tnt2),
maybe that's of importance...

the oops:

kernel BUG at page_alloc.c:81!
invalid operand: 
CPU:0
EIP:0010:[]
EFLAGS: 00010282
eax: 001f   ebx: c11bbb6c   ecx: 0001   edx: c0223a28
esi:    edi:    ebp:    esp: c7affe84
ds: 0018   es: 0018   ss: 0018
Process blackbox (pid: 782, stackpage=c7aff000)
Stack: c01ec68b c01ec7b9 0051  c11bbb6c c11bbb6c c0127dbc
c11bbb6c 
   0001 c11bbb6c 000c c7b6c310 c012a68a c11bbb6c 0202
 
   c11efe48 c11efe48 c11bbb6c 0027 c011f184 c11bbb6c 0003
 
Call Trace: [] [] [] []
[] [] [] 
   [] [] 

Code: 0f 0b 83 c4 0c 8b 43 18 83 e0 20 74 16 6a 53 68 b9 c7 1e c0 
kernel BUG at page_alloc.c:81!
invalid operand: 
CPU:0
EIP:0010:[]
EFLAGS: 00013286
eax: 001f   ebx: c1209868   ecx: 0001   edx: c0223a28
esi:    edi:    ebp:    esp: c1a95e98
ds: 0018   es: 0018   ss: 0018
Process X (pid: 777, stackpage=c1a95000)
Stack: c01ec68b c01ec7b9 0051  c1209868 c1209868 c0127dbc
c1209868 
    c1209868 00161000 c4101644 c012a68a c1209868 0010
c584f440 
   c012c368 c584f54c c1209868 0004 c011f184 c1209868 002f
 
Call Trace: [] [] [] []
[] [] [] 
   [] [] [] [] []
[] 

Code: 0f 0b 83 c4 0c 8b 43 18 83 e0 20 74 16 6a 53 68 b9 c7 1e c0 

Ksymoops output when I last had the oops (only for first one, I lost the
other one):

ksymoops 2.3.4 on i686 2.4.3.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.3/ (default)
 -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Reading Oops report from the terminal

kernel BUG at page_alloc.c:81!
invalid operand: 
CPU:0
EIP:0010:[]
EFLAGS: 00010282
eax: 001f   ebx: c11bbb6c   ecx: 0001   edx: c0223a28
esi:    edi:    ebp:    esp: c7affe84
ds: 0018   es: 0018   ss: 0018
Process blackbox (pid: 782, stackpage=c7aff000)
Stack: c01ec68b c01ec7b9 0051  c11bbb6c c11bbb6c c0127dbc
c11bbb6c
   0001 c11bbb6c 000c c7b6c310 c012a68a c11bbb6c 0202

   c11efe48 c11efe48 c11bbb6c 0027 c011f184 c11bbb6c 0003

Call Trace: [] [] [] []
[] [] 
[] []

Code: 0f 0b 83 c4 0c 8b 43 18 83 e0 20 74 16 6a 53 68 b9 c7 1e c0



invalid operand: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 001f   ebx: c11bbb6c   ecx: 0001   edx: c0223a28
esi:    edi:    ebp:    esp: c7affe84
ds: 0018   es: 0018   ss: 0018
Process blackbox (pid: 782, stackpage=c7aff000)
Stack: c01ec68b c01ec7b9 0051  c11bbb6c c11bbb6c c0127dbc
c11bbb6c
   0001 c11bbb6c 000c c7b6c310 c012a68a c11bbb6c 0202

   c11efe48 c11efe48 c11bbb6c 0027 c011f184 c11bbb6c 0003

Call Trace: [] [] [] []
[] [] [] []
Code: 0f 0b 83 c4 0c 8b 43 18 83 e0 20 74 16 6a 53 68 b9 c7 1e c0

>>EIP; c01298df <__free_pages_ok+af/310>   <=
Trace; c0127dbc 
Trace; c012a68a 
Trace; c011f184 
Trace; c012142f 
Trace; c012072a 
Trace; c01214fd 
Code;  c01298df <__free_pages_ok+af/310>
 <_EIP>:
Code;  c01298df <__free_pages_ok+af/310>   <=
   0:   0f 0b ud2a  <=
Code;  c01298e1 <__free_pages_ok+b1/310>
   2:   83 c4 0c  add$0xc,%esp
Code;  c01298e4 <__free_pages_ok+b4/310>
   5:   8b 43 18  mov0x18(%ebx),%eax
Code;  c01298e7 <__free_pages_ok+b7/310>
   8:   83 e0 20  and$0x20,%eax
Code;  c01298ea <__free_pages_ok+ba/310>
   b:   74 16 je 23 <_EIP+0x23> c0129902
<__free_pages_ok+d2/310>
Code;  c01298ec <__free_pages_ok+bc/310>
   d:   6a 53 push   $0x53

Problems with i2c-matroxfb and latest kernel

[German Gomez Garcia]

Hello,

After downloading latest 2.4.3-ac9 kernel and compiling it I found
that when I insert the i2c-matroxfb module, the modprobe utility
completely monopolize the system during about a minute everything gets
really slow and it seems that it do something on the virtual consoles
during this time, because if I change virtual console my monitor gets out
of sync for an instant, the same that happens when you have the consoles
set to different resolution/refresh rate. Everything gets fixed after it
load. 

Any clue?

- german

PS: Please CC'd to me as I'm not subscribed to the list.
-
German Gomez Garcia | "This isn't right.  This isn't even wrong."
<[EMAIL PROTECTED]> | -- Wolfgang Pauli

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

Re: [repost] Announce: Linux-OpenLVM mailing list

[AJ Lewis]

It is unfortunate that this could not have been resolved in a more mature
manner.  Saying "I don't like the way somebody is doing something.  I won't
bother to talk to them about it, I'll just flame them and try to undermine
their work." is not acceptable.  It would have been nice if you'd actually
tried to work this out instead of handling it this way.

Regards,
AJ Lewis

On Thu, Apr 19, 2001 at 07:51:52PM +0200, Jes Sorensen wrote:
> Hi
> 
> I would like to announce the creation of the openlvm mailing list for
> discussion about maintenance and further development of the Linux
> Logical Volume Manager (LVM).
> 
> The new mailing list is named linux-openlvm and hosted at
> nl.linux.org, you can subscribe to the list by posting to
> [EMAIL PROTECTED] and postings should go to
> [EMAIL PROTECTED] The list is unmoderated and open to
> postings from individuals who are not subscribed to the list as it is
> good practice for all open development lists.
> 
> We have found it necessary to create the new list as the current LVM
> development proces is closed and does not take input from the
> community. We have experienced numerous incidents of postings to the
> old mailing list with patches, on topic questions and comments about
> the LVM code that have been rejected by the list moderator. We find
> this completely unacceptable just as it is hindering development that
> a development mailing list is being so mismoderated.
> 
> Please welcome the new list and join in on the development and
> discussions.
> 
> Sincerly,
> Jens Axboe
> Arjan van de Ven
> Martin Petersen
> Rik van Riel
> Jes Sorensen
> -
> Linux-openlvm: open list for LVM on Linux
> Archive:   http://mail.nl.linux.org/linux-openlvm/
> 


-- 
AJ Lewis
Sistina Software Inc.  Voice:  612-379-3951
1313 5th St SE, Suite 111  Fax:612-379-3952
Minneapolis, MN 55414  E-Mail: [EMAIL PROTECTED]
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)

-Begin Obligatory Humorous Quote
Error: Keyboard not attached. Press F1 to continue.
-End Obligatory Humorous Quote--

 PGP signature

Re: light weight user level semaphores

[Alexander Viro]

On Thu, 19 Apr 2001, Linus Torvalds wrote:

> 
> 
> On Thu, 19 Apr 2001, Alexander Viro wrote:
> >
> > Ehh... Non-lazy variant is just read() and write() as down_failed() and
> > up_wakeup() Lazy... How about
> 
> Looks good to me. Anybody want to try this out and test some benchmarks?

Ugh. It doesn't look good for me. s/MAX_INT/MAX_INT>>1/ or we will
get into trouble on anything that goes into spin_and_lose. Window is
pretty narrow (notice that lost_it is OK - we only need to worry
about somebody coming in after winner drives Lock from 1 to 0
and before it gets it from 0 to MAX_INT), but we can get into serious
trouble if schedule() will hit that window.

MAX_INT/2 should be enough to deal with that, AFAICS.

However, I would _really_ like to get that code reviewed from the memory
access ordering POV. Warning: right now I'm half-asleep, so the thing can
very well be completely bogus in that area. Extra eyes would be certainly
welcome.

Al

PS: ->Lock should be set to 1 when we initialize semaphore. Destroying
semaphore should do
if (sem->Lock > 1) {
close(sem->writer);
close(sem->reader);
}

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

Re: Dead symbol elimination, stage 1

[Eric S. Raymond]

David Woodhouse <[EMAIL PROTECTED]>:
> 
> [EMAIL PROTECTED] said:
> >  I read this as "I haven't fixed the problem because..."  not as
> > "Don't fix the problem."  Please be more explicit next time so I won't
> > step on your toes? 
> 
> "This is not a problem, please don't \"fix\" it".

But it is.  The more false positives I get in the dead-symbol reports,
the harder it will be to spot real problems like that business in the 
ARM kernel.c file.

I grant you this wasn't a problem before I wrote kxref.py, but it is
one now.  New tools create new opportunities, but they sometimes require
better discipline and working practices to be useful.  This is one of
those cases.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

"I hold it, that a little rebellion, now and then, is a good thing, and as 
necessary in the political world as storms in the physical."
-- Thomas Jefferson, Letter to James Madison, January 30, 1787
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: KERNEL: assertion (tp->lost_out == 0) failed at tcp_input.c(1202):tcp_remove_reno_sacks

[Kurt Roeckx]

On Sat, Apr 14, 2001 at 04:42:54PM +0200, Kurt Roeckx wrote:
> While running 2.4.3, I saw the following message a few times:
> 
> KERNEL: assertion (tp->lost_out == 0) failed at
> tcp_input.c(1202):tcp_remove_reno_sacks

I've been running tcpdump for some time, and get the message 2
times again today.

Apr 19 19:05:17 thunderbird kernel: KERNEL: assertion (tp->lost_out == 0)
failed at tcp_input.c(1202):tcp_remove_reno_sacks
Apr 19 19:07:18 thunderbird kernel: KERNEL: assertion (tp->lost_out == 0)
failed at tcp_input.c(1202):tcp_remove_reno_sacks

I'm going to start with the second one, because there was alot less trafic at that 
time.

19:07:17.571150 3ffe:80c0:220::b.6667 > 3ffe:400:290:100:2a0:c9ff:feaa:635e.1060: . 
1921:3141(1220) ack 1811 win 5680 (len 1240, hlim 64)
19:07:17.571163 3ffe:80c0:220::b.6667 > 3ffe:400:290:100:2a0:c9ff:feaa:635e.1060: P 
3141:3341(200) ack 1811 win 5680 (len 220, hlim 64)
19:07:17.572431 3ffe:401:0:1::16:2 > 3ffe:80c0:220::b: icmp6: too big 1280
 (len 1240, hlim 63)
19:07:17.645807 3ffe:8010:91::26.2237 > 3ffe:80c0:220::b.6667: S [tcp sum ok] 
2268475160:2268475160(0) win 32660  
(len 40, hlim 61)
19:07:17.816319 3ffe:1001:211:80:baba:beba:deca:ceca.33258 > 3ffe:80c0:220::b.6667: . 
[tcp sum ok] 290:290(0) ack 14134 win 34160 (len 20, hlim 60)
19:07:18.186433 3ffe:400:290:100:2a0:c9ff:feaa:635e.1060 > 3ffe:80c0:220::b.6667: . 
[tcp sum ok] 1811:1811(0) ack 3341 win 15620 (len 20, hlim 59)
19:07:18.186465 3ffe:80c0:220::b.6667 > 3ffe:400:290:100:2a0:c9ff:feaa:635e.1060: . 
3341:4561(1220) ack 1811 win 5680 (len 1240, hlim 64)
19:07:18.886979 3ffe:400:290:100:2a0:c9ff:feaa:635e.1060 > 3ffe:80c0:220::b.6667: . 
[tcp sum ok] 1811:1811(0) ack 4561 win 17040 (len 20, hlim 59)
19:07:18.887047 3ffe:80c0:220::b.6667 > 3ffe:400:290:100:2a0:c9ff:feaa:635e.1060: P 
4561:4761(200) ack 1811 win 5680 (len 220, hlim 64)
19:07:19.236653 3ffe:8010:14::1:dead:beef.3207 > 3ffe:80c0:220::b.6667: S [tcp sum ok] 
2702352776:2702352776(0) win 31680  (len 40, hlim 60)

As you can see, during that second there only was trafic of 1 connection.

Some part of the tcpdump around the time of the first:

19:05:16.783871 3ffe:8010:7:43:1000:dead:dead:2.3292 > 3ffe:80c0:220::b.6667: P
[tcp sum ok] 134:152(18) ack 1104 win 31520 (len 38, hlim 60)
19:05:16.783923 3ffe:80c0:220::b.6667 > 3ffe:8010:7:43:1000:dead:dead:2.3292: .
[tcp sum ok] 3321:3321(0) ack 152 win 5680 (len 20, hlim 64)
19:05:16.849145 3ffe:400:680::::15.1117 > 3ffe:80c0:220::b.6667: . [tcp
sum ok] 124:124(0) ack 38670 win 32660 (len 20, hlim 61)
19:05:16.921394 3ffe:8060:100::26:2 > 3ffe:80c0:220::b: icmp6: too big 1280
 (len 1240, hlim 63)
19:05:16.972044 3ffe:8191::2.1044 > 3ffe:80c0:220::b.6667: . [tcp sum ok] 73:73(0) ack 
8784 win 17040 (len 20, hlim 60)
19:05:16.972143 3ffe:80c0:220::b.6667 > 3ffe:8191::2.1044: P 8784:8984(200) ack
73 win 5680 (len 220, hlim 64)
19:05:17.030129 3ffe:80c0:220::b.6667 > 3ffe:b00:4011:a::3.1880: P 76:1163(1087) ack 
213 win 5680 (len 1107, hlim 64)
19:05:17.062691 3ffe:80c0:220::b.6667 > 3ffe:b00:4011:a::3.1880: P 1163:2383(1220) ack 
213 win 5680 (len 1240, hlim 64)
19:05:17.097973 3ffe:80c0:220::b. > 3ffe:1200:3028:82ca:4:4:4:6.2160: P 
205:819(614) ack 256 win 5680 (len 634, hlim 64)
19:05:17.098080 3ffe:80c0:220::b. > 3ffe:8114:2000:1d0::4.2856: P 3811:4198(387) 
ack 85 win 5680 (len 407, hlim 64)
19:05:17.098135 3ffe:80c0:220::b.6667 > 3ffe:400:680::::15.1117: . 
38670:40090(1420) ack 124 win 5680 (len 1440, hlim 64)
19:05:17.098151 3ffe:80c0:220::b.6667 > 3ffe:400:680::::15.1117: P 
40090:40197(107) ack 124 win 5680 (len 127, hlim 64)
19:05:17.098860 3ffe:80c0:220::b.6667 > 3ffe:80e8:140:200::1.3899: P 158:1049(891) ack 
85 win 5680 (len 911, hlim 64)
19:05:17.106040 3ffe:80c0:220::b.6667 > 3ffe:80c0:220::19.1998: P 5851:6543(692) ack 
475 win 5680 (len 712, hlim 64)
19:05:17.108239 3ffe:80c0:220::b.4126 > 3ffe:1001:340::6.113: S [tcp sum ok] 
2552352896:2552352896(0) win 5680  (len 40, hlim 64)
19:05:17.258572 3ffe:401:0:1::16:2 > 3ffe:80c0:220::b: icmp6: too big 1280
 (len 1240, hlim 63)
19:05:17.258633 3ffe:80c0:220::b.6667 > 3ffe:400:680::::15.1117: . 
38670:39890(1220) ack 124 win 5680 (len 1240, hlim 64)
19:05:17.321612 3ffe:8010:7:43:1000:dead:dead:2.3292 > 3ffe:80c0:220::b.6667: P
152:244(92) ack 1104 win 31520 (len 112, hlim 60)
19:05:17.321636 3ffe:80c0:220::b.6667 > 3ffe:8010:7:43:1000:dead:dead:2.3292: .
[tcp sum ok] 3321:3321(0) ack 244 win 5680 (len 20, hlim 64)
19:05:17.364448 3ffe:80c0:220::b.6667 > 3ffe:400:680:11:::aa15.3452: P [tcp
sum ok] 770:789(19) ack 67 win 5680 (len 39, hlim 64)
19:05:17.370740 3ffe:400:680:11:::aa15.3452 > 3ffe:80c0:220::b.6667: P [tcp
sum ok] 51:67(16) ack 770 win 48800 (len 36, hlim 60)
19:05:17.370761 3ffe:80c0:220::b.6667 > 3ffe:400:680:11:::aa15.3452: . [tcp
sum ok] 789:789(0) ack 67 win 5680  (len 32, hlim
64)
19:05:17.390719 3ffe:8114:2000:1d0::4.2856 > 3ffe:80c0:220::b.: . [tcp sum ok] 

Re: Is there a way to turn file caching off ?

[John Lenton]

On Thu, Apr 19, 2001 at 10:21:14AM +0200, Helge Hafting wrote:
> A program may know its own access pattern, but it don't usually know
> future access patterns.  Well, backing up the entire fs could benefit
> from a something like this, you probably won't need the backup again
> soon.  But this is hard to know in many other cases.

tar --please-leave-this-in-cache-pretty-please ?

-- 
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
Si los bugs te abruman, cierra tu Windows.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dead symbol elimination, stage 1

[Eric S. Raymond]

David Woodhouse <[EMAIL PROTECTED]>:
> 
> > -# CONFIG_MTD_SBC_MEDIAGX is not set
> > -# CONFIG_MTD_ELAN_104NC is not set
> > -# CONFIG_MTD_SA1100 is not set
> > -# CONFIG_MTD_DC21285 is not set
> > -# CONFIG_MTD_CSTM_CFI_JEDEC is not set
> >  # CONFIG_MTD_JEDEC is not set
> >  # CONFIG_MTD_MIXMEM is not set
> >  # CONFIG_MTD_OCTAGON is not set
> >  # CONFIG_MTD_VMAX is not set
> > -# CONFIG_MTD_NAND is not set
> > -# CONFIG_MTD_NAND_SPIA is not set
> 
> Please don't. People using some of these embedded architectures need to
> update to the latest MTD code (which includes those options) anyway, and I'm
> hoping to merge that all into 2.4 shortly.

Well, then, those symbols will stop being dead.  But note this: *none of
those MTD symbols are set*.  So the effect of losing these would not be
to lose any CML1 information, merely to make a few more questions visible
during make oldconfig.  This is a feature, not a bug.
 
> They're not doing any harm, are they?

They are helping create a dense thicket in which real bugs can hide.

The cross-referencer has already turned up several genuine errors, 
and will doubtless turn up more -- but if the reports are stuffed
full of meaningless crap about undead defconfig symbols that aren't 
even set, the genuine errors are going to be hard to notice.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

In every country and in every age, the priest has been hostile to
liberty. He is always in alliance with the despot, abetting his abuses
in return for protection to his own.
-- Thomas Jefferson, 1814
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dead symbol elimination, stage 1

[David Woodhouse]

[EMAIL PROTECTED] said:
>  I read this as "I haven't fixed the problem because..."  not as
> "Don't fix the problem."  Please be more explicit next time so I won't
> step on your toes? 

"This is not a problem, please don't \"fix\" it".


--
dwmw2


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

Re: ext2 inode size (on-disk)

[Alexander Viro]

On Thu, 19 Apr 2001, Andreas Dilger wrote:

> Al, you write:
> > Erm... Folks, can ->s_inode_size be not a power of 2? Both
> > libext2fs and kernel break in that case. Example:
> > 
> > dd if=/dev/zero of=foo bs=1024 count=20480
> > mkfs -I 192 foo
> 
> I had always assumed that it would be a power-of-two size, but since it
> is an undocumented option to mke2fs, I suppose it was never really
> intended to be used.  It appears, however, that the mke2fs code
> doesn't do ANY checking on the parameter, so you could concievably make
> the inode size SMALLER than the current size, and this would DEFINITELY
> be bad as well.

In some sense it does - it dies if you've passed it not a power of two ;-)
I don't think that segfault is a good way to report the problem, though...

Problem with mkfs is obvious, but kernel side is also shady - we could
have cleaner code if we assumed that inode size is power of 2. As it
is, we have a code in read_super() that checks for size == 128 _and_
code that was apparently writen in assumption that it can be not a
power of 2. However, if that was the really the goal, we fail - code
in ext2_read_inode() actually would break with such sizes.

In other words, the real question is what the hell are we trying to
do there. If we want code that deals with sizes that are not powers of 2
we need to change ext2_read_inode() and friends. It wouldn't be
hard. OTOH, if we guarantee that inode size will always remain a power of
2 we can simplify the thing. In any case current situation doesn't
make much sense. The only question is direction of fix.

Could those who introduced ->s_inode_size tell what use had been intended?

> mke2fs will always set up the filesystem this way, and there is no real
> reason NOT to do that.  If you are using a filesystem block for the inode
> table, it is pointless to leave part of it empty, because you can't use
> it for anything else anyways.

It's not that simple - if you need 160 bytes per inode rounding it up
to the next power of two will lose a lot. On 4Kb fs it will be
16 inodes per block instead of 25 - 36% loss...

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

Re: Children first in fork

[Linus Torvalds]

In article <9bn3sr$fer$[EMAIL PROTECTED]>,
Wichert Akkerman <[EMAIL PROTECTED]> wrote:
>
>What you can do is what strace does: insert a loop instruction after
>the fork or clone call and remove that when the call returns.

You're probably even better off just intercepting the fork, turning it
into a clone, and setting the CLONE_PTRACE option. Which (together with
tracing the parent, which you will obviously be doing already in order
to do all this in the first place) will nicely cause the child to get an
automatic SIGSTOP _and_ be already traced.

Not that I've tested it myself.

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

Re: Dead symbol elimination, stage 1

[Eric S. Raymond]

Russell King <[EMAIL PROTECTED]>:
> On Thu, Apr 19, 2001 at 01:19:44PM -0400, Eric S. Raymond wrote:
> > The following patch cleans dead symbols out of the defconfigs in the 2.4.4pre4
> > source tree.  It corrects a typo involving CONFIG_GEN_RTC.  Another typo
> > involving CONFIG_SOUND_YMPCI doesn't need to be corrected, as the symbol
> > is never set in these files.
> 
> As I said previously, please don't eliminate the ones on arch/arm -
> you'll prevent me from sending a patch to Alan without a _lot_ more
> work.

Um...this is what you said:

> The ones that show up in arch/arm/def-configs are purely because I've been
> keeping back the updates to these files; each time the config structure
> changes, I get a nice big patch from people with the new def-configs.  I
> didn't want to inflict this too regularly on people.

I read this as "I haven't fixed the problem because..."  not as "Don't
fix the problem."  Please be more explicit next time so I won't step on
your toes?

I don't care whether it's you or me that cleans up this part of the
dead-symbol mess.  I'm just trying to get it cleaned up.  

I'm rather disturbed by the amount of crap kxref is turning up -- I
expected dozens of dodgy bits, but I'm finding hundreds.  We need to pay
better attention to janitorial issues like this if the kernel code
isn't going to degenerate into an unmaintainable hairball.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

False is the idea of utility that sacrifices a thousand real advantages for
one imaginary or trifling inconvenience; that would take fire from men because
it burns, and water because one may drown in it; that has no remedy for evils
except destruction.  The laws that forbid the carrying of arms are laws of
such a nature.  They disarm only those who are neither inclined nor determined
to commit crimes.
-- Cesare Beccaria, as quoted by Thomas Jefferson's Commonplace book
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

No Subject

[Marcelo Tosatti]

Hi Linus, 

The following patch fixes the OOM deadlock condition caused by
prune_icache(), and also improves its performance significantly.

The OOM deadlock can happen because prune_icache() tries to sync _all_
dirty inodes (under PF_MEMALLOC) on the system before trying to free a
portion of the clean unused inodes.

The patch also changes prune_icache() to free clean inodes first, and then
sync _unused_ ones if needed. In case (nr_free_pages < freepages.low) the
code writes one inode synchronously and returns (to avoid the OOM
deadlock).

Could you please include this patch in your tree?

Thanks 


--- fs/inode.c~ Thu Apr 12 21:16:35 2001
+++ fs/inode.c  Thu Apr 12 21:49:56 2001
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /*
  * New inode.c implementation.
@@ -197,6 +199,34 @@
inodes_stat.nr_unused--;
 }
 
+static inline void __sync_one(struct inode *inode, int sync)
+{
+   unsigned dirty;
+
+   list_del(>i_list);
+   list_add(>i_list, atomic_read(>i_count)
+   ? _in_use
+   : _unused);
+
+   /* Set I_LOCK, reset I_DIRTY */
+   dirty = inode->i_state & I_DIRTY;
+   inode->i_state |= I_LOCK;
+   inode->i_state &= ~I_DIRTY;
+   spin_unlock(_lock);
+
+   filemap_fdatasync(inode->i_mapping);
+
+   /* Don't write the inode if only I_DIRTY_PAGES was set */
+   if (dirty & (I_DIRTY_SYNC | I_DIRTY_DATASYNC))
+   write_inode(inode, sync);
+
+   filemap_fdatawait(inode->i_mapping);
+
+   spin_lock(_lock);
+   inode->i_state &= ~I_LOCK;
+   wake_up(>i_wait);
+}
+
 static inline void sync_one(struct inode *inode, int sync)
 {
if (inode->i_state & I_LOCK) {
@@ -206,29 +236,7 @@
iput(inode);
spin_lock(_lock);
} else {
-   unsigned dirty;
-
-   list_del(>i_list);
-   list_add(>i_list, atomic_read(>i_count)
-   ? _in_use
-   : _unused);
-   /* Set I_LOCK, reset I_DIRTY */
-   dirty = inode->i_state & I_DIRTY;
-   inode->i_state |= I_LOCK;
-   inode->i_state &= ~I_DIRTY;
-   spin_unlock(_lock);
-
-   filemap_fdatasync(inode->i_mapping);
-
-   /* Don't write the inode if only I_DIRTY_PAGES was set */
-   if (dirty & (I_DIRTY_SYNC | I_DIRTY_DATASYNC))
-   write_inode(inode, sync);
-
-   filemap_fdatawait(inode->i_mapping);
-
-   spin_lock(_lock);
-   inode->i_state &= ~I_LOCK;
-   wake_up(>i_wait);
+   __sync_one(inode, sync);
}
 }
 
@@ -236,10 +244,42 @@
 {
struct list_head * tmp;
 
-   while ((tmp = head->prev) != head)
+   while ((tmp = head->prev) != head) 
sync_one(list_entry(tmp, struct inode, i_list), 0);
 }
 
+static inline int try_to_sync_unused_list(struct list_head *head)
+{
+   struct list_head *tmp = head;
+   struct inode *inode;
+
+   while ((tmp = tmp->prev) != head) {
+   inode = list_entry(tmp, struct inode, i_list);
+
+   if (!(inode->i_state & I_LOCK) 
+   && !atomic_read(>i_count)) {
+   /* 
+* We're under PF_MEMALLOC here, and syncing the 
+* inode may have to allocate memory. To avoid
+* running into a OOM deadlock, we write one 
+* inode synchronously and stop syncing in case 
+* we're under freepages.low
+*/
+
+   int sync = nr_free_pages() < freepages.low;
+   __sync_one(inode, sync);
+   if (sync) 
+   return 0;
+   /* 
+* __sync_one moved the inode to another list,
+* so we have to start looking from the list head.
+*/
+   tmp = head;
+   }
+   }
+   return 1;
+}
+
 /**
  * sync_inodes
  * @dev: device to sync the inodes from.
@@ -273,13 +313,14 @@
 /*
  * Called with the spinlock already held..
  */
-static void sync_all_inodes(void)
+static void try_to_sync_unused_inodes(void)
 {
struct super_block * sb = sb_entry(super_blocks.next);
for (; sb != sb_entry(_blocks); sb = sb_entry(sb->s_list.next)) {
if (!sb->s_dev)
continue;
-   sync_list(>s_dirty);
+   if (!try_to_sync_unused_list(>s_dirty))
+   break;
}
 }
 
@@ -506,13 +547,12 @@
 {
LIST_HEAD(list);
struct list_head *entry, *freeable = 
-   int count = 0;
+   int count = 

[repost] Announce: Linux-OpenLVM mailing list

[Jes Sorensen]

Hi

For some reason this one didn't make it through in the first try ;-(

Jes




Hi

I would like to announce the creation of the openlvm mailing list for
discussion about maintenance and further development of the Linux
Logical Volume Manager (LVM).

The new mailing list is named linux-openlvm and hosted at
nl.linux.org, you can subscribe to the list by posting to
[EMAIL PROTECTED] and postings should go to
[EMAIL PROTECTED] The list is unmoderated and open to
postings from individuals who are not subscribed to the list as it is
good practice for all open development lists.

We have found it necessary to create the new list as the current LVM
development proces is closed and does not take input from the
community. We have experienced numerous incidents of postings to the
old mailing list with patches, on topic questions and comments about
the LVM code that have been rejected by the list moderator. We find
this completely unacceptable just as it is hindering development that
a development mailing list is being so mismoderated.

Please welcome the new list and join in on the development and
discussions.

Sincerly,
Jens Axboe
Arjan van de Ven
Martin Petersen
Rik van Riel
Jes Sorensen
-
Linux-openlvm: open list for LVM on Linux
Archive:   http://mail.nl.linux.org/linux-openlvm/

Re: Dead symbol elimination, stage 1

[David Woodhouse]

> -# CONFIG_MTD_SBC_MEDIAGX is not set
> -# CONFIG_MTD_ELAN_104NC is not set
> -# CONFIG_MTD_SA1100 is not set
> -# CONFIG_MTD_DC21285 is not set
> -# CONFIG_MTD_CSTM_CFI_JEDEC is not set
>  # CONFIG_MTD_JEDEC is not set
>  # CONFIG_MTD_MIXMEM is not set
>  # CONFIG_MTD_OCTAGON is not set
>  # CONFIG_MTD_VMAX is not set
> -# CONFIG_MTD_NAND is not set
> -# CONFIG_MTD_NAND_SPIA is not set

Please don't. People using some of these embedded architectures need to
update to the latest MTD code (which includes those options) anyway, and I'm
hoping to merge that all into 2.4 shortly.

They're not doing any harm, are they?

--
dwmw2


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

Re: Lost O_NONBLOCK (Bug?)

[Philippe Troin]

Jason Gunthorpe <[EMAIL PROTECTED]> writes:

> On 12 Apr 2001, Philippe Troin wrote:
> 
> > Apt I guess ? It has a very strange behavior when backgrounded...
> 
> Not really, just want it tries to run dpkg it hangs.
> 
> > > The last read was after the process was forgrounded. The read waits
> > > forever, the non-block flag seems to have gone missing. It is also a
> > > little odd I think that it repeated to get SIGTTIN which was never
> > > actually delivered to the program.. Shouldn't SIGTTIN suspend the process?
>  
> > Strace can perturbate signal delivery, especially for terminal-related
> > signals, I wouldn't trust it...
> 
> I know, the problem still happens without strace.

Do you have a snippet that can reproduce the problem ? Does this
happens only with 2.4, or both 2.2 and 2.4 have the problem ?

> > O_NONBLOCK is not lost... Attempting to read from the controlling tty
> > even from a O_NONBLOCK descriptor will trigger SIGTTIN.
> 
> I don't really care about the SIGTTIN, what bugs me is that the read that
> happens after the process has been foregrounded blocks - and that should
> not be.

True.

8< snip >8

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

Re: Dead symbol elimination, stage 1

[Russell King]

On Thu, Apr 19, 2001 at 01:19:44PM -0400, Eric S. Raymond wrote:
> The following patch cleans dead symbols out of the defconfigs in the 2.4.4pre4
> source tree.  It corrects a typo involving CONFIG_GEN_RTC.  Another typo
> involving CONFIG_SOUND_YMPCI doesn't need to be corrected, as the symbol
> is never set in these files.

As I said previously, please don't eliminate the ones on arch/arm -
you'll prevent me from sending a patch to Alan without a _lot_ more
work.

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

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

Re: ext2 inode size (on-disk)

[Andreas Dilger]

Al, you write:
>   Erm... Folks, can ->s_inode_size be not a power of 2? Both
> libext2fs and kernel break in that case. Example:
> 
> dd if=/dev/zero of=foo bs=1024 count=20480
> mkfs -I 192 foo

I had always assumed that it would be a power-of-two size, but since it
is an undocumented option to mke2fs, I suppose it was never really
intended to be used.  It appears, however, that the mke2fs code
doesn't do ANY checking on the parameter, so you could concievably make
the inode size SMALLER than the current size, and this would DEFINITELY
be bad as well.

> corrupts memory and segfaults. Reason: ext2_read_inode() (same problem
> is present in the kernel version of said beast) finds inode offset within
> cylinder group piece of inode table, splits it into block*block_size+offset,
> reads the block and works with the structure at given offset.

However, we _should_ be safe against this, because ext2_read_super() does:

if (le32_to_cpu(es->s_rev_level) == EXT2_GOOD_OLD_REV) {
sb->u.ext2_sb.s_inode_size = EXT2_GOOD_OLD_INODE_SIZE;
sb->u.ext2_sb.s_first_ino = EXT2_GOOD_OLD_FIRST_INO;
} else {
sb->u.ext2_sb.s_inode_size = le16_to_cpu(es->s_inode_size);
sb->u.ext2_sb.s_first_ino = le32_to_cpu(es->s_first_ino);
if (sb->u.ext2_sb.s_inode_size != EXT2_GOOD_OLD_INODE_SIZE) {
printk ("EXT2-fs: unsupported inode size: %d\n",
sb->u.ext2_sb.s_inode_size);
goto failed_mount;
}
}

Are you talking about user-space code or kernel code when you say it is
segfaulting and corrupting memory?

>   a) require inode size to be a power of 2

This would be my preferred solution, makes the math in the kernel a lot
faster.  Should probably be put into mke2fs for safety, and also checked
when/if we ever allow the kernel to mount a filesystem with non-power-of-2
inode sizes.

> PS: can we assume that inodes_per_group is a multiple of inodes_per_block
> or it isn't guaranteed?

mke2fs will always set up the filesystem this way, and there is no real
reason NOT to do that.  If you are using a filesystem block for the inode
table, it is pointless to leave part of it empty, because you can't use
it for anything else anyways.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/   -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PNP BIOS and parport_pc - dma found but not used

[Gunther Mayer]

Pavel Roskin wrote:
...
> 
> There is another interesting line in the log that you didn't quote. The
> driver actually knows about DMA 3:
> 
> 0x378: ECP settings irq=7 dma=3

The parport code only uses DMA when told by the user, so 
insmod parport_pc dma=auto
should to the trick. Parport DMA transfers are considered experimental still,
so this is not the default.

> 
> Just in case, that board is Asus P5A-B with the latest BIOS:
> P5A-B BIOS ver. 1010, 05/31/2000
> 
> For comparison, I took a board with VIA chipset and PhoenixBIOS 4.0
> Release 6.0, and it works properly with another 2.4.3-ac9 kernel:

Fine. With PNPBIOS or ACPI you don't currently need dma=auto.
This is subject to change probably (see above).

> 
> Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
> SMSC Super-IO detection, now testing Ports 2F0, 370 ...
> PnPBIOS: Parport found PNPBIOS PNP0401 at io=0378,0778 irq=7 dma=3
> 0x378: FIFO is 16 bytes
> 0x378: writeIntrThreshold is 8
> 0x378: readIntrThreshold is 8
> 0x378: PWord is 8 bits
> 0x378: Interrupts are ISA-Pulses
> 0x378: ECP port cfgA=0x10 cfgB=0x4b
> 0x378: ECP settings irq=7 dma=3
> parport0: PC-style at 0x378 (0x778), irq 7, dma 3
> [PCSPP,TRISTATE,COMPAT,ECP,DMA]
> parport0: cpp_daisy: aa5500ff(38)
> parport0: assign_addrs: aa5500ff(38)
> parport0: cpp_daisy: aa5500ff(38)
> parport0: assign_addrs: aa5500ff(38)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: light weight user level semaphores

[Linus Torvalds]

On Thu, 19 Apr 2001, Alexander Viro wrote:
>
> Ehh... Non-lazy variant is just read() and write() as down_failed() and
> up_wakeup() Lazy... How about

Looks good to me. Anybody want to try this out and test some benchmarks?

There may be problems with large numbers of semaphores, but hopefully that
won't be an issue. And the ability to select/poll on these things might
come in handy for various implementation issues (ie locks with timeouts
etc).

Linus

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

Re: light weight user level semaphores

[Alexander Viro]

On Thu, 19 Apr 2001, Linus Torvalds wrote:

> 
> 
> On Thu, 19 Apr 2001, Alexander Viro wrote:
> >
> > I certainly agree that introducing ioctl() in _any_ API is a shootable
> > offense. However, I wonder whether we really need any kernel changes
> > at all.
> 
> I'd certainly be interested in seeing the pipe-based approach. Especially
> if you make the pipe allocation lazy. That isn'tr trivial (it needs to be
> done right with both up_failed() and down_failed() trying to allocate the
> pipe on contention and using an atomic cmpxchg-style setting if none
> existed before). It has the BIG advantage of working on old kernels, so
> that you don't need to have backwards compatibility cruft in the
> libraries.

Ehh... Non-lazy variant is just read() and write() as down_failed() and
up_wakeup() Lazy... How about

if (Lock <= 1)
goto must_open;
opened:
/* as in non-lazy case */


must_open:
pipe(fd);
lock decl Lock
jg lost_it  /* Already seriously positive - clean up and go */
jl spin_and_lose
/* Lock went from 1 to 0 - go ahead */
reader = fd[0];
writer = fd[1];
Lock = MAX_INT;
goto opened;
spin_and_lose:
/* Won't take long - another guy got to do 3 memory writes */
while (Lock <= 0)
;
lost_it:
lock incl Lock
close(fd[0]);
close(fd[1]);
goto opened;

Al

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

Re: Cross-referencing frenzy

[Eric S. Raymond]

Andreas Dilger <[EMAIL PROTECTED]>:
> Could you make a list that splits the symbols up by each of the above
> failure conditions?  It would make the task of deciding how to fix the
> "problem" more apparent.

There are 32 possible categories.  I need to eyeball them and decide which
ones are significant.
 
> Also, it appears that some of the symbols you are matching are only in
> documentation (which isn't necessarily a bad thing).  I would start with:
> 
> *.[chS] Config.in Makefile Configure.help

There should be few enough of these to fit on one screen.  Over 700 dead
symbols indicates a larger problem.
 
> However, I'm not sure that your reasoning for removing these is correct.
> For example, one symbol that I saw was CONFIG_EXT2_CHECK, which is code
> that used to be enabled in the kernel, but is currently #ifdef'd out with
> the above symbol.  When Ted changed this, he wasn't sure whether we would
> need the code again in the future.  I enable it sometimes when I'm doing
> ext2 development, but it may not be worthy of a separate config option
> that 99.9% of people will just be confused about.

I think things like that don't belong in the CONFIG_ namespace to begin
with.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

"To disarm the people... was the best and most effectual way to enslave them."
-- George Mason, speech of June 14, 1788
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PNP BIOS and parport_pc - dma found but not used

[Gunther Mayer]

Pavel Roskin wrote:
> 
> Hello!
> 
> I've compiled 2.4.3-ac9 with support for PNP BIOS. I understand that this
> is a new feature experimental and the feedback is requested.
> 
> The setting is BIOS is to use irq 7 and dma 3. I normally use "options
> parport_pc io=0x378 irq=7 dma=3" in /etc/modules.conf, but this time I
> commented them out hoping that the driver will ask BIOS.
> 
> Although the kernel can see those settings, the dma is not used by the
> driver. This is the output from dmesg.
> 
> PnPBIOS: Parport found PNPBIOS PNP0401 at io=0378,0778 irq=7 dma=-1
   ^^ culprit !

Send me the raw PNP resource data so I can look into this:

1) Search for the right two-digit PNP handle for device "0104d041":
   cat /proc/bus/pnb/devices
   01  0104d04107:01:000080
   02  0105d04107:00:020180
   03  1005d04107:00:020180
   04  0007d04101:02:000003
   ...

   The number in the first column (here: 01) is the handle
   to be used in step 2.

2) Send cat /proc/bus/pnp/01 | od -tx1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Dead symbol elimination, stage 1

[Eric S. Raymond]

The following patch cleans dead symbols out of the defconfigs in the 2.4.4pre4
source tree.  It corrects a typo involving CONFIG_GEN_RTC.  Another typo
involving CONFIG_SOUND_YMPCI doesn't need to be corrected, as the symbol
is never set in these files.

This completely eliminates one class of dead symbol, that discovered by

kxref.py -f "d&~(c|h|o|m)"

That's 82 broken symbols, so it's a substantial whack.

--- arch/parisc/defconfig   Tue Dec  5 15:29:39 2000
+++ arch/parisc/defconfig   Thu Apr 19 11:03:09 2001
@@ -255,7 +255,7 @@
 # Watchdog Cards
 #
 # CONFIG_WATCHDOG is not set
-CONFIG_GENRTC=y
+CONFIG_GEN_RTC=y
 # CONFIG_INTEL_RNG is not set
 # CONFIG_NVRAM is not set
 # CONFIG_RTC is not set
--- arch/alpha/defconfigSun Mar  4 17:30:18 2001
+++ arch/alpha/defconfig.tweakedThu Apr 19 12:23:56 2001
@@ -378,7 +378,6 @@
 # CONFIG_NE2K_PCI is not set
 # CONFIG_NE3210 is not set
 # CONFIG_ES3210 is not set
-# CONFIG_RTL8129 is not set
 # CONFIG_8139TOO is not set
 # CONFIG_SIS900 is not set
 # CONFIG_EPIC100 is not set
--- arch/arm/def-configs/a5kMon Nov 27 20:07:59 2000
+++ arch/arm/def-configs/a5k.tweakedThu Apr 19 12:23:56 2001
@@ -527,7 +527,6 @@
 #
 # Kernel hacking
 #
-CONFIG_FRAME_POINTER=y
 CONFIG_DEBUG_ERRORS=y
 CONFIG_DEBUG_USER=y
 # CONFIG_DEBUG_INFO is not set
--- arch/arm/def-configs/assabetMon Nov 27 20:07:59 2000
+++ arch/arm/def-configs/assabet.tweakedThu Apr 19 12:23:56 2001
@@ -54,8 +54,6 @@
 # CONFIG_SA1100_XP860 is not set
 # CONFIG_SA1100_PANGOLIN is not set
 CONFIG_ANGELBOOT=y
-CONFIG_SA1100_FREQUENCY_SCALE=y
-# CONFIG_SA1100_VOLTAGE_SCALE is not set
 # CONFIG_ARCH_ACORN is not set
 # CONFIG_FOOTBRIDGE is not set
 # CONFIG_FOOTBRIDGE_HOST is not set
@@ -83,8 +81,6 @@
 # PCMCIA/CardBus support
 #
 CONFIG_PCMCIA=y
-# CONFIG_PCMCIA_DEBUG is not set
-CONFIG_SA1100_PCMCIA=y
 CONFIG_VIRTUAL_BUS=y
 CONFIG_NET=y
 CONFIG_SYSVIPC=y
@@ -338,8 +334,6 @@
 CONFIG_SERIAL_SA1100=y
 CONFIG_SERIAL_SA1100_CONSOLE=y
 CONFIG_SA1100_DEFAULT_BAUDRATE=9600
-CONFIG_TOUCHSCREEN_UCB1200=y
-# CONFIG_TOUCHSCREEN_BITSY is not set
 CONFIG_UNIX98_PTYS=y
 CONFIG_UNIX98_PTY_COUNT=32
 
@@ -381,7 +375,6 @@
 # CONFIG_FTAPE is not set
 # CONFIG_AGP is not set
 # CONFIG_DRM is not set
-# CONFIG_PCMCIA_SERIAL is not set
 
 #
 # File systems
@@ -517,7 +510,6 @@
 CONFIG_DUMMY_CONSOLE=y
 # CONFIG_FB_CYBER2000 is not set
 CONFIG_FB_SA1100=y
-# CONFIG_FB_MQ200 is not set
 # CONFIG_FB_VIRTUAL is not set
 # CONFIG_FBCON_ADVANCED is not set
 CONFIG_FBCON_CFB2=y
@@ -536,8 +528,6 @@
 # Sound
 #
 CONFIG_SOUND=y
-CONFIG_SOUND_UDA1341=y
-# CONFIG_SOUND_SA1100_SSP is not set
 # CONFIG_SOUND_CMPCI is not set
 # CONFIG_SOUND_EMU10K1 is not set
 # CONFIG_SOUND_FUSION is not set
@@ -561,7 +551,6 @@
 #
 # Kernel hacking
 #
-CONFIG_FRAME_POINTER=y
 CONFIG_DEBUG_ERRORS=y
 CONFIG_DEBUG_USER=y
 # CONFIG_DEBUG_INFO is not set
--- arch/arm/def-configs/brutus Mon Nov 27 20:07:59 2000
+++ arch/arm/def-configs/brutus.tweaked Thu Apr 19 12:23:56 2001
@@ -37,14 +37,11 @@
 # CONFIG_SA1100_CERF is not set
 # CONFIG_SA1100_BITSY is not set
 # CONFIG_SA1100_LART is not set
-# CONFIG_SA1100_THINCLIENT is not set
 # CONFIG_SA1100_GRAPHICSCLIENT is not set
 # CONFIG_SA1100_NANOENGINE is not set
 # CONFIG_SA1100_VICTOR is not set
 # CONFIG_SA1100_XP860 is not set
 CONFIG_ANGELBOOT=y
-# CONFIG_SA1100_FREQUENCY_SCALE is not set
-# CONFIG_SA1100_VOLTAGE_SCALE is not set
 # CONFIG_ARCH_ACORN is not set
 # CONFIG_FOOTBRIDGE is not set
 # CONFIG_FOOTBRIDGE_HOST is not set
@@ -151,8 +148,6 @@
 # CONFIG_VT_CONSOLE is not set
 CONFIG_SERIAL_SA1100=y
 CONFIG_SERIAL_SA1100_CONSOLE=y
-# CONFIG_TOUCHSCREEN_UCB1200 is not set
-# CONFIG_TOUCHSCREEN_BITSY is not set
 # CONFIG_SERIAL is not set
 # CONFIG_SERIAL_EXTENDED is not set
 # CONFIG_SERIAL_NONSTANDARD is not set
@@ -288,7 +283,6 @@
 #
 # Kernel hacking
 #
-CONFIG_FRAME_POINTER=y
 CONFIG_DEBUG_ERRORS=y
 CONFIG_DEBUG_USER=y
 CONFIG_DEBUG_INFO=y
--- arch/arm/def-configs/cerf   Mon Nov 27 20:07:59 2000
+++ arch/arm/def-configs/cerf.tweaked   Thu Apr 19 12:23:56 2001
@@ -35,17 +35,13 @@
 # CONFIG_SA1100_ASSABET is not set
 # CONFIG_SA1100_BRUTUS is not set
 CONFIG_SA1100_CERF=y
-CONFIG_SA1100_CERF_32MB=y
 # CONFIG_SA1100_BITSY is not set
 # CONFIG_SA1100_LART is not set
-# CONFIG_SA1100_THINCLIENT is not set
 # CONFIG_SA1100_GRAPHICSCLIENT is not set
 # CONFIG_SA1100_NANOENGINE is not set
 # CONFIG_SA1100_VICTOR is not set
 # CONFIG_SA1100_XP860 is not set
 # CONFIG_ANGELBOOT is not set
-# CONFIG_SA1100_FREQUENCY_SCALE is not set
-# CONFIG_SA1100_VOLTAGE_SCALE is not set
 # CONFIG_ARCH_ACORN is not set
 # CONFIG_FOOTBRIDGE is not set
 # CONFIG_FOOTBRIDGE_HOST is not set
@@ -63,15 +59,12 @@
 #
 # General setup
 #
-# CONFIG_SA1100_CERF_CMDLINE is not set
 CONFIG_HOTPLUG=y
 
 #
 # PCMCIA/CardBus support
 #
 CONFIG_PCMCIA=y
-# CONFIG_PCMCIA_DEBUG is not set
-CONFIG_SA1100_PCMCIA=y
 CONFIG_VIRTUAL_BUS=y
 CONFIG_NET=y
 CONFIG_SYSVIPC=y
@@ -134,10 +127,8 @@
 CONFIG_IP_PNP=y
 

Re: ANNOUNCE New Open Source X server

[James Simmons]

Thank you. It is true all I want to do is help the community. I feel as
alot of people do XFree86 can not meet the needs of the community. It is
very sad that people feel that no amount of people in the open source
community can make code of the same or better quality as XFree86 in a
shorter period of time. I don't feel this way. Now I'm off to work on code
and documentation for the project. Thank you.

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

Good example of the kind of thing the cross-referencer turns up.

[Eric S. Raymond]

Go on.  Tell me this isn't an error...

CONFIG_ARCH_CLPS7110: arch/arm/kernel/arch.c
CONFIG_ARCH_CLPS711X: arch/arm/Makefile arch/arm/config.in arch/arm/kernel/Makefile 
arch/arm/kernel/entry-armv.S arch/arm/kernel/debug-armv.S arch/arm/def-configs/ebsa110 
arch/arm/def-configs/footbridge arch/arm/def-configs/rpc 
arch/arm/def-configs/integrator

Somebody forgot an edit.  I wonder what bits got permanently conditioned out?
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

"The great object is, that every man be armed. [...] 
Every one who is able may have a gun."
-- Patrick Henry, speech of June 14 1788
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: light weight user level semaphores

[Alan Cox]

> > libc is entitled to, and most definitely does exactly that. Take a look at
> > things like gethostent, getpwent etc etc.
> 
> Ehh.. I will bet you $10 USD that if libc allocates the next file
> descriptor on the first "malloc()" in user space (in order to use the
> semaphores for mm protection), programs _will_ break.
> 
> You want to take the bet?

Its not normally a good idea to take a Linus bet, but this time Im obviously
missing something. fd0-2 will be passed in (and if not then shit already
happens - see old bugtraq on the matter for setuid apps, glibc bugs)

So the C library gets fd 3
My first fopen gets fd 4.

That can already happen and isnt new. Several profiling libraries on Unix have
precisely this effect already. They dynamic link/loader will also open file
handles to do mmaps although generally you wont see those as they are closed
again after mapping. 

Internationalisation code in glibc will also open and map tables during startup


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

Re: Kernel panics on raw I/O stress test

[Andrea Arcangeli]

On Thu, Apr 19, 2001 at 09:01:53PM +0900, Takanori Kawano wrote:
> 
> When I ran raw I/O SCSI read/write test with 2.4.1 kernel 
> on our IA64 8way SMP box, kernel paniced and following 
> message was displayed.

Could you try again with 2.4.4pre4 plus the below patch?


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.4pre2/rawio-3

You should experience also a quite noticeable improvement on both CPU usage and
disk I/O (also depends on the max size of a I/O request for your hardware disk
controller).

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

Re: ARP handling in case of having multiple interfaces on same segment

[Christopher Friesen]

NIIBE Yutaka wrote:
> 
> Sometime, we have setting like following (say, in the migration
> process of changing IP networks, or perhaps wrong way of load
> balancing):
> 
> +--+
> |eth0 eth1 |
> +--+
>|   |
> ---+---+
> 
> Current implementation of Linux doesn't handle this case.  The problem
> is ARP handling.  When ARP broadcast packet comes to the host, both
> interfaces receive the packet, and regardless of the device, we reply
> to that packet.  I think that we should not reply if the packet is not
> related to that interface.  If the ARP request is for eth1's address,
> we should not send reply from eth0.


Under later 2.2 kernels there is something called arp_filter that can be enabled
to give the exact behaviour you want. Apparently it is not yet in 2.4, but I
think that it should definately be added.

See the "ARP responses broken!" thread for more on this.

Chris


-- 
Chris Friesen| MailStop: 043/33/F10  
Nortel Networks  | work: (613) 765-0557
3500 Carling Avenue  | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange Oops in free_wait()/do_select()

[Martin Buck]

On Thu, Apr 19, 2001 at 03:25:33PM +0200, Martin Buck wrote:
> I'm getting strange Oopses with 2.2.17 on an AMD Athlon 1.2 GHz machine.
> [...]

BTW, I didn't mention it explicitly, but this kernel is *not*
Athlon-optimized (since I used it for several months on a P II and IIRC,
2.2.17 didn't offer Athlon-optimizaations anyway). It was compiled with gcc
2.95.2.

The motherboard is an Asus A7V133 with the KT133A chipset which probably
has the UDMA bug, but this shouldn't affect me since I'm only using SCSI on
the Athlon machine.

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

Re: More ATA100 oddity

[Joel Jaeggli]

udma 5 is ata100 udma4 is 66 so it's seeing your disk fine...

as far as the 27MB/s goes, it actually testing the disk and that's
what it got for throughput... that's acutally a pretty good number, on the
diamondmax 80 I get 23MB/s

/dev/hde:

 Model=Maxtor 98196H8, FwRev=ZAH814Y0, SerialNo=V80H9YCC
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=160086528
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5

/dev/hde:
 Timing buffered disk reads:  64 MB in  2.77 seconds = 23.10 MB/sec

using promise ultra-100

On Thu, 19 Apr 2001, Nicholas Petreley wrote:

> I just noticed something odd. (I'm using 2.4.3-ac9 on an
> ASUS A7V, Athlon 1000 mHz)
>
>
> (1) As noted in other messages, my machine boots up the Promise
> chipset as UDMA(100)
>
>
> hde: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=79406/16/63, UDMA(100)
>
>
> (2) hdparm recognizes it as UDMA5 with 27 MB/sec speed
>
>
> /dev/hde:
>
>  Model=Maxtor 54098H8, FwRev=DAC10SC0, SerialNo=K80EP5NC Config={ Fixed }
>  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
>  BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16,MultSect=off
>  CurCHS=16383/16/63, CurSects=16514064, LBA=yes,LBAsects=80041248
>  IORDY=on/off, tPIO={min:120,w/IORDY:120},tDMA={min:120,rec:120}
>  PIO modes: pio0 pio1 pio2 pio3 pio4
>  DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
>  Timing buffered disk reads:  64 MB in  2.31 seconds = 27.71 MB/sec
>
>
>
> (3) /proc/ide/pdc202xx sees it as UDMA 4
>
>
>
> PDC20265 Chipset.
> --- General Status -
> Burst Mode   : enabled
> Host Mode: Normal
> Bus Clocking : 33 PCI Internal
> IO pad select: 10 mA
> Status Polling Period: 1
> Interrupt Check Status Polling Delay : 2
> --- Primary Channel  Secondary Channel -
> enabled  enabled
> 66 Clocking enabled  disabled
>Mode PCI Mode PCI
> FIFO Empty   FIFO Empty
> --- drive0 - drive1  drive0-- drive1 --
> DMA enabled:yes  no  no no
> DMA Mode:   UDMA 4   NOTSET  NOTSET NOTSET
> PIO Mode:   PIO 4NOTSET   NOTSETNOTSET
>
>
>
> Oh, and by the way, ACPI support has never powered off this
> machine.  Ever.  But I use apm and I'm happy.
>
>
> -Nick
>
>

-- 
--
Joel Jaeggli   [EMAIL PROTECTED]
Academic User Services   [EMAIL PROTECTED]
 PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.


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

Re: generic rwsem [Re: Alpha "process table hang"]

[Andrea Arcangeli]

On Thu, Apr 19, 2001 at 11:21:17AM -0500, Bob McElrath wrote:
> I'm at 2 days uptime now, and have not seen the process-table-hang.
> Looks like this fixed it.  Previously I would get a hang in the first
> day or so.  I'm using your alpha-numa-3 and rwsem-generic-4 against
> 2.4.4pre3.

good, thanks for the report.

BTW, if you upgrade to 2.4.4pre4 you can apply those two patches:


ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre4aa1/00_alpha-numa-4

ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre4aa1/00_rwsem-generic-6

really the first is not necessary anymore unless you're using a wildfire. The
second also resurrect the optimized rwsemaphores for all archs but alpha and
ia32.

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

Re: light weight user level semaphores

[Abramo Bagnara]

Linus Torvalds wrote:
> 
> On Thu, 19 Apr 2001, Abramo Bagnara wrote:
> >
> > > [ Using file descriptors ]
> >
> > This would also permit:
> > - to have poll()
> > - to use mmap() to obtain the userspace area
> >
> > It would become something very near to sacred Unix dogmas ;-)
> 
> No, this is NOT what the UNIX dogmas are all about.
> 
> When UNIX says "everything is a file", it really means that "everything is
> a stream of bytes". Things like magic operations on file desciptors are
> _anathema_ to UNIX. ioctl() is the worst wart of UNIX. Having magic
> semantics of file descriptors is NOT Unix dogma at all, it is a horrible
> corruption of the original UNIX cleanlyness.

Nice outpouring indeed, it seems taken from L'Ouvre au Noir by
Marguerite Yourcenar ;-)))

You're perfectly right but the file descriptor solution appeared to me a
nice way to work around the Unix limitation to have poll(2) working only
on file descriptor.

Said this, I've no doubt that a better poll-like syscall would solve all
that in a more elegant way.

You understand that sometime we've no other choice that to design
workarounds to minimize needed changes (and then often to maximize
acceptance probability).

OTOH you may always decide to do things in the elegant way, you've such
a responsibility for linux kernel.

-- 
Abramo Bagnara   mailto:[EMAIL PROTECTED]

Opera Unica  Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy

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

Re: light weight user level semaphores

[Linus Torvalds]

On Thu, 19 Apr 2001, Alan Cox wrote:
> > can libraries use fast semaphores behind the back of the user? They might
> > well want to use the semaphores exactly for things like memory allocator
> > locking etc. But libc certainly cant use fd's behind peoples backs.
>
> libc is entitled to, and most definitely does exactly that. Take a look at
> things like gethostent, getpwent etc etc.

Ehh.. I will bet you $10 USD that if libc allocates the next file
descriptor on the first "malloc()" in user space (in order to use the
semaphores for mm protection), programs _will_ break.

You want to take the bet?

Linus

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

Kernel 2.4.x - Oops with 2k-block MO disks + FAT

[Marc-Jano Knopp]

Hi!

  Both kernel 2.4.2 and 2.4.3 have an error in handling magneto-
  optical disks (MOs) with 2048-byte blocks when they are formatted
  with FAT.
  
  
  Conditions
  --
  
- Kernel 2.4.2 or 2.4.3 (most likely ALL 2.4.x kernels)
- MO with 2048-byte blocks (e.g. 3.5" 640 MB)
  (it doesn't matter if it's a LIMDOW-MO or a normal MO)
- FAT fs on that MO

If any of the conditions are not met, for example

- ext2 on the MO, or
- an MO with 512-byte blocks
  (e.g. 3.5" 230 MB and 3.5" 540 MB) and FAT, or
- a kernel 2.2.x,

the problem doesn't occur.


  Symptoms
  
  
- Directly accessing the device (e.g. dd if=/dev/sda of=/tmp/sda.bin)
  is OKAY.
- Mounting the MO is OKAY.
- Navigating through the directory tree on the MO is OKAY.
- Writing files onto the MO seems to be okay (haven't tried
  to read these files under 2.2.x yet)
- But as soon as you try to READ a FILE, the program (e.g. cat)
  SEGFAULTs and a kernel OOPS occurs.

This happens both with the new and with the old aic7xxx
driver (as offered in kernel 2.4.3).

- After the Oops, one cannot umount the device anymore.
  'fuser -v /vmo' says:
  
   USERPID ACCESS COMMAND
  /vmo root kernel mount  /vmo
   
- mount says:
  /dev/sda on /vmo type vfat (rw,noexec,nosuid,nodev)


  Oops (output from ksymoops)
  ---
  
---BEGIN
ksymoops 2.4.0 on i686 2.4.3.  Options used
 -V (default)
 -k /tmp/ksyms (specified)  [immediately copied from /proc after Oops]
 -l /proc/modules (default)
 -o /lib/modules/2.4.3/ (default)
 -m /boot/System.map (specified)

Warning (compare_maps): ksyms_base symbol scsi_logging_level_R__ver_scsi_logging_level 
not found in System.map.  Ignoring ksyms_base entry
Apr 19 16:05:39 pc8 kernel: Unable to handle kernel NULL pointer dereference at 
virtual address 
Apr 19 16:05:39 pc8 kernel: 
Apr 19 16:05:39 pc8 kernel: *pde = 
Apr 19 16:05:39 pc8 kernel: Oops: 
Apr 19 16:05:39 pc8 kernel: CPU:0
Apr 19 16:05:39 pc8 kernel: EIP:0010:[agp_frontend_cleanup+0/-1072693248]
Apr 19 16:05:39 pc8 kernel: EFLAGS: 00010282
Apr 19 16:05:39 pc8 kernel: eax:    ebx: e4fc2cc0   ecx: 4000   edx: 
e4fc2ce0
Apr 19 16:05:39 pc8 kernel: esi: 0804cea8   edi:    ebp: 4000   esp: 
e4cebf80
Apr 19 16:05:39 pc8 kernel: ds: 0018   es: 0018   ss: 0018
Apr 19 16:05:39 pc8 kernel: Process cat (pid: 682, stackpage=e4ceb000)
Apr 19 16:05:39 pc8 kernel: Stack: c01589fd e4fc2cc0 0804cea8 4000 e4fc2ce0 
e4fc2cc0 ffea c012cce6 
Apr 19 16:05:39 pc8 kernel:e4fc2cc0 0804cea8 4000 e4fc2ce0 e4cea000 
4000 0804cea8 b604 
Apr 19 16:05:39 pc8 kernel:c0106e83 0003 0804cea8 4000 4000 
0804cea8 b604 0003 
Apr 19 16:05:39 pc8 kernel: Call Trace: [fat_cache_add+173/176] [sys_read+150/208] 
[system_call+51/56] 
Apr 19 16:05:39 pc8 kernel: Code:  Bad EIP value.
Using defaults from ksymoops -t elf32-i386 -a i386



1 warning issued.  Results may not be reliable.
---END--
  

  Output of 'strace -v -f -s 16384 cat /vmo/out' ('out' is an mbox file)
  --
  
---BEGIN
execve("/bin/cat", ["cat", "/vmo/out"], [/* 51 vars */]) = 0
uname({sysname="Linux", nodename="pc8", release="2.4.3", version="#8 Thu Apr 19 
15:46:00 CEST 2001", machine="i686"}) = 0
brk(0)  = 0x804c048
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat64(3, {st_dev=makedev(3, 7), st_ino=12488, st_mode=S_IFREG|0644, st_nlink=1, 
st_uid=0, st_gid=0, st_blksize=4096, st_blocks=232, st_size=117364, 
st_atime=2001/04/19-15:57:37, st_mtime=2001/04/18-12:33:10, 
st_ctime=2001/04/18-12:33:10}) = 0
old_mmap(NULL, 117364, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
[uninteresting stuff (reading from libc) deleted]
fstat64(3, {st_dev=makedev(3, 7), st_ino=28585, st_mode=S_IFREG|0755, st_nlink=1, 
st_uid=0, st_gid=0, st_blksize=4096, st_blocks=2714, st_size=1382179, 
st_atime=2001/04/19-15:57:37, st_mtime=2001/01/19-07:14:03, 
st_ctime=2001/04/12-22:58:14}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40034000
old_mmap(NULL, 1123876, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40035000
mprotect(0x4013e000, 38436, PROT_NONE)  = 0
old_mmap(0x4013e000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x108000) 
= 0x4013e000
old_mmap(0x40144000, 13860, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 
-1, 0) = 0x40144000
close(3)= 0
munmap(0x40017000, 117364)  = 0
getpid()

Re: generic rwsem [Re: Alpha "process table hang"]

[Bob McElrath]

Bob McElrath [[EMAIL PROTECTED]] wrote:
> Andrea Arcangeli [[EMAIL PROTECTED]] wrote:
> >
> > So please try to reproduce the hang with 2.4.4pre3 with those two
> > patches applied:
> > 
> > 
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre3aa3/00_alpha-numa-3
> > 
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre3aa3/00_rwsem-generic-1
> > 
> > All alpha users should run with at least the above two patches applied
> > to compile their tree and to make sure to have rock solid rwsemaphores.
> 
> Excellent!  I'll give it a try.
> 
> Note that I recently saw the X hang with the 2.2.19 kernel, but I still
> haven't seen the process-table-hang with 2.2.19 (about 4 days running
> with 2.2.19).  It is *far* easier to get the X hang in 2.4 than 2.2.
> (minutes for 2.4, days for 2.2)  Also note that this is not an SMP
> machine (single processor 21164a, LX164 mobo).
> 
> But I'll apply your patch tonight and let you know the results.

Status report:
I'm at 2 days uptime now, and have not seen the process-table-hang.
Looks like this fixed it.  Previously I would get a hang in the first
day or so.  I'm using your alpha-numa-3 and rwsem-generic-4 against
2.4.4pre3.

Cheers,
-- Bob

Bob McElrath ([EMAIL PROTECTED]) 
Univ. of Wisconsin at Madison, Department of Physics

 PGP signature

Re: linux timer performance ?

[Jeremy Jackson]

Praveen Rajendran wrote:

> hi
>
> I am working on a kernel module which requires the addition of a large
> number of kernel timers  to expire statistical values ( including time
> ) maintained in a table.
>
> One alternative would be to use a single timer and traverse the entire
> table and use the existing system time to expire the values ( comparing
> it with the time already stored in the table )when the timer expires .

Most versions of cron claim to be very scalable, and use an optimized
algorithm to do the second option.  (avoiding linear scan) You could likely
just cut and paste
the code.  Problem solved?

>
>
> Following the method I describe first I would have to add a large number
> of timers ( around 2000) ... would this cause any significant
> performance drop  ? which method should I use ?
>
> thanks in advance
>
> Praveen
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

Re: ATA 100

[Vojtech Pavlik]

On Thu, Apr 19, 2001 at 04:46:03PM +0200, David Balazic wrote:

> Vojtech Pavlik ([EMAIL PROTECTED]) wrote :
> 
> > On Wed, Apr 18, 2001 at 10:21:53PM -0400, Manuel Ignacio Monge Garcia wrote: 
> > 
> > > El Mié 18 Abr 2001 15:16, escribiste: 
> > > > I don't know about other possible problems with the kernel, but you must 
> > > > use an 80 wire IDE cable for UDMA66/100 to work. 
> > > > 
> > > > > ---Primary IDE---Secondary IDE-- 
> > > > > Cable Type: 40w 40w 
> > > 
> > > 
> > > Strange thing. With previous version of kernel (2.4.1 I think), I 
> > > haven't got this problem. May be a bios detection problem? 
> > > 
> > > Extract from /usr/src/linux/drivers/ide/via82cxxx..c: 
> > > 
> > > * 
> > > * PIO 0-5, MWDMA 0-2, SWDMA 0-2 and UDMA 0-5 
> > > * 
> > > * (this includes UDMA33, 66 and 100) modes. UDMA66 and higher modes are 
> > > * autoenabled only in case the BIOS has detected a 80 wire cable. To ignore 
> > > * the BIOS data and assume the cable is present, use 'ide0=ata66' or 
> > > * 'ide1=ata66' on the kernel command line. 
> > > * 
> > > 
> > > I've tried with ide0=ata100, but this options doesn't work. 
> > 
> > Try ide0=ata66 instead. The option should have been named ide0=80wire, 
> > but, well, "ata66" was chosen as the name, because that was it at the 
> > time. 
> 
> Any chance of auto detecting this ?

None. It's different on each (pre-686b) VIA motherboard.

> I just hate when linux is relaying on the BIOS ...

We don't have any other chance here. Actually we'll have to rely on the
BIOS for even more in the next release of the driver to make it work on
all boards out there.

> BTW , why are there 666 CONFIG_.*IDE.*DMA.* switches ?

Ask Andre. :)

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

Re: Is there a way to turn file caching off ?

[Jeremy Jackson]

Helge Hafting wrote:

> Jeremy Jackson wrote:
>
> > currently all the kernel's heuristics are feed-back control loops.
> > what you are asking for is a feed-forward system: a way for the application
> > to tell kernel "I'm only reading this once, so after I'm done, throw it out
> > straight away"
> > and "I'm only writing this data, so after I'm done, start writing it out and
> > then forget it"
> >
> This is hard to get right.  Sure - your unpack/copy program read once
> and
> writes once.  But the stuff might be used shortly thereafter by
> another process.  For example:  I unpack a kernel tarball.  tar
> knows it writes only once and might not need more than 5M to do
> this as efficient as possible with my disks.  A lot of other cache
> could be saved, fewer things swapped out.
> But then I compile it.  Todays system ensures that lots of the source
> is in memory already.  Limiting the caching to what tar needed
> however will force the source to be read from disk once during
> the compile - not what I want at all.

They why would you tell tar not to use cache?  If you know what's happening
next you need to tell the system (feed-forward), not have it try to read your
mind.  I'm assuming your modified tar would have an option switch
to cause this behaviour, not be hard coded...

>
>
> A program may know its own access pattern, but it don't usually know
> future access patterns.  Well, backing up the entire fs could benefit

Yes, so a script that does the above wouldn't enable no cache mode
for written files.  The program doesn't know, but the encompasing
script (or person at console) does.

>
> from a something like this, you probably won't need the backup again
> soon.  But this is hard to know in many other cases.

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

Re: light weight user level semaphores

[Linus Torvalds]

On Thu, 19 Apr 2001, Abramo Bagnara wrote:
>
> > [ Using file descriptors ]
>
> This would also permit:
> - to have poll()
> - to use mmap() to obtain the userspace area
>
> It would become something very near to sacred Unix dogmas ;-)

No, this is NOT what the UNIX dogmas are all about.

When UNIX says "everything is a file", it really means that "everything is
a stream of bytes". Things like magic operations on file desciptors are
_anathema_ to UNIX. ioctl() is the worst wart of UNIX. Having magic
semantics of file descriptors is NOT Unix dogma at all, it is a horrible
corruption of the original UNIX cleanlyness.

Please don't excuse "semaphore file descriptors" with the "everything is a
file" mantra. It is not at ALL applicable.

The "everything is a file" mantra is to make pipe etc meaningful -
processes don't have to worry about whether the fd they have is from a
file open, a pipe() system call, opening a special block device, or a
socket()+connect() thing. They can just read and write. THAT is what UNIX
is all about.

And this is obviously NOT true of a "magic file descriptors for
semaphores". You can't pass it off as stdin to another process and expect
anything useful from it unless the other process _knows_ it is a special
semaphore thing and does mmap magic or something.

The greatness of UNIX comes from "everything is a stream of bytes". That's
something that almost nobody got right before UNIX. Remember VMS
structured files? Did anybody ever realize what an absolutely _idiotic_
crock the NT "CopyFile()" thing is for the same reason?

Don't confuse that with "everything should be a file descriptor". The two
have nothing to do with each other.

Linus

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

FW: Bug in serial.c

[Marc Karasek]

 

-Original Message-
From: Marc Karasek
To: 'Disconnect '
Sent: 4/19/01 11:49 AM
Subject: RE: Bug in serial.c

 I have changed everything to point to /dev/ttyS0.  The settings in
lilo.conf (I am booting from a floppy to emulate the embedded space) are
all for ttyS0.  Lilo pritns to the terminal (minicom on another Linux
box) and the kernel prints as well.  When I get to inittab (running
busybox) it asks for some input thru a script to setup the embedded
emulation.  At this point it just sits there.  If I turn on the debug in
serial.c I can see the characters (hex values) as I type.  Kernel 2.4.2
works fine, with the only problem being the smp compile issue.  As I
need module support and cannot have a kernel of 600k+ size I am in a bit
of a pickle.



-Original Message-
From: Disconnect
To: Marc Karasek
Cc: '[EMAIL PROTECTED]'
Sent: 4/19/01 11:38 AM
Subject: Re: Bug in serial.c

On Thu, 19 Apr 2001, Marc Karasek did have cause to say:

> 2) In 2.4.3 the console port using ttySX is broken.  It dumps fine to
the
> terminal but when you get to a point of entering data (login,
configuration
> scripts, etc) the terminal does not accept any input.  

Most gettys and such take a /dev/tty* argument, which has to be changed
to
point to the serial port for a serial console. Config scripts (and
anything else) specifically using /dev/tty or /dev/console should work
fine, however. (I wouldn't recommend pointing a getty at /dev/console -
we
had some issues on a headless server trying that. Easiest to point it at
/dev/ttyS0 or whatnot.)

> 
> So far I have been able to debug to the point where I see that the
kernel is
> receiving the characters from the serial.c driver.  But it never echos
them
> or does anything else with them.  I will continue to look into this at
this
> end.  
> 
> I was also wondering if anyone else has seen this or if a patch is
avail for
> this bug??
> 
> Marc Karasek
> Sr. Firmware Engineer
> iVivity Inc
> [EMAIL PROTECTED]  
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-==-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the
Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

FW: Bug in serial.c

[Marc Karasek]

 

-Original Message-
From: Marc Karasek
To: 'Richard B. Johnson '
Sent: 4/19/01 11:53 AM
Subject: RE: Bug in serial.c 

 Did something change between 2.4.2 & 2.4.3? Under 2.4.2 I did not have
to init the terminal (are you refering to the host or client side?) and
just accepted the defaults (9600, 8n1) which was fine for debug and
terminal I/O.  

My issue is with 2.4.2 it works with 2.4.3 (same .config) it does not.
So in my mind this is a bug of some type.  :-) 

Which kernel are you using in your embedded project??




-Original Message-
From: Richard B. Johnson
To: Marc Karasek
Cc: '[EMAIL PROTECTED]'
Sent: 4/19/01 11:43 AM
Subject: Re: Bug in serial.c 

On Thu, 19 Apr 2001, Marc Karasek wrote:

> I am doing some embedded development with the 2.4.x series and have
noticed
> a few things..
>
[SNIPPED...]
 
> 
> 2) In 2.4.3 the console port using ttySX is broken.  It dumps fine to
the
> terminal but when you get to a point of entering data (login,
configuration
> scripts, etc) the terminal does not accept any input.  
>

It is not broken. It is used all the while in our embeded systems.
 
> So far I have been able to debug to the point where I see that the
kernel is
> receiving the characters from the serial.c driver.  But it never echos
them
> or does anything else with them.  I will continue to look into this at
this
> end.  
> 

Did you ever initialize the terminal? And I'm not talking about
baud-rate.
There is a termios structure of information necessary to configure a
terminal for I/O.

> I was also wondering if anyone else has seen this or if a patch is
avail for
> this bug??

You refer to a BUG?  There isn't any of the kind you describe.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/sound/nm256_audio.c

[Marcus Meissner]

On Thu, Apr 19, 2001 at 11:56:01AM -0400, Jeff Garzik wrote:
> Marcus Meissner wrote:
> > 
> > Hi,
> > 
> > This updates the nm256_audio driver to the 2.4 PCI API.
> > 
> > Patch is against 2.4.3-ac9, verified on Sony VAIO Laptop.
> 
> "verified" is the really important part with this driver, since its
> really finicky.  I have a patch I would love to bounce to you in
> private, that I have been searching for a tester for -months- because I
> had no test hardware of my own.

Feel free to send (I have a NM256AV card in that VAIO).

> Your patch looks ok to me and I would say apply it.  But I also think it
> is incomplete.
> 
> * there is no need for a linked list of cards, since
> pci_{get,set}_drvdata is used.  This eliminates the list walk in
> nm256_remove

The problem is with device opens, which just pass numbers, most other
sound drivers still use linked lists.

Hmm, but via8_audio.c doesn't, I will take this as example.

> * the new PCI API has suspend/resume hooks, and those should be used in
> preference to register_pm_...

Ok, will have another look at the other issues.

And I hope my colleague brings his VAIO to work tomorrow ;)

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

BUG: Global FPU corruption in 2.2

[Victor Zandy]

We have found that one of our programs can cause system-wide
corruption of the x86 FPU under 2.2.16 and 2.2.17.  That is, after we
run this program, the FPU gives bad results to all subsequent
processes.

We see this problem on dual 550MHz Xeons with 1GB RAM.  We have 64 of
these things, and we see the problem on every node we try (dozens).
We don't have other SMPs handy.  Uniprocessors, including other PIIIs,
don't seem to be affected.

While we prepare to test for the problem on more recent 2.2 and 2.4
kernels, we would appreciate hearing from anyone who may have insight
into it.

Below are two programs we use to produce the behavior.  The first
program, pi, repeatedly spawns 10 parallel computations of pi.  When
all is well, each process prints pi as it completes.

The second program, pt, repeatedly attaches to and detaches from
another process.  Run pt against the root pi process until the output
of pi begins to look wrong.  Then kill everything and run pi by itself
again.  It will no longer produce good results.  We find that the FPU
persistently gives bad results until we reboot.

Here is the sort of thing we see:

BEFORE  AFTER
--
c36% ./pi   c36% ./pi
[3883]  [4069]   
3.1415936865157.146714   
3.141593inf  
3.14159381705.277947 
3.1415934.742524 
3.141593nan  
3.141593585.810296   
3.141593inf  
3.1415934.578857 
3.141593nan  
3.1415934.578857 

I am not currently subscribed to linux-kernel.  I'll be checking the
web archives, but please CC replies to me.

Thanks!

Vic Zandy

/* pi.c: gcc -g -o pi pi.c -lm */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

static double
do_pi()
{
double sum=0.0;
double x=1.0;
double s=1.0;
double pi;

while (x <= 1000.0) {
sum += (1.0/pow(x, 3.0))*s;
s = -s;
x += 2.0;
}
pi = pow(sum*32.0, 1.0/3.0);
return pi;
}

int
main( int argc, char* argv[] )
{
int i;
int pid;
int m = 1000;   /* runs */
int n = 10; /* procs per run */

pid = getpid();
fprintf(stderr, "[%d]\n", pid);
while (m-- > 0) {
 for (i = 1; i < n; i++)
  if (!fork())
   break;
 fprintf(stderr, "%f\n", do_pi());
 if (getpid() != pid)
  return 0;
 while (waitpid(0, 0, WNOHANG) > 0)
  ;
}
return 0;
}
/* end of pi.c */

/* pt.c: gcc -g -o pt pt.c */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

long
dptrace(int req, pid_t pid, void *addr, void *data)
{
char buf[64];
int rv;
rv = ptrace(req, pid, addr, data);
if ((req != PTRACE_PEEKUSR && req != PTRACE_PEEKTEXT) && 0 > rv) {
sprintf(buf, "ptrace (req=%d)", req);
perror(buf);
exit(1);
}
return rv;
}

int
main(int argc, char *argv[])
{
int pid;
char buf[1024];
int n;

if (argc < 2) {
fprintf(stderr, "Usage: %s PID\n", argv[0]);
exit(1);
}
pid = atoi(argv[1]);
while (1) {
dptrace(PTRACE_ATTACH, pid, 0, 0);
waitpid(pid, 0, 0);
dptrace(PTRACE_DETACH, pid, 0, 0);
fprintf(stderr, ".");
}
return 0;
}
/* end of pt.c */


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

Re: light weight user level semaphores

[Linus Torvalds]

On Thu, 19 Apr 2001, Alon Ziv wrote:
>
> * the userspace struct was just a signed count and a file handle.

The main reason I wanted to avoid a filehandle is just because it's
another name space that people already use, and that people know what the
semantics are for (ie "open()" is _defined_ to return the "lowest
available file descriptor", and people depend on that).

So if you use a file handle, you'd need to do magic - open it, and then
use dup2() to move it up high, or something. Which has its own set of
problems: just _how_ high woul dyou move it? Would it potentially disturb
an application that opens thousands of files, and knows that they get
consecutive file descriptors? Which is _legal_ and well-defined in UNIX.

However, I'm not married to the secure hash version - you could certainly
use another name-space, and something more akin to file descriptors. You
should be aware of issues like the above, though. Maybe it would be ok to
say "if you use fast semaphores, they use file descriptors and you should
no longer depend on consecutive fd's".

But note how that might make it really nasty for things like libraries:
can libraries use fast semaphores behind the back of the user? They might
well want to use the semaphores exactly for things like memory allocator
locking etc. But libc certainly cant use fd's behind peoples backs.

So personally, I actually think that you must _not_ use file descriptors.
But that doesn't mean that you couldn't have a more "file-desciptor-like"
approach.

Side note: the design _should_ allow for "lazy initialization". In
particular, it should be ok for FS_create() to not actually do a system
call at all, but just initialize the count and set a "uninitialized" flag.
And then the actual initialization would be done at "FS_down()" time, and
only if contention happens.

Why? Note that there are many cases where contention simply _cannot_
happen. The classic one is a thread-safe library that is used both by
threaded applications and by single-threaded ones, where the
single-threaded one would never actually trigger contention.

For these kinds of reasons it would actually be best to make try to
abstract the interfaces (notably the system call interface) as much as
possible, so that you can change the implementation inside the kernel
without having to recompile applications that use it. So the sanest
implementation might be one where

 - FS_create is a system call that just gets a 128-byte area and an ID.
 - the contention cases are plain system calls with no user-mode part to
   them at all.

This allows people to modify the behaviour of the semaphores later,
_without_ having any real coupling between user-mode expectations and
kernel implementation.

For example, if the user-mode library actually does a physical "open()" or
plays games with file descriptors itself, we will -always- be stuck with
the fd approach, and we can never fix it. But if you have opaque system
calls, you mist start out with a system call that internally just does the
equivalent of the "open a file descriptor and hide it in the semaphore",
and later on the thing can be changed to do whatever else without the user
program ever even realizing..

Linus

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

Re: [PATCH] drivers/sound/nm256_audio.c

[Jeff Garzik]

Marcus Meissner wrote:
> 
> Hi,
> 
> This updates the nm256_audio driver to the 2.4 PCI API.
> 
> Patch is against 2.4.3-ac9, verified on Sony VAIO Laptop.

"verified" is the really important part with this driver, since its
really finicky.  I have a patch I would love to bounce to you in
private, that I have been searching for a tester for -months- because I
had no test hardware of my own.

Your patch looks ok to me and I would say apply it.  But I also think it
is incomplete.

* there is no need for a linked list of cards, since
pci_{get,set}_drvdata is used.  This eliminates the list walk in
nm256_remove

* the new PCI API has suspend/resume hooks, and those should be used in
preference to register_pm_...

* there is rarely a need to compare PCI ids manually in a driver.  Do
this implicitly by using the struct pci_device_id::driver_data field. 
In the following code, you could simply pass these two strings as your
driver_data:
> +if (pcidev->device == PCI_DEVICE_ID_NEOMAGIC_NM256AV_AUDIO)
> +   return nm256_install(pcidev, REV_NM256AV, "256AV");
> +if (pcidev->device == PCI_DEVICE_ID_NEOMAGIC_NM256ZX_AUDIO)
> +   return nm256_install(pcidev, REV_NM256ZX, "256ZX");

* typically you don't want to -always- printout the module version when
built into the kernel.  that can get ugly, when you have a bunch of
drivers in the kernel.  you should surround the existing version printk
code with ifdef MODULE, and then add some additional code in your
pci_driver::probe routine which looks something like

#ifndef MODULE
static int printed_version;
if (!printed_version++)
printk(version);
#endif

and further, declare your version string like the following code, so it
can be dropped from the kernel image...

static char version[] __devinitdata =
KERN_INFO "... version ...\n";

Looks good, thanks for the work!  If you spot any other drivers you can
convert, feel free.

Jeff


-- 
Jeff Garzik   | "The universe is like a safe to which there is a
Building 1024 |  combination -- but the combination is locked up
MandrakeSoft  |  in the safe."-- Peter DeVries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug in serial.c

[Richard B. Johnson]

On Thu, 19 Apr 2001, Marc Karasek wrote:

> I am doing some embedded development with the 2.4.x series and have noticed
> a few things..
>
[SNIPPED...]
 
> 
> 2) In 2.4.3 the console port using ttySX is broken.  It dumps fine to the
> terminal but when you get to a point of entering data (login, configuration
> scripts, etc) the terminal does not accept any input.  
>

It is not broken. It is used all the while in our embeded systems.
 
> So far I have been able to debug to the point where I see that the kernel is
> receiving the characters from the serial.c driver.  But it never echos them
> or does anything else with them.  I will continue to look into this at this
> end.  
> 

Did you ever initialize the terminal? And I'm not talking about baud-rate.
There is a termios structure of information necessary to configure a
terminal for I/O.

> I was also wondering if anyone else has seen this or if a patch is avail for
> this bug??

You refer to a BUG?  There isn't any of the kind you describe.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug in serial.c

[Disconnect]

On Thu, 19 Apr 2001, Marc Karasek did have cause to say:

> 2) In 2.4.3 the console port using ttySX is broken.  It dumps fine to the
> terminal but when you get to a point of entering data (login, configuration
> scripts, etc) the terminal does not accept any input.  

Most gettys and such take a /dev/tty* argument, which has to be changed to
point to the serial port for a serial console. Config scripts (and
anything else) specifically using /dev/tty or /dev/console should work
fine, however. (I wouldn't recommend pointing a getty at /dev/console - we
had some issues on a headless server trying that. Easiest to point it at
/dev/ttyS0 or whatnot.)

> 
> So far I have been able to debug to the point where I see that the kernel is
> receiving the characters from the serial.c driver.  But it never echos them
> or does anything else with them.  I will continue to look into this at this
> end.  
> 
> I was also wondering if anyone else has seen this or if a patch is avail for
> this bug??
> 
> Marc Karasek
> Sr. Firmware Engineer
> iVivity Inc
> [EMAIL PROTECTED]  
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-==-._
| [EMAIL PROTECTED]| And Remember...
\  [EMAIL PROTECTED]  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-BEGIN GEEK CODE BLOCK-
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C$ ULBS*$ P+>+++ L>+ 
E--- W+++ N+@ o+>$ K? w--->+ O- M V-- PS+() PE Y+@ PGP++() t 5--- 
X-- R tv+@ b>$ DI D++(+++) G++ e* h(-)* r++ y++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers/sound/nm256_audio.c

[Marcus Meissner]

Hi,

This updates the nm256_audio driver to the 2.4 PCI API.

Patch is against 2.4.3-ac9, verified on Sony VAIO Laptop.

Ciao, Marcus

Index: drivers/sound/nm256_audio.c
===
RCS file: /build/mm/work/repository/linux-mm/drivers/sound/nm256_audio.c,v
retrieving revision 1.1
diff -u -r1.1 nm256_audio.c
--- drivers/sound/nm256_audio.c 2001/04/17 14:50:30 1.1
+++ drivers/sound/nm256_audio.c 2001/04/19 15:28:43
@@ -15,6 +16,8 @@
  * Changes:
  * 11-10-2000  Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
  * Added some __init
+ * 19-04-2001  Marcus Meissner <[EMAIL PROTECTED]>
+ * Ported to 2.4 PCI API.
  */
 
 #define __NO_VERSION__
@@ -49,8 +52,6 @@
 #define PCI_DEVICE_ID_NEOMAGIC_NM256AV_AUDIO 0x8005
 #define PCI_DEVICE_ID_NEOMAGIC_NM256ZX_AUDIO 0x8006
 
-#define RSRCADDRESS(dev,num) ((dev)->resource[(num)].start)
-
 /* List of cards.  */
 static struct nm256_info *nmcard_list;
 
@@ -1042,6 +1043,9 @@
 struct pm_dev *pmdev;
 int x;
 
+if (pci_enable_device(pcidev))
+   return 0;
+
 card = kmalloc (sizeof (struct nm256_info), GFP_KERNEL);
 if (card == NULL) {
printk (KERN_ERR "NM256: out of memory!\n");
@@ -1055,7 +1059,7 @@
 
 /* Init the memory port info.  */
 for (x = 0; x < 2; x++) {
-   card->port[x].physaddr = RSRCADDRESS (pcidev, x);
+   card->port[x].physaddr = pci_resource_start (pcidev, x);
card->port[x].ptr = NULL;
card->port[x].start_offset = 0;
card->port[x].end_offset = 0;
@@ -1201,6 +1205,8 @@
}
 }
 
+pci_set_drvdata(pcidev,card);
+
 /* Insert the card in the list.  */
 card->next_card = nmcard_list;
 nmcard_list = card;
@@ -1251,37 +1257,38 @@
 return 0;
 }
 
-/*
- * This loop walks the PCI configuration database and finds where
- * the sound cards are.
- */
- 
-int __init
-init_nm256(void)
+static int __devinit
+nm256_probe(struct pci_dev *pcidev,const struct pci_device_id *pciid)
 {
-struct pci_dev *pcidev = NULL;
-int count = 0;
-
-if(! pci_present())
-   return -ENODEV;
-
-while((pcidev = pci_find_device(PCI_VENDOR_ID_NEOMAGIC,
-   PCI_DEVICE_ID_NEOMAGIC_NM256AV_AUDIO,
-   pcidev)) != NULL) {
-   count += nm256_install(pcidev, REV_NM256AV, "256AV");
-}
-
-while((pcidev = pci_find_device(PCI_VENDOR_ID_NEOMAGIC,
-   PCI_DEVICE_ID_NEOMAGIC_NM256ZX_AUDIO,
-   pcidev)) != NULL) {
-   count += nm256_install(pcidev, REV_NM256ZX, "256ZX");
+if (pcidev->device == PCI_DEVICE_ID_NEOMAGIC_NM256AV_AUDIO)
+   return nm256_install(pcidev, REV_NM256AV, "256AV");
+if (pcidev->device == PCI_DEVICE_ID_NEOMAGIC_NM256ZX_AUDIO)
+   return nm256_install(pcidev, REV_NM256ZX, "256ZX");
+return -1; /* should not come here ... */
+}
+
+static void __devinit
+nm256_remove(struct pci_dev *pcidev) {
+struct nm256_info *xcard = pci_get_drvdata(pcidev);
+struct nm256_info *card,*next_card = NULL;
+
+for (card = nmcard_list; card != NULL; card = next_card) {
+   next_card = card->next_card;
+   if (card == xcard) {
+   stopPlay (card);
+   stopRecord (card);
+   if (card->has_irq)
+   free_irq (card->irq, card);
+   nm256_release_ports (card);
+   sound_unload_mixerdev (card->mixer_oss_dev);
+   sound_unload_audiodev (card->dev[0]);
+   sound_unload_audiodev (card->dev[1]);
+   kfree (card);
+   break;
+   }
 }
-
-if (count == 0)
-   return -ENODEV;
-
-printk (KERN_INFO "Done installing NM256 audio driver.\n");
-return 0;
+if (nmcard_list == card)
+   nmcard_list = next_card;
 }
 
 /*
@@ -1639,9 +1646,21 @@
 local_qlen:nm256_audio_local_qlen,
 };
 
-EXPORT_SYMBOL(init_nm256);
+static struct pci_device_id nm256_pci_tbl[] __devinitdata = {
+   {PCI_VENDOR_ID_NEOMAGIC, PCI_DEVICE_ID_NEOMAGIC_NM256AV_AUDIO,
+   PCI_ANY_ID, PCI_ANY_ID, 0, 0},
+   {PCI_VENDOR_ID_NEOMAGIC, PCI_DEVICE_ID_NEOMAGIC_NM256ZX_AUDIO,
+   PCI_ANY_ID, PCI_ANY_ID, 0, 0},
+   {0,}
+};
+MODULE_DEVICE_TABLE(pci, nm256_pci_tbl);
 
-static int loaded = 0;
+struct pci_driver nm256_pci_driver = {
+   name:"nm256_audio",
+   id_table:nm256_pci_tbl,
+   probe:nm256_probe,
+   remove:nm256_remove,
+};
 
 MODULE_PARM (usecache, "i");
 MODULE_PARM (buffertop, "i");
@@ -1650,37 +1669,13 @@
 
 static int __init do_init_nm256(void)
 {
-nmcard_list = NULL;
-printk (KERN_INFO "NeoMagic 256AV/256ZX audio driver, version 1.1\n");
-
-if (init_nm256 () == 0) {
-   loaded = 1;
-   return 0;
-}
-else
-   return -ENODEV;
+printk (KERN_INFO "NeoMagic 256AV/256ZX audio driver, version 1.1p\n");
+return pci_module_init(_pci_driver);
 }
 
 static void __exit cleanup_nm256 

Bug in serial.c

[Marc Karasek]

I am doing some embedded development with the 2.4.x series and have noticed
a few things..

1) In 2.4.2 in order to compile with module support you also had to turn on
smp support.  This has been fixed in the 2.4.3 release.  This bloated the
kernel image to 600k+ which in an embedded world is not a good thing :-)

2) In 2.4.3 the console port using ttySX is broken.  It dumps fine to the
terminal but when you get to a point of entering data (login, configuration
scripts, etc) the terminal does not accept any input.  

So far I have been able to debug to the point where I see that the kernel is
receiving the characters from the serial.c driver.  But it never echos them
or does anything else with them.  I will continue to look into this at this
end.  

I was also wondering if anyone else has seen this or if a patch is avail for
this bug??

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

Re: [kbuild-devel] Re: Cross-referencing frenzy

[Rogier Wolff]

Eric S. Raymond wrote:
> Rogier Wolff <[EMAIL PROTECTED]>:
> > I think it should be possible to do: 
> > 
> > /* to enable the special stuff, change the "undef" to "define",
> >If you really want you can add this to Config.in so that you're presented
> >with this choice when configuring your kernel. But it's not neccesary
> >for the general public to always see this toggle.  */
> > #undef CONFIG_SX_SPECIALSTUFF
> > 
> > #ifdef CONFIG_SX_SPECIALSTUFF
> > ...
> > 
> > #endif
> 
> Yes, I could write and test code to handle this in about twenty minutes.
> And I was about to do it when I realized that it would be the wrong thing.
> 
> The right answer is that CONFIG_SX_SPECIALSTUFF *should* be flagged as
> an error -- because it doesn't belong in the CONFIG_ namespace, which
> by definition should be reserved for things the configurators control.
> 
> It should be called something else: perhaps ENABLE_SX_SPECIALSTUFF

You surely can do 

#undef ENABLE_SX_SPECIALSTUFF

however, then the "upgrade path" to a configurable parameter in the
configuration stuff is harder.

Now, as far as I know, this is rarely (if ever) used right now. (but
I've been tempted to do it in the past) Maybe with better
configuration tools, always declaring it a configuration option is a
good idea.

Think about it. Consider the issue, decide whatever you want. Tell me
about it. (i.e. what you suggest is the best way to deal with this.) (*)



Roger. 

(*) you may say: "But I just did that". However the above hints at
that you skipped over the "but I'd like to prepare for the case where
the configuration of that parameter should be made easier by including
it in the config mechanism."

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux timer performance ?

[Praveen Rajendran]

hi

I am working on a kernel module which requires the addition of a large
number of kernel timers  to expire statistical values ( including time
) maintained in a table.

One alternative would be to use a single timer and traverse the entire
table and use the existing system time to expire the values ( comparing
it with the time already stored in the table )when the timer expires .

Following the method I describe first I would have to add a large number
of timers ( around 2000) ... would this cause any significant
performance drop  ? which method should I use ?

thanks in advance

Praveen




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

Re: via udma100 fix

[David Balazic]

Andre Hedrick ([EMAIL PROTECTED]) wrote :

> Hi Dan, 
> 
> This was sent to me the other day, is this waht you are talking about? 
> 
> Cheers, 

+   /*
+*Turn off PCI Latency timeout (set to 0 clocks)
+*/
+   pci_write_config_byte(dev, 0x75, 0x80);

Is turning off PCI Latency a good thing ?

Anyway the article (http://home.tiscalinet.de/au-ja/review-kt133a-4.html)
says that any value below 32 is good, so why not use 16 for example ?

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

Re: PNP BIOS and parport_pc - dma found but not used

[Pavel Roskin]

Hello, Alan!

> > The setting is BIOS is to use irq 7 and dma 3. I normally use "options
> > parport_pc io=0x378 irq=7 dma=3" in /etc/modules.conf, but this time I
> > commented them out hoping that the driver will ask BIOS.
> >
> > PnPBIOS: Parport found PNPBIOS PNP0401 at io=0378,0778 irq=7 dma=-1
>
> Do you have it set in the BIOS itself to use DMA mode and to use DMA 3. The
> PnPBIOS should be reflecting your BIOS choices if I understand rightly

Yes, it is set in BIOS to use ECP, EPP, IRQ 7 and DMA 3.

There is another interesting line in the log that you didn't quote. The
driver actually knows about DMA 3:

0x378: ECP settings irq=7 dma=3

Just in case, that board is Asus P5A-B with the latest BIOS:
P5A-B BIOS ver. 1010, 05/31/2000

For comparison, I took a board with VIA chipset and PhoenixBIOS 4.0
Release 6.0, and it works properly with another 2.4.3-ac9 kernel:

Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ...
SMSC Super-IO detection, now testing Ports 2F0, 370 ...
PnPBIOS: Parport found PNPBIOS PNP0401 at io=0378,0778 irq=7 dma=3
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 8
0x378: readIntrThreshold is 8
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: ECP port cfgA=0x10 cfgB=0x4b
0x378: ECP settings irq=7 dma=3
parport0: PC-style at 0x378 (0x778), irq 7, dma 3
[PCSPP,TRISTATE,COMPAT,ECP,DMA]
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)

-- 
Regards,
Pavel Roskin

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

Re: ATA 100

[David Balazic]

Manuel Ignacio Monge Garcia ([EMAIL PROTECTED]) wrote :

> Hi. I have a ASUS A7V133 Motherboard with AMD ThinderBird 1 Ghz, and 
> PDC20265/VIA. I've tried all the possible combinations on "IDE, ATA and ATAPI 
> Block devices". I've read the "Unofficial Asus A7V and Linux ATA100 
> "Quasi-Mini-Howto" on http://www.geocities.com/ender7007/. But I still can't 
> use de IDE UDMA100 controler. I see some messages with this options on 
> earlier version of the ac-kernel, so I guess what I need to do the right 
> thing. My current kernel is 2.4.3-ac9. 
> Some settings: 

According to your dmesg output , hde is working in UDMA/100.
Since hde is the only device on your ATA/100 ( the PDC20265 )
controller , I don't see any problem.

Are the transfer rates not good ?
Whet is the output of hdparm -ti /dev/hde ?


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

Re: block devices don't work without plugging in 2.4.3

[Peter T. Breuer]

"Jens Axboe wrote:"
> [ptb wrote]
> > through merge_reqeusts function controls.
> > My unease derives, I think, from the fact that I have occasionally used
> > plugging for other purposes. Namely for throttling the device. These
> > uses have always been experimental and uniformly unsuccessful, because
> > throttling that way backs up the VFS with dirty buffers and provokes
> > precisely the deadlock against VFS that I was trying to avoid. So ..
> > 
> >  ... how can I tell when VFS is nearly full?  In those circumstances I
> > want to sync every _other_ device, thus giving me enough buffers at
> > least to flush something to the net with, thus freeing a request of
> > mine, plus its buffers.
> 
> You can't, there's currently no way of doing what you suggest. The block
> layer will throttle locked buffers for you. Besides, this would be the
> very wrong place to do it. If you reject or throttle requests, you are
> effectively throttling stuff that is already locked down and cannot be
> touched.

Oh, I agree. Exactly. It's pointless to throttle via requests/plugging.

However, it appears possible to deadlock if there is no way to detect
generic VFS fullness.  Let me explain the setting: part of the driver is
in user space, and it sends requests over the net.  It holds onto the
requests and their buffers while the user space process does the
networking (over ssl, sometimes) until an ack comes back.  There is an
obvious deadlock against VFS if the remote is on localhost (it has to
write the received requests to disk before acking, and it needs buffers
to do so ..), but there have been persistent sporadic reports that the
driver can occasionally deadlock even against a true remote host.

No such reports arise when I have forced a sync on the sender every
thousand requests or so, and people with problems report that mounting
an FS sync on the device solves their problem completely. This is
empirical evidence, but it suggests that there is a problem to be
avoided here. Thus I am keen to be able to detect how many buffers
there are that could be liberated by fsyncing _other_ devices, and
doing it.

I've never seen a way.

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

Re: ATA 100

[David Balazic]

Vojtech Pavlik ([EMAIL PROTECTED]) wrote :

> On Wed, Apr 18, 2001 at 10:21:53PM -0400, Manuel Ignacio Monge Garcia wrote: 
> 
> > El Mié 18 Abr 2001 15:16, escribiste: 
> > > I don't know about other possible problems with the kernel, but you must 
> > > use an 80 wire IDE cable for UDMA66/100 to work. 
> > > 
> > > > ---Primary IDE---Secondary IDE-- 
> > > > Cable Type: 40w 40w 
> > 
> > 
> > Strange thing. With previous version of kernel (2.4.1 I think), I 
> > haven't got this problem. May be a bios detection problem? 
> > 
> > Extract from /usr/src/linux/drivers/ide/via82cxxx..c: 
> > 
> > * 
> > * PIO 0-5, MWDMA 0-2, SWDMA 0-2 and UDMA 0-5 
> > * 
> > * (this includes UDMA33, 66 and 100) modes. UDMA66 and higher modes are 
> > * autoenabled only in case the BIOS has detected a 80 wire cable. To ignore 
> > * the BIOS data and assume the cable is present, use 'ide0=ata66' or 
> > * 'ide1=ata66' on the kernel command line. 
> > * 
> > 
> > I've tried with ide0=ata100, but this options doesn't work. 
> 
> Try ide0=ata66 instead. The option should have been named ide0=80wire, 
> but, well, "ata66" was chosen as the name, because that was it at the 
> time. 

Any chance of auto detecting this ?
I just hate when linux is relaying on the BIOS ...

BTW , why are there 666 CONFIG_.*IDE.*DMA.* switches ?

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

RE: Real Time Traffic Flow Measurement - anybody working on it?

[Michael Clark]

Can't say i'm actively working on it but I've emailed Nevil to see if
he knows of any RTFM work that is being done on Linux.

Although here's some observations:

Userspace pcap meters (such as NeTreMet) can measure traffic IP stack
doesn't even see (useful for a probe on a span port for instance) -
can also meter other protocols.

An obvious kernel improvement for userspace meters like NeTraMet would
be to give libpcap's pcap_read a kernel interface that can return more
than one packet at a time (the libpcap interface has this capability).
The current linux libpcap implementation incurs a read syscall per
packet.

An additional feature for network devices that could support it (not
sure if this is feasible) would be to switch to an 'interrupt when
packet buffer full' when in promiscuous mode.

A libpcap comment lists a bug in packet socket that means you need to
read the entire packet to get the packet length (which I assume means
meters like NeTraMet are forced to set the snaplen really high) -
which is a performance penalty if your just want to read headers but
also need the packet length.

from libpcap-0.6.2/pcap-linux.c

/*
 * XXX: According to the kernel source we should get the real
 * packet len if calling recvfrom with MSG_TRUNC set. It does
 * not seem to work here :(, but it is supported by this code
 * anyway.
 * To be honest the code RELIES on that feature so this is
really
 * broken with 2.2.x kernels.
 * I spend a day to figure out what's going on and I found out
 * that the following is happening:
 *
 * The packet comes from a random interface and the packet_rcv
 * hook is called with a clone of the packet. That code
inserts
 * the packet into the receive queue of the packet socket.
 * If a filter is attached to that socket that filter is run
 * first - and there lies the problem. The default filter
always
 * cuts the packet at the snaplen:
 *
 * # tcpdump -d
 * (000) ret  #68
 *
 * So the packet filter cuts down the packet. The recvfrom
call
 * says "hey, it's only 68 bytes, it fits into the buffer"
with
 * the result that we don't get the real packet length. This
 * is valid at least until kernel 2.2.17pre6.
 *
 * We currently handle this by making a copy of the filter
 * program, fixing all "ret" instructions with non-zero
 * operands to have an operand of 65535 so that the filter
 * doesn't truncate the packet, and supplying that modified
 * filter to the kernel.
 */

~mc

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Manfred Bartz
> Sent: Thursday, 19 April 2001 12:16 p.m.
> To: [EMAIL PROTECTED]
> Subject: Real Time Traffic Flow Measurement - anybody working on it?
>
>
> Through the stimulating discussion we had under ``IP Acounting
> Idea for 2.5'', it appears that a separate Traffic Flow Measure-
> ment and Accounting sub-system would be useful. See:
> 
>
> If anybody is working on Real Time Traffic Flow Measurement (RTFM)
> please reply.
>
> I would also like to know if there are any objections to providing
> a RTFM interface in the kernel (as an optional module).
>
> FYI:
>
> Considerable work has already been done on RTFM in general and
> for other systems:
> 
> 
>
> Relevant RFCs include: 2720 ... 2724
>
> Thanks
> --
> Manfred Bartz
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

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

Re: Cross-referencing frenzy

[Eric S. Raymond]

Jeff Garzik <[EMAIL PROTECTED]>:
> "Eric S. Raymond" wrote:
> > CONFIG_SOUND_YMPCI: arch/ppc/configs/power3_defconfig 
>arch/arm/def-configs/footbridge arch/arm/def-configs/rpc arch/arm/def-configs/lart 
>arch/arm/def-configs/shark
> 
> typo, that should be ...YMFPCI.
> 
> maybe you could add soundex to catch misspellings ;-)

Don't laugh.  I considered it -- only not with soundex but with 
Ratcliff/Obershelp gestalt similarity matching, which is better at
catching this sort of typo.  Python has a module for this; I could make
it happen with about two hours' work.
-- 
http://www.tuxedo.org/~esr/">Eric S. Raymond

You need only reflect that one of the best ways to get yourself 
a reputation as a dangerous citizen these days is to go about 
repeating the very phrases which our founding fathers used in the 
great struggle for independence.
-- Attributed to Charles Austin Beard (1874-1948)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

OOM tries to kill a root process eating all the memory but does not make it.

[Cabaniols, Sebastien]

Hello,

I have a process  which eats all the memory available 
(buy making a loop of mallocs, writing and reading the 
malloc'd memory) called memoryEater (to torture test
the memory system before going to a production system)

My kernel is 2.4.2smp on a 4 way Alpha machine with 8 Go
of  RAM.

When the process is launched under a user ID everything
works the way it should, i.e. the malloc works fine until 
the process eats 7.8 Gbytes of RAM and then the process
stops on a segfault.

When the process is launched under the root ID, I see
the OOM in the /var/log/messages saying it wants to kill
this process (memoryEater) but it does not kill it.

Hitting Control+C, kill PID -9 does not work. Halting the machine 
is my only solution.

Any ideas ?



--
Sebastien CABANIOLS
COMPAQ France 
HPTC Engineer
CustomSystems & Solutions  Annecy  
High Performance Technical Computing 
Office No.  +33 (0)4 50 09 44 10
Fax No.  +33 (0)4 50 64 01 39 
Email.   [EMAIL PROTECTED] 

--

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