ppp performance degradation?

[Adrian V. Bono]

Hi,

Could anyone please explain the major changes to the ppp module from
2.4.1 to 2.4.3? I've noticed that ppp performance isn't as fast as it
was using 2.4.1, and after a week using 2.4.3 i've concluded that ppp is
definitely slower. I've looked at the ppp_* files but so far the only
changes i saw were ppp_cleanup() being made static, and a new line added
to ppp_generic.c. Perhaps the major changes are in the rest of the
network code?

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

Re: No 100 HZ timer !

[Karim Yaghmour]

Mark Salisbury wrote:
> 
> It would probably be a good compile config option to allow fine or coarse
> process time accounting, that leaves the choice to the person setting up the
> system to make the choice based on their needs.
> 

I suggested this a while ago during a discussion about performance
measurement. This would be fairly easy to implement using the patch
provided with the Linux Trace Toolkit since all entry points and
exit points are known (and it already is available in post-mortem
analysis). Implementing the measurement code within the kernel should
be fairly easy to implement and it would be provided as part of the
compile option. All in all, given the measurements I made, I'd place
the overhead at around 1% for the computations. (The overhead is very
likely to be negligeable when eventual fixes are taken into account.)

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

Re: ide.2.2.19.04092001.patch

[William Park]

On Tue, Apr 10, 2001 at 10:35:54PM -0700, Shane Wegner wrote:
> Hi,
> 
> This isn't working here on my Abit VP6 board.  The
> ide.2.2.18.1221 works fine but this latest patch as well as
> ide.2.2.19.0325 fails.
> 
> Uniform Multi-Platform E-IDE driver Revision: 6.30
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> VP_IDE: IDE controller on PCI bus 00 dev 39
> VP_IDE: chipset revision 6
> VP_IDE: not 100% native mode: will probe irqs later
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
> ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:pio, hdd:pio
> HPT370: IDE controller on PCI bus 00 dev 70
> HPT370: chipset revision 3
> HPT370: not 100% native mode: will probe irqs later
> ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:pio, hdf:pio
> ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA, hdh:pio
> hda: Maxtor 92720U8, ATA DISK drive
> hdg: Maxtor 96147U8, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide3 at 0xe400-0xe407,0xe802 on irq 10
> 
> That's where it stops.  Locks solid, not even sysrq-b
> works.

Same here with my VP6.  ide-2.2.18 worked, but ide-2.2.19 doesn't.  

--William Park, Open Geometry Consulting, Linux/Python/LaTeX/vim, 8 CPUs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ide.2.2.19.04092001.patch

[Shane Wegner]

On Mon, Apr 09, 2001 at 05:33:13PM -0700, Andre Hedrick wrote:
> 
> This is up with some updates
Hi,

This isn't working here on my Abit VP6 board.  The
ide.2.2.18.1221 works fine but this latest patch as well as
ide.2.2.19.0325 fails.

Uniform Multi-Platform E-IDE driver Revision: 6.30
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:pio, hdd:pio
HPT370: IDE controller on PCI bus 00 dev 70
HPT370: chipset revision 3
HPT370: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA, hdh:pio
hda: Maxtor 92720U8, ATA DISK drive
hdg: Maxtor 96147U8, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide3 at 0xe400-0xe407,0xe802 on irq 10

That's where it stops.  Locks solid, not even sysrq-b
works.

Shane

-- 
Shane Wegner: [EMAIL PROTECTED]
  http://www.cm.nu/~shane/
PGP:  1024D/FFE3035D
  A0ED DAC4 77EC D674 5487
  5B5C 4F89 9A4E FFE3 035D
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.4 kernel problem

[David Ashley]

XFree86 X window updates are slower on 2.4 than 2.2, by a significant amount.
I've observed this comparing 2.2.18 with 2.4.1 and one of the 2.4.pre kernels.
I've seen it with ATI Rage 128, Geforce 1 and GeForce 2 MX. I've seen it on
two different computers, both Athlon based. Just any rectangular copies to
an X window are slow on 2.4 and much faster under 2.2.18.

I'm using DRI and accelerated GLX servers so I get good 3d, but 2d is
suffering in a *big* way. Here are some frames/second for a simple program:


Using shared memory   Kernel   frames/second
 yes   2.4  39
 no2.4  30
 yes   2.2.18  245
 no2.2.18   88

I can't get any response from the XFree86 team. I know I'm not the only
one with this trouble, something has been broken in the 2.4.

Thanks--
Dave
[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: [Lse-tech] Re: [PATCH for 2.5] preemptible kernel

[yodaiken]

On Tue, Apr 10, 2001 at 09:08:16PM -0700, Paul McKenney wrote:
> > Disabling preemption is a possible solution if the critical section is
> short
> > - less than 100us - otherwise preemption latencies become a problem.
> 
> Seems like a reasonable restriction.  Of course, this same limit applies
> to locks and interrupt disabling, right?

So supposing 1/2 us per update
lock process list
for every process update pgd
unlock process list

is ok if #processes <  200, but can cause some unspecified system failure
due to a dependency on the 100us limit otherwise?

And on a slower machine or with some heavy I/O possibilities 

We have a tiny little kernel to worry about inRTLinux and it's quite 
hard for us to keep track of all possible delays in such cases. How's this
going to work for Linux?


-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.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/

PATCH: PS/2 ESDI

[Hal Duston]

All,

Here is the second patch for ps2esdi.
This one corrects/updates the DMA handling.
In case my mailer mangles it, it is also available at
http://www.sound.net/~hald/projects/ps2esdi/ps2esdi-2.4.3.patch1

Thanks, and not on the list,
Hal Duston 
[EMAIL PROTECTED]


Bring DMA up to date with current MCA_DMA architecture.

Use mca_dma functions and macros.
Replace cli/sti with the DMA spinlock.

--- linux-2.4.3-hdd0/drivers/block/ps2esdi.cTue Apr 10 00:50:26 2001
+++ linux-2.4.3-hdd1/drivers/block/ps2esdi.cTue Apr 10 00:51:05 2001
@@ -52,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define PS2ESDI_IRQ 14
@@ -657,33 +658,23 @@
 /* prepare for dma - do all the necessary setup */
 static void ps2esdi_prep_dma(char *buffer, u_short length, u_char dma_xmode)
 {
-   u_int tc;
-   
-   buffer=(char *)virt_to_bus(buffer);
-
+   unsigned long flags;
 #if 0
printk("ps2esdi: b_wait: %p\n", &CURRENT->bh->b_wait);
 #endif
-   cli();
+   flags = claim_dma_lock();
 
-   outb(dma_arb_level | DMA_MASK_CHAN, PORT_DMA_FN);
+   mca_disable_dma(dma_arb_level);
 
-   outb(dma_arb_level | DMA_WRITE_ADDR, PORT_DMA_FN);
-   outb((u_int) buffer & (u_int) 0xff, PORT_DMA_EX);
-   outb(((u_int) buffer >> 8) & (u_int) 0xff, PORT_DMA_EX);
-   outb(((u_int) buffer >> 16) & (u_int) 0xff, PORT_DMA_EX);
+   mca_set_dma_addr(dma_arb_level, virt_to_bus(buffer));
 
-   outb(dma_arb_level | DMA_WRITE_TC, PORT_DMA_FN);
-   tc = (length * SECT_SIZE / 2) - 1;
-   outb(tc & 0xff, PORT_DMA_EX);
-   outb((tc >> 8) & 0xff, PORT_DMA_EX);
+   mca_set_dma_count(dma_arb_level, length * 512 / 2);
 
-   outb(dma_arb_level | DMA_WRITE_MODE, PORT_DMA_FN);
-   outb(dma_xmode, PORT_DMA_EX);
+   mca_set_dma_mode(dma_arb_level, dma_xmode);
 
-   outb(dma_arb_level | DMA_UNMASK_CHAN, PORT_DMA_FN);
+   mca_enable_dma(dma_arb_level);
 
-   sti();
+   release_dma_lock(flags);
 
 }  /* prepare for dma */
 
@@ -861,7 +852,9 @@
switch (int_ret_code & 0x0f) {
case INT_TRANSFER_REQ:
ps2esdi_prep_dma(CURRENT->buffer, CURRENT->current_nr_sectors,
-   (CURRENT->cmd == READ) ? DMA_READ_16 : DMA_WRITE_16);
+   (CURRENT->cmd == READ)
+   ? MCA_DMA_MODE_16 | MCA_DMA_MODE_WRITE | MCA_DMA_MODE_XFER
+   : MCA_DMA_MODE_16 | MCA_DMA_MODE_READ);
outb(CTRL_ENABLE_DMA | CTRL_ENABLE_INTR, ESDI_CONTROL);
ending = -1;
break;

Re: Let init know user wants to shutdown

[alad]

Kurt Roeckx <[EMAIL PROTECTED]> on 04/11/2001 06:16:52 AM

To:   Miquel van Smoorenburg <[EMAIL PROTECTED]>
cc:   [EMAIL PROTECTED] (bcc: Amol Lad/HSS)

Subject:  Re: Let init know user wants to shutdown




On Wed, Apr 11, 2001 at 01:38:30AM +0200, Kurt Roeckx wrote:
> On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
> >
> > the shutdown scripts
> > include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
> > "all processes except me". That means init will get hit with
> > SIGTERM occasionally during shutdown, and that might cause
> > weird things to happen.
>
> -1 mean everything but init.

>>> well. don't fight.. here is something from kernel/signal.c

asmlinkage int sys_kill(int pid, int sig){
...
...
return kill_something_info(sig,&info,pid)
}


int
kill_something_info(int sig, struct siginfo *info, int pid){
...
...
...
 if (pid == -1){
  for_each_task(p){(int
   if (p->pid >1 && p != current){
err = send_sig_info(sig,info,p);
...
...
   }
  }
 }

Amol


Oh, maybe you mean killall5 -TERM?

Which would send a SIGTERM to all processes but the one in his
own session.

(Hey look, you wrote that manpage.)


Kurt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Let init know user wants to shutdown

[John R Lenton]

On Tue, Apr 10, 2001 at 10:05:13AM -0700, Grover, Andrew wrote:
> This is not correct, because we want the power button to be configurable.
> The user should be able to redefine the power button's action, perhaps to
> only sleep the system. We currently surface button events to acpid, which
> then can do the right thing, including a shutdown -h now (which I assume
> notifies init).

Just today a friend saw my box shutdown via the powerbutton and
wondered if he coudln't set his up to trigger a different event
(actually two: he wanted his sister - the guilty party - zapped,
and a webcam shot of her face to prove it)...

-- 
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
¿Como meterán los cacahuetes dentro de la cáscara?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Lse-tech] Re: [PATCH for 2.5] preemptible kernel

[Paul McKenney]

> On Tue, 10 Apr 2001, Paul McKenney wrote:
> > The algorithms we have been looking at need to have absolute guarantees
> > that earlier activity has completed.  The most straightforward way to
> > guarantee this is to have the critical-section activity run with
preemption
> > disabled.  Most of these code segments either take out locks or run
> > with interrupts disabled anyway, so there is little or no degradation
of
> > latency in this case.  In fact, in many cases, latency would actually
be
> > improved due to removal of explicit locking primitives.
> >
> > I believe that one of the issues that pushes in this direction is the
> > discovery that "synchronize_kernel()" could not be a nop in a UP kernel
> > unless the read-side critical sections disable preemption (either in
> > the natural course of events, or artificially if need be).  Andi or
> > Rusty can correct me if I missed something in the previous exchange...
> >
> > The read-side code segments are almost always quite short, and, again,
> > they would almost always otherwise need to be protected by a lock of
> > some sort, which would disable preemption in any event.
> >
> > Thoughts?
>
> Disabling preemption is a possible solution if the critical section is
short
> - less than 100us - otherwise preemption latencies become a problem.

Seems like a reasonable restriction.  Of course, this same limit applies
to locks and interrupt disabling, right?

> The implementation of synchronize_kernel() that Rusty and I discussed
> earlier in this thread would work in other cases, such as module
> unloading, where there was a concern that it was not practical to have
> any sort of lock in the read-side code path and the write side was not
> time critical.

True, but only if the synchronize_kernel() implementation is applied to UP
kernels, also.

Thanx, Paul

> Nigel Gamble[EMAIL PROTECTED]
> Mountain View, CA, USA. http://www.nrg.org/
>
> MontaVista Software [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: No 100 HZ timer !

[george anzinger]

Mark Salisbury wrote:
> 
> > mark salisbury wrote:
> > >
> > > george anzinger wrote:
> > >
> > > > f) As noted, the account timers (task user/system times) would be much
> > > > more accurate with the tick less approach.  The cost is added code in
> > > > both the system call and the schedule path.
> > > >
> > > > Tentative conclusions:
> > > >
> > > > Currently we feel that the tick less approach is not acceptable due to
> > > > (f).  We felt that this added code would NOT be welcome AND would, in
> a
> > > > reasonably active system, have much higher overhead than any savings
> in
> > > > not having a tick.  Also (d) implies a list organization that will, at
> > > > the very least, be harder to understand.  (We have some thoughts here,
> > > > but abandoned the effort because of (f).)  We are, of course, open to
> > > > discussion on this issue and all others related to the project
> > > > objectives.
> > >
> > > f does not imply tick-less is not acceptable, it implies that better
> process time
> > > accounting is not acceptable.
> >
> > My thinking is that a timer implementation that forced (f) would have
> > problems gaining acceptance (even with me :).  I think a tick less
> > system does force this and this is why we have, at least for the moment,
> > abandoned it.  In no way does this preclude (f) as it is compatible with
> > either ticks or tick less time keeping.  On the other hand, the stated
> > project objectives do not include (f) unless, of course we do a tick
> > less time system.
> > >
> > > list organization is not complex, it is a sorted absolute time list.  I
> would
> > > argue that this is a hell of a lot easier to understand that ticks +
> offsets.
> >
> > The complexity comes in when you want to maintain indexes into the list
> > for quick insertion of new timers.  To get the current insert
> > performance, for example, you would need pointers to (at least) each of
> > the next 256 centasecond boundaries in the list.  But the list ages, so
> > these pointers need to be continually updated.  The thought I had was to
> > update needed pointers (and only those needed) each time an insert was
> > done and a needed pointer was found to be missing or stale.  Still it
> > adds complexity that the static structure used now doesn't have.
> 
> actually, I think a head and tail pointer would be sufficient for most
> cases. (most new timers are either going to be a new head of list or a new
> tail, i.e. long duration timeouts that will never be serviced or short
> duration timers that are going to go off "real soon now (tm)")  the oddball
> cases would be mostly coming from user-space, i.e. nanosleep which a longerr
> list insertion disapears in the block/wakeup/context switch overhead
> 
> > >
> > > still, better process time accounting should be a compile CONFIG option,
> not
> > > ignored and ruled out because some one thinks that is is to expensive in
> the
> > > general case.
> >
> > As I said above, we are not ruling it out, but rather, we are not
> > requiring it by going tick less.
> > As I said, it is not clear how you could get
> > CONFIG_USELESS_PROCESS_TIME_ACCOUNTING unless you did a tick every
> > jiffie.  What did you have in mind?
> 
> time accounting can be limited to the quantum expiration and voluntary
> yields in the tickless/useless case.
> 
> > For the most part, I agree.  I am not sure that it makes a lot of sense
> > to mix some of these options, however.  I think it comes down to the
> > question of benefit vs cost.  If keeping an old version around that is
> > not any faster or more efficient in any way would seem too costly to
> > me.  We would like to provide a system that is better in every way and
> > thus eliminate the need to keep the old one around.  We could leave it
> > in as a compile option so folks would have a fall back, I suppose.
> 
> I agree that some combinations don't make much sense _TO_ME_ but that
> doesn't mean they don't meet sombody's needs.
> 
> in my case (embedded, medium hard real time, massively parallel
> multicomputer)  the only choices that makes sense to my customers is
> tickless/useless in deployment and tickless/useful in
> development/profiling/optimization.

I suspect you might go for ticked if its overhead was less.  The thing
that makes me think the overhead is high for tick less is the accounting
and time slice stuff.  This has to be handled each system call and each
schedule call.  These happen WAY more often than ticks...  Contrary
wise, I would go for tick less if its overhead is the same or less under
a reasonable load.  Of course, we would also want to check overload
sensitivity.
> 
> in other cases ticked/useless makes sense (dumb old slow chips)
> 
> I have no idea who would want ticked/useful or hybrid.  i suggested hybrid
> as an alternative in case linus might be reluctant to gutting and replacing
> the sysclock.
> 
> >
> > An Issue no one has raised is that the tick less system would need to
> > start a timer each t

2.5 module development mailing list needed? [Fwd: Linux Security Module Interface]

[Miles Lane]

Hi,

Since the 2.5 kernel development will require continued module
architecture changes to accomodate power management, pluggable
security and PCMCIA in the kernel tree, it would seem to make
sense that the various groups that are doing module related
architecture changes collaborate and be aware of what each
other are doing, so that changes can be coordinated.

Groups that contain individuals who might be interested 
might include:  

[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LKML

Comments?

Miles

Crispin Cowan wrote:
> 
> One of the byproducts of the Linux 2.5 Kernel Summit
> http://lwn.net/2001/features/KernelSummit/ was the notion of an
> enhancement of the loadable kernel module interface to facilitate
> security-oriented kernel modules.  The purpose is to ease the tension
> between folks (such as Immunix and SELinux) who want to add substantial
> security capabilities to the kernel, and other folks who want to
> minimize kernel bloat & have no use for such security extensions.
> 
> Modules that can be loaded, or not, are the obvious solution, but the
> current LKM does not export sufficient hooks to support many security
> mechanisms.  Thus many current security enhancements end up existing as
> kernel patches, which marginalizes their utility by making distribution
> problematic. The proposed solution is to enhance the LKM with a variety
> of new kernel elements exported to the module interface, so as to
> support a reasonable variety of security enhancements.
> 
> We have started a new mailing list called linux-security-module.  The
> charter is to design, implement, and maintain suitable enhancements to
> the LKM to support a reasonable set of security enhancement packages.
> The prototypical module to be produced would be to port the POSIX Privs
> code out of the kernel and make it a module.  An essential part of this
> project will be that the resulting work is acceptable for the mainline
> Linux kernel.
> 
> The list is open to all.  You can subscribe here
> http://mail.wirex.com/mailman/listinfo/linux-security-module or by
> sending e-mail to [EMAIL PROTECTED] with a subject
> of "subscribe".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386 rw_semaphores fix

[Andi Kleen]

On Tue, Apr 10, 2001 at 06:12:12PM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 11 Apr 2001, Andi Kleen wrote:
> >
> > Fixup for user space is probably not that nice (CMPXCHG is used there by
> > linuxthreads)
> 
> In user space I'm not convinced that you couldn't do the same thing
> equally well by just having the proper dynamically linked library.  You'd
> not get in-lined lock primitives, but that's probably fine.

It's currently done this way, ld-linux.so looks in a special "686" path when
the ELF vector mentions it, otherwise normal path. There is a special 686
version of glibc and linuxthread. Just it's a very complicated and disk 
space chewing solution for a simple problem (some distributions are starting 
to drop support for 386 because of that)

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

Re: [PATCH] i386 rw_semaphores fix

[Linus Torvalds]

On Wed, 11 Apr 2001, Andi Kleen wrote:
>
> Fixup for user space is probably not that nice (CMPXCHG is used there by
> linuxthreads)

In user space I'm not convinced that you couldn't do the same thing
equally well by just having the proper dynamically linked library.  You'd
not get in-lined lock primitives, but that's probably fine.

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] i386 rw_semaphores fix

[Andi Kleen]

On Tue, Apr 10, 2001 at 05:55:09PM -0700, Linus Torvalds wrote:
> Note that the "fixup" approach is not necessarily very painful at all,
> from a performance standpoint (either on 386 or on newer CPU's). It's not
> really that hard to just replace the instruction in the "undefined
> instruction"  handler by having strict rules about how to use the "xadd"
> instruction.

Fixup for user space is probably not that nice (CMPXCHG is used there by 
linuxthreads) 


-Andi


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

Re: bizarre TCP behavior

[Andi Kleen]

On Tue, Apr 10, 2001 at 05:35:31PM -0700, Mike Castle wrote:
> On Wed, Apr 11, 2001 at 02:21:42AM +0200, Andi Kleen wrote:
> > Try echo 0 > /proc/sys/net/ipv4/tcp_ecn
> > If it helps complain to the sites that their firewall is broken.
> 
> It's certain that this refers only to the site firewall?
>
> I had to do this to get to www.ibm.com.  :-<

iirc some load balancer also doesn't like them.


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

Re: [PATCH] i386 rw_semaphores fix

[Andi Kleen]

On Wed, Apr 11, 2001 at 02:56:32AM +0200, David Weinehall wrote:
> My reasoning is that the choice of computer is a direct function of
> your financial situation. I can get hold of a lot of 386's/486's, but
> however old a Pentium may be, people are still reluctant to give away
> those. Doing the sometimes necessary updates on my 386:en is already
> painfully slow, and I'd rather not take another performance hit.

As long as you don't use multithreaded applications there is no performance
hit with a kernel-mode CMPXCHG handler. iirc most multithreaded applications
are either too bloated for a 386 anyways, or trivial so that it doesn't matter.

-Andi

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

Re: [PATCH] i386 rw_semaphores fix

[David Weinehall]

On Wed, Apr 11, 2001 at 02:20:28AM +0200, Andi Kleen wrote:
> On Wed, Apr 11, 2001 at 02:13:18AM +0200, David Weinehall wrote:
> > > 
> > > Yes, and with CMPXCHG handler in the kernel it wouldn't be needed 
> > > (the other 686 optimizations like memcpy also work on 386) 
> > 
> > But the code would be much slower, and it's on 386's and similarly
> > slow beasts you need every cycle you can get, NOT on a Pentium IV.
> 
> My reasoning is that who uses a 386 is not interested in speed, so a little
> bit more slowness is not that bad.

My reasoning is that the choice of computer is a direct function of
your financial situation. I can get hold of a lot of 386's/486's, but
however old a Pentium may be, people are still reluctant to give away
those. Doing the sometimes necessary updates on my 386:en is already
painfully slow, and I'd rather not take another performance hit.

> You realize that the alternative for distributions is to drop 386 support
> completely?

Yes, I realise that. But if _distribution X_ drops support for the 386,
there's always _distribution Y_ available with it still in, while if
we give the glibc-people the thumbs up saying "Ignore the 386 users from
now on", every distribution will get lousy performance on those machines.

> Most 386 i've seen used for linux do not run multi threaded applications
> anyways; they usually do things like ISDN routing. Also on early 386 with
> the kernel mode wp bug it's a security hazard to use clone().

Well, not all 386:en are early...


/David
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i386 rw_semaphores fix

[Linus Torvalds]

On Wed, 11 Apr 2001, David Weinehall wrote:
> >
> > Yes, and with CMPXCHG handler in the kernel it wouldn't be needed
> > (the other 686 optimizations like memcpy also work on 386)
>
> But the code would be much slower, and it's on 386's and similarly
> slow beasts you need every cycle you can get, NOT on a Pentium IV.

Note that the "fixup" approach is not necessarily very painful at all,
from a performance standpoint (either on 386 or on newer CPU's). It's not
really that hard to just replace the instruction in the "undefined
instruction"  handler by having strict rules about how to use the "xadd"
instruction.

For example, you would not actually fix up the xadd to be a function call
to something that emulates "xadd" itself on a 386. You would fix up the
whole sequence of "inline down_write()" with a simple call to an
out-of-line "i386_down_write()" function.

Note that down_write() on an old 386 is likely to be complicated enough
that you want to do it out-of-line anyway, so the code-path you take
(afetr the first time you've trapped on that particular location) would be
the one you would take for an optimized 386 kernel anyway. And similarly,
the restrictions you place on non-386-code to make it fixable are simple
enough that it probably shouldn't make a difference for performance on
modern chips.

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: No 100 HZ timer !

[Mark Salisbury]

> mark salisbury wrote:
> >
> > george anzinger wrote:
> >
> > > f) As noted, the account timers (task user/system times) would be much
> > > more accurate with the tick less approach.  The cost is added code in
> > > both the system call and the schedule path.
> > >
> > > Tentative conclusions:
> > >
> > > Currently we feel that the tick less approach is not acceptable due to
> > > (f).  We felt that this added code would NOT be welcome AND would, in
a
> > > reasonably active system, have much higher overhead than any savings
in
> > > not having a tick.  Also (d) implies a list organization that will, at
> > > the very least, be harder to understand.  (We have some thoughts here,
> > > but abandoned the effort because of (f).)  We are, of course, open to
> > > discussion on this issue and all others related to the project
> > > objectives.
> >
> > f does not imply tick-less is not acceptable, it implies that better
process time
> > accounting is not acceptable.
>
> My thinking is that a timer implementation that forced (f) would have
> problems gaining acceptance (even with me :).  I think a tick less
> system does force this and this is why we have, at least for the moment,
> abandoned it.  In no way does this preclude (f) as it is compatible with
> either ticks or tick less time keeping.  On the other hand, the stated
> project objectives do not include (f) unless, of course we do a tick
> less time system.
> >
> > list organization is not complex, it is a sorted absolute time list.  I
would
> > argue that this is a hell of a lot easier to understand that ticks +
offsets.
>
> The complexity comes in when you want to maintain indexes into the list
> for quick insertion of new timers.  To get the current insert
> performance, for example, you would need pointers to (at least) each of
> the next 256 centasecond boundaries in the list.  But the list ages, so
> these pointers need to be continually updated.  The thought I had was to
> update needed pointers (and only those needed) each time an insert was
> done and a needed pointer was found to be missing or stale.  Still it
> adds complexity that the static structure used now doesn't have.

actually, I think a head and tail pointer would be sufficient for most
cases. (most new timers are either going to be a new head of list or a new
tail, i.e. long duration timeouts that will never be serviced or short
duration timers that are going to go off "real soon now (tm)")  the oddball
cases would be mostly coming from user-space, i.e. nanosleep which a longerr
list insertion disapears in the block/wakeup/context switch overhead

> >
> > still, better process time accounting should be a compile CONFIG option,
not
> > ignored and ruled out because some one thinks that is is to expensive in
the
> > general case.
>
> As I said above, we are not ruling it out, but rather, we are not
> requiring it by going tick less.
> As I said, it is not clear how you could get
> CONFIG_USELESS_PROCESS_TIME_ACCOUNTING unless you did a tick every
> jiffie.  What did you have in mind?

time accounting can be limited to the quantum expiration and voluntary
yields in the tickless/useless case.

> For the most part, I agree.  I am not sure that it makes a lot of sense
> to mix some of these options, however.  I think it comes down to the
> question of benefit vs cost.  If keeping an old version around that is
> not any faster or more efficient in any way would seem too costly to
> me.  We would like to provide a system that is better in every way and
> thus eliminate the need to keep the old one around.  We could leave it
> in as a compile option so folks would have a fall back, I suppose.

I agree that some combinations don't make much sense _TO_ME_ but that
doesn't mean they don't meet sombody's needs.

in my case (embedded, medium hard real time, massively parallel
multicomputer)  the only choices that makes sense to my customers is
tickless/useless in deployment and tickless/useful in
development/profiling/optimization.

in other cases ticked/useless makes sense (dumb old slow chips)

I have no idea who would want ticked/useful or hybrid.  i suggested hybrid
as an alternative in case linus might be reluctant to gutting and replacing
the sysclock.

>
> An Issue no one has raised is that the tick less system would need to
> start a timer each time it scheduled a task.  This would lead to either
> slow but very precise time slicing or about what we have today with more
> schedule overhead.

no.  you would re-use the timer with a new expiration time and a re-insert.

also re overhead. the cost of servicing 10 times as many interrupts as
necessary for system function must cost a fair chunk.



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

[Crispin Cowan]

One of the byproducts of the Linux 2.5 Kernel Summit
http://lwn.net/2001/features/KernelSummit/ was the notion of an
enhancement of the loadable kernel module interface to facilitate
security-oriented kernel modules.  The purpose is to ease the tension
between folks (such as Immunix and SELinux) who want to add substantial
security capabilities to the kernel, and other folks who want to
minimize kernel bloat & have no use for such security extensions.

Modules that can be loaded, or not, are the obvious solution, but the
current LKM does not export sufficient hooks to support many security
mechanisms.  Thus many current security enhancements end up existing as
kernel patches, which marginalizes their utility by making distribution
problematic. The proposed solution is to enhance the LKM with a variety
of new kernel elements exported to the module interface, so as to
support a reasonable variety of security enhancements.

We have started a new mailing list called linux-security-module.  The
charter is to design, implement, and maintain suitable enhancements to
the LKM to support a reasonable set of security enhancement packages.
The prototypical module to be produced would be to port the POSIX Privs
code out of the kernel and make it a module.  An essential part of this
project will be that the resulting work is acceptable for the mainline
Linux kernel.

The list is open to all.  You can subscribe here
http://mail.wirex.com/mailman/listinfo/linux-security-module or by
sending e-mail to [EMAIL PROTECTED] with a subject
of "subscribe".

Crispin

--
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:   http://immunix.org



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386 rw_semaphores fix

[Tim Wright]

Sequent Symmetry machinses supported SMP on i486 and even i386 going back
to the original 16MHz 386 processors. You could put up to 30 in a system.
I do not, however, envisage anyone porting Linux to these any time soon.
The hardware is just too "unusual" for it to be feasible. The later Symmetry
5000 machines might be slightly more practical, but I'm not sure if you'd have
room in your new house for one. You could probably do without central heating
if we did send you one :-)

Tim

On Tue, Apr 10, 2001 at 10:57:09PM +0100, Alan Cox wrote:
> > That's no problem if we make this SMP-specific - I doubt anybody actually
> > uses SMP on i486's even if the machines exist, as I think they all had
> 
> They do. There are two (total world wide) 486 SMP users I know about and they
> mostly do it to be awkward ;)
> 
> > special glue logic that Linux would have trouble with anyway. But the
> 
> The Compaqs were custom, the non Compaq ones included several using Intel
> MP 1.1.
> 
> 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/

-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: bizarre TCP behavior

[Mike Castle]

On Wed, Apr 11, 2001 at 02:21:42AM +0200, Andi Kleen wrote:
> Try echo 0 > /proc/sys/net/ipv4/tcp_ecn
> If it helps complain to the sites that their firewall is broken.

It's certain that this refers only to the site firewall?

I had to do this to get to www.ibm.com.  :-<

mrc
-- 
   Mike Castle   Life is like a clock:  You can work constantly
  [EMAIL PROTECTED]  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
We are all of us living in the shadow of Manhattan.  -- Watchmen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: bizarre TCP behavior

[Andi Kleen]

On Tue, Apr 10, 2001 at 06:24:46PM -0400, Dave wrote:
> 
> I am having a very strange problem in linux 2.4 kernels.  I have not set
> any iptables rules at all, and there is no firewall blocking any of my
> outgoing traffic.  At what seems like random selection, I can not connect
> to IP's yet I can get ping replies from them.  Most IP's reply just fine,
> but certain ones fail to send even an ACK.  This problem disappears when I
> boot into 2.2.  Here is a brief example of what I am talking about:

Try echo 0 > /proc/sys/net/ipv4/tcp_ecn
If it helps complain to the sites that their firewall is broken.


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

Re: [PATCH] i386 rw_semaphores fix

[Andi Kleen]

On Wed, Apr 11, 2001 at 02:13:18AM +0200, David Weinehall wrote:
> > 
> > Yes, and with CMPXCHG handler in the kernel it wouldn't be needed 
> > (the other 686 optimizations like memcpy also work on 386) 
> 
> But the code would be much slower, and it's on 386's and similarly
> slow beasts you need every cycle you can get, NOT on a Pentium IV.

My reasoning is that who uses a 386 is not interested in speed, so a little
bit more slowness is not that bad.

You realize that the alternative for distributions is to drop 386 support
completely?

Most 386 i've seen used for linux do not run multi threaded applications
anyways; they usually do things like ISDN routing. Also on early 386 with
the kernel mode wp bug it's a security hazard to use clone().

-Andi

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

Re: [PATCH] i386 rw_semaphores fix

[David Weinehall]

On Wed, Apr 11, 2001 at 02:00:58AM +0200, Andi Kleen wrote:
> On Tue, Apr 10, 2001 at 11:00:31PM +0100, Alan Cox wrote:
> > > I guess 386 could live with an exception handler that emulates it.
> > 
> > 386 could use a simpler setup and is non SMP
> 
> The idea was to have a `generic' kernel that works on all architectures.
> If you drop 386 support much is better already.
>  
> > > (BTW an generic exception handler for CMPXCHG would also be very useful
> > > for glibc -- currently it has special checking code for 386 in its mutexes) 
> > > The 386 are so slow that nobody would probably notice a bit more slowness
> > > by a few exceptions.
> > 
> > Be serious. You can compile glibc without 386 support. Most vendors already
> > distribute 386/586 or 386/686 glibc sets.
> 
> Yes, and with CMPXCHG handler in the kernel it wouldn't be needed 
> (the other 686 optimizations like memcpy also work on 386) 

But the code would be much slower, and it's on 386's and similarly
slow beasts you need every cycle you can get, NOT on a Pentium IV.


/David
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] comments about conflicting SCSI/CDROM ioctls

[Andreas Dilger]

This patch adds a couple of comments to the cdrom and SCSI code warning of
duplicate ioctl numbers.

Cheers, Andreas

diff -ru linux.orig/include/linux/cdrom.h linux/include/linux/cdrom.h
--- linux.orig/include/linux/cdrom.hThu Jan  4 15:50:47 2001
+++ linux/include/linux/cdrom.h Fri Feb 16 17:12:05 2001
@@ -128,8 +128,13 @@
 #define CDROM_DEBUG0x5330  /* Turn debug messages on/off */
 #define CDROM_GET_CAPABILITY   0x5331  /* get capabilities */
 
+/* Note that scsi/scsi_ioctl.h also uses 0x5382 - 0x5386.
+ * Future CDROM ioctls should be kept below 0x537F
+ */
+
 /* This ioctl is only used by sbpcd at the moment */
 #define CDROMAUDIOBUFSIZ0x5382 /* set the audio buffer size */
+   /* conflict with SCSI_IOCTL_GET_IDLUN */
 
 /* DVD-ROM Specific ioctls */
 #define DVD_READ_STRUCT0x5390  /* Read structure */
diff -ru -x .[a-z]* ./include/scsi/scsi.h /usr/src/linux-2.4.0-0.3/include/scsi/scsi.h
--- ./include/scsi/scsi.h   Tue Sep  5 15:08:55 2000
+++ /usr/src/linux-2.4.0-0.3/include/scsi/scsi.hFri Feb 16 17:11:51 2001
@@ -196,8 +196,9 @@
  * Here are some scsi specific ioctl commands which are sometimes useful.
  */
 /* These are a few other constants  only used by scsi  devices */
+/* Note that include/linux/cdrom.h also defines IOCTL 0x5300 - 0x5395 */
 
-#define SCSI_IOCTL_GET_IDLUN 0x5382
+#define SCSI_IOCTL_GET_IDLUN 0x5382/* conflicts with CDROMAUDIOBUFSIZ */
 
 /* Used to turn on and off tagged queuing for scsi devices */
 
-- 
Andreas Dilger   TurboLabs filesystem development
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386 rw_semaphores fix

[Andi Kleen]

On Tue, Apr 10, 2001 at 11:00:31PM +0100, Alan Cox wrote:
> > I guess 386 could live with an exception handler that emulates it.
> 
> 386 could use a simpler setup and is non SMP

The idea was to have a `generic' kernel that works on all architectures.
If you drop 386 support much is better already.
 
> > (BTW an generic exception handler for CMPXCHG would also be very useful
> > for glibc -- currently it has special checking code for 386 in its mutexes) 
> > The 386 are so slow that nobody would probably notice a bit more slowness
> > by a few exceptions.
> 
> Be serious. You can compile glibc without 386 support. Most vendors already
> distribute 386/586 or 386/686 glibc sets.

Yes, and with CMPXCHG handler in the kernel it wouldn't be needed 
(the other 686 optimizations like memcpy also work on 386) 

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

Re: Let init know user wants to shutdown

[Miquel van Smoorenburg]

According to Kurt Roeckx:
> On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
> > The "-1" means
> > "all processes except me". That means init will get hit with
> > SIGTERM occasionally during shutdown, and that might cause
> > weird things to happen.
> 
> -1 mean everything but init.
> 
> From the manpage:

Oh. OK, so this is yet another special case for init - forget to
check those. Sorry about that (hey it's 01:53 here, I should be
in bed).  Yet I still think it'd be a better idea to use RT signals,
see my other message in this thread.

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

Re: [Lse-tech] Re: [PATCH for 2.5] preemptible kernel

[Nigel Gamble]

On Tue, 10 Apr 2001, Paul McKenney wrote:
> The algorithms we have been looking at need to have absolute guarantees
> that earlier activity has completed.  The most straightforward way to
> guarantee this is to have the critical-section activity run with preemption
> disabled.  Most of these code segments either take out locks or run
> with interrupts disabled anyway, so there is little or no degradation of
> latency in this case.  In fact, in many cases, latency would actually be
> improved due to removal of explicit locking primitives.
>
> I believe that one of the issues that pushes in this direction is the
> discovery that "synchronize_kernel()" could not be a nop in a UP kernel
> unless the read-side critical sections disable preemption (either in
> the natural course of events, or artificially if need be).  Andi or
> Rusty can correct me if I missed something in the previous exchange...
> 
> The read-side code segments are almost always quite short, and, again,
> they would almost always otherwise need to be protected by a lock of
> some sort, which would disable preemption in any event.
> 
> Thoughts?

Disabling preemption is a possible solution if the critical section is short
- less than 100us - otherwise preemption latencies become a problem.

The implementation of synchronize_kernel() that Rusty and I discussed
earlier in this thread would work in other cases, such as module
unloading, where there was a concern that it was not practical to have
any sort of lock in the read-side code path and the write side was not
time critical.

Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/

MontaVista Software [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: Let init know user wants to shutdown

[Kurt Roeckx]

On Wed, Apr 11, 2001 at 01:38:30AM +0200, Kurt Roeckx wrote:
> On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
> > 
> > the shutdown scripts
> > include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
> > "all processes except me". That means init will get hit with
> > SIGTERM occasionally during shutdown, and that might cause
> > weird things to happen.
> 
> -1 mean everything but init.

Oh, maybe you mean killall5 -TERM?

Which would send a SIGTERM to all processes but the one in his
own session.

(Hey look, you wrote that manpage.)


Kurt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 Compile errors - 2.4.3ac2 through ac4

[Mordrid Nightshade]

Hey,
I've been trying to compile 2.4.3ac2 - ac4 and have had the same problem everytime.
It deals with pmac_pic.c (I sent this to Cort <[EMAIL PROTECTED]> as well)
As I never meddle with kernel source I'm sorta at a loss (hope to change this one day)

Error is as follows:

gcc -D__KERNEL__ -I/usr/src/2.4.3/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -D__powerpc__ -fsigned-char -msoft-float 
-pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring-c -o pmac_pic.o pmac_pic.c
In file included from /usr/src/2.4.3/include/linux/sched.h:9,
from pmac_pic.c:4:
/usr/src/2.4.3/include/linux/binfmts.h:45: warning: `struct mm_struct' declared inside 
parameter list
/usr/src/2.4.3/include/linux/binfmts.h:45: warning: its scope is only this definition 
or declaration, which is probably not what you want.
pmac_pic.c:47: parse error before `{'
make[1]: *** [pmac_pic.o] Error 1
make[1]: Leaving directory `/usr/src/2.4.3/arch/ppc/kernel'
make: *** [_dir_arch/ppc/kernel] Error 2

I appreciate the help

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

Re: Let init know user wants to shutdown

[Mike Castle]

On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> Pavel Machek  <[EMAIL PROTECTED]> wrote:
> >Init should get to know that user pressed power button (so it can do
> >shutdown and poweroff). Plus, it is nice to let user know that we can
> 
> Not so hasty ;)
> 
> >+printk ("acpi: Power button pressed!\n");
> >+kill_proc (1, SIGTERM, 1);

[reasons deleted]

Is using a signal the appropriate thing to do anyway?

Wouldn't there be better solutions?

Perhaps a mechanism a user space program can use to communicate to the kernel
(ala arpd/kerneld message queues, or something like klogd).  Then a more
general user space tool could be used that would do policy appropriate
stuff, ending with init 0.

mrc
-- 
   Mike Castle   Life is like a clock:  You can work constantly
  [EMAIL PROTECTED]  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
We are all of us living in the shadow of Manhattan.  -- Watchmen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Let init know user wants to shutdown

[Kurt Roeckx]

On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
> 
> the shutdown scripts
> include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
> "all processes except me". That means init will get hit with
> SIGTERM occasionally during shutdown, and that might cause
> weird things to happen.

-1 mean everything but init.

>From the manpage:

   If pid equals -1, then sig is sent to every process except
   for the first one, from  higher  numbers  in  the  process
   table to lower.

And later:

BUGS
   It  is impossible to send a signal to task number one, the
   init process, for which it has not installed a signal han-
   dler.   This  is  done to assure the system is not brought
   down accidentally.


Kurt

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

[Andreas Dilger]

The following patch adds the LVM ioctl number to Documentation/ioctl-numer.txt.
I had previously sent this directly to MEC as well.

Cheers, Andreas
==
--- linux.orig/Documentation/ioctl-number.txt   Tue Apr 10 17:13:00 2001
+++ linux/Documentation/ioctl-number.txtTue Apr 10 17:10:40 2001
@@ -186,3 +186,5 @@
 0xB1   00-1F   PPPoX   
 0xCB   00-1F   CBM serial IEC bus  in development:

+
+0xFE   00-9F   Logical Volume Manager  

-- 
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: Let init know user wants to shutdown

[Miquel van Smoorenburg]

In article <9b04fo$9od$[EMAIL PROTECTED]>,
Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote:
>SIGTERM is a bad choise. Right now, init ignores SIGTERM. For
>good reason; on some (many?) systems, the shutdown scripts
>include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
>"all processes except me". That means init will get hit with
>SIGTERM occasionally during shutdown, and that might cause
>weird things to happen.
>
>Perhaps SIGUSR1 ?

In the immortal words of Max Headroom, t-t-talking to myself ;)

In fact, the kernel should probably use a real-time signal
with si_code set to 1 for ctrl-alt-del, 2 for the powerbutton etc.

It should first check if process 1 (init) installed a handler
for that real-time signal. If not, it should use the old
signals (SIGINT for ctrl-alt-del, SIGWINCH for kbrequest).

Mike.

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

[PATCH] minor PCI fixup

[Andreas Dilger]

Attached is a very minor patch that is in my tree (I don't even remember why
I was in there) which uses the defined PCI vendor ID instead of a number.

Cheers, Andreas

diff -ru linux.orig/drivers/scsi/atp870u.c linux/drivers/scsi/atp870u.c
--- linux.orig/drivers/scsi/atp870u.c   Sat Nov 11 20:01:11 2000
+++ linux/drivers/scsi/atp870u.cWed Mar  7 12:58:10 2001
@@ -1668,7 +1668,7 @@
}
h = 0;
while (devid[h] != 0) {
-   pdev[2] = pci_find_device(0x1191, devid[h], pdev[2]);
+   pdev[2] = pci_find_device(PCI_VENDOR_ID_ARTOP,devid[h],pdev[2]);
if (pdev[2] == NULL || pci_enable_device(pdev[2])) {
h++;
index = 0;
-- 
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: Let init know user wants to shutdown

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Pavel Machek  <[EMAIL PROTECTED]> wrote:
>Hi!
>
>Init should get to know that user pressed power button (so it can do
>shutdown and poweroff). Plus, it is nice to let user know that we can
>read such event. [I hunted bug for few hours, thinking that kernel
>does not get the event at all].
>
>Here's patch to do that. Please apply,

Not so hasty ;)

>+  printk ("acpi: Power button pressed!\n");
>+  kill_proc (1, SIGTERM, 1);

SIGTERM is a bad choise. Right now, init ignores SIGTERM. For
good reason; on some (many?) systems, the shutdown scripts
include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
"all processes except me". That means init will get hit with
SIGTERM occasionally during shutdown, and that might cause
weird things to happen.

Perhaps SIGUSR1 ?

Mike.

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

Re: bizarre TCP behavior

[Dave]

This did fix my problem.  Thanks very much, I'll be sure to send a polite
message to the admins at sites where I notice this problem!  Any detailed
info you might have on why this was failing?
dave

---

This is my signature.  There are many like it but this one is mine.

On Tue, 10 Apr 2001, Gregory Maxwell wrote:

> On Tue, Apr 10, 2001 at 06:24:46PM -0400, Dave wrote:
> > I am having a very strange problem in linux 2.4 kernels.  I have not set
> > any iptables rules at all, and there is no firewall blocking any of my
> > outgoing traffic.  At what seems like random selection, I can not connect
> > to IP's yet I can get ping replies from them.  Most IP's reply just fine,
> > but certain ones fail to send even an ACK.  This problem disappears when I
> > boot into 2.2.  Here is a brief example of what I am talking about:
>
> echo -n 0 > /proc/sys/net/ipv4/tcp_ecn
>
> Fix it?
>
> If so, please tell the sites your are trying to connect to to upgrade their
> $I#$@#%@(%)@%$ firewall and/or loadbalencer (usually Localdirector or PIX).
>
>

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

Re: bizarre TCP behavior

[Gregory Maxwell]

On Tue, Apr 10, 2001 at 06:24:46PM -0400, Dave wrote:
> I am having a very strange problem in linux 2.4 kernels.  I have not set
> any iptables rules at all, and there is no firewall blocking any of my
> outgoing traffic.  At what seems like random selection, I can not connect
> to IP's yet I can get ping replies from them.  Most IP's reply just fine,
> but certain ones fail to send even an ACK.  This problem disappears when I
> boot into 2.2.  Here is a brief example of what I am talking about:

echo -n 0 > /proc/sys/net/ipv4/tcp_ecn

Fix it?

If so, please tell the sites your are trying to connect to to upgrade their
$I#$@#%@(%)@%$ firewall and/or loadbalencer (usually Localdirector or PIX).

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

Re: [Lse-tech] Re: [PATCH for 2.5] preemptible kernel

[Paul McKenney]

> > As you've observed, with the approach of waiting for all pre-empted
tasks
> > to synchronize, the possibility of a task staying pre-empted for a long
> > time could affect the latency of an update/synchonize (though its hard
for
> > me to judge how likely that is).
>
> It's very unlikely on a system that doesn't already have problems with
> CPU starvation because of runaway real-time tasks or interrupt handlers.

Agreed!

> First, preemption is a comparitively rare event with a mostly
> timesharing load, typically from 1% to 10% of all context switches.

Again, agreed!

> Second, the scheduler should not penalize the preempted task for being
> preempted, so that it should usually get to continue running as soon as
> the preempting task is descheduled, which is at most one timeslice for
> timesharing tasks.

The algorithms we have been looking at need to have absolute guarantees
that earlier activity has completed.  The most straightforward way to
guarantee this is to have the critical-section activity run with preemption
disabled.  Most of these code segments either take out locks or run
with interrupts disabled anyway, so there is little or no degradation of
latency in this case.  In fact, in many cases, latency would actually be
improved due to removal of explicit locking primitives.

I believe that one of the issues that pushes in this direction is the
discovery that "synchronize_kernel()" could not be a nop in a UP kernel
unless the read-side critical sections disable preemption (either in
the natural course of events, or artificially if need be).  Andi or
Rusty can correct me if I missed something in the previous exchange...

The read-side code segments are almost always quite short, and, again,
they would almost always otherwise need to be protected by a lock of
some sort, which would disable preemption in any event.

Thoughts?

  Thanx, Paul

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

vfat read problem with 2.4.x

[Filip Van Raemdonck]

Hi,

I encountered a problem with 2.4 kernels today.

Decompressing a 60+ Mb file with bzip2, residing on a vfat partition, gave
errors reporting that the archive was corrupt.
When I rebooted into windows and ran scandisk it couldn't find any problem
with the partition. That made me suspicious...
I rebooted into an leftover 2.2.18, ran "bunzip -t" on the file, and all was
fine. Rebooted back into 2.4.3, bunzip gave errors. Tried 2.4.2 (had an image
of that left around as well), errors too.

I copied the file (in 2.2.18) to my ext2 partition, tested it with bzip2 in
the 2.4 kernels and all was fine - so it is most likely a vfat related
problem.
Also, the file was written to the vfat partition in 2.4.2, so writing may not
even be affected by this possible bug.

Regards,

Filip

-- 
Sometimes it pays to stay in bed on Monday, rather than spending the rest of
the week debugging Monday's code.
-- Dan Salomon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dell 4300 + megaraid

[Matt Domsch]

> Our Dell 4300, plus raid card, works okay with a 2.2.14
> kernel, which has a version 107 megaraid.o module.  This
> is many versions behind the version present in 2.4.3.  More
> recent driver modules for the card hand on booting, thus this
> problem report.

Chances are you have downrev firmware on your PERC 2/SC card, and there
should be some messages printed on the console when the megaraid driver
tries to load, telling you to update your firmware, and hangs the system
at that point (else data corruption could ensue).

In any case, please see http://domsch.com/linux for an easy link to recent
firmware, and you should be set.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux


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

Re: kswapd, kupdated, and bdflush at 99% under intense IO

[Rik van Riel]

On Tue, 10 Apr 2001, Alan Cox wrote:

> > Any time I start injecting lots of mail into the qmail queue, *one* of the
> > two processors gets pegged at 99%, and it takes forever for anything typed
> > at the console to actually appear (just as you describe).  But I don't see
> 
> Yes I've seen this case. Its partially still a mystery

I've seen it too.  It could be some interaction between kswapd
and bdflush ... but I'm not sure what the exact cause would be.

regards,

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

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

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

bizarre TCP behavior

[Dave]

I am having a very strange problem in linux 2.4 kernels.  I have not set
any iptables rules at all, and there is no firewall blocking any of my
outgoing traffic.  At what seems like random selection, I can not connect
to IP's yet I can get ping replies from them.  Most IP's reply just fine,
but certain ones fail to send even an ACK.  This problem disappears when I
boot into 2.2.  Here is a brief example of what I am talking about:

meatloop:~>ping 204.202.131.229
PING 204.202.131.229 (204.202.131.229): 56 data bytes
64 bytes from 204.202.131.229: icmp_seq=0 ttl=42 time=114.7 ms
64 bytes from 204.202.131.229: icmp_seq=1 ttl=42 time=117.0 ms

 [iptraf output]

ICMP echo request (84 bytes) from 209.192.217.120 to 204.202.131.229 on eth0
ICMP echo reply (84 bytes) from 204.202.131.229 to 209.192.217.120 on eth0
ICMP echo request (84 bytes) from 209.192.217.120 to 204.202.131.229 on eth0
ICMP echo reply (84 bytes) from 204.202.131.229 to 209.192.217.120 on eth0


meatloop:~>telnet 204.202.131.229 80
Trying 204.202.131.229...
telnet: Unable to connect to remote host: Connection timed out

 [iptraf output]

209.192.217.120:32926  =   6 360   S---eth0
204.202.131.229:80 =   0   0   eth0


and yet when I boot 2.2, I have not seen any problems of this nature.  Is
this a known issue?  Possibly a setting in /proc/sys/net/ipv4 that I dont
know about?  Thanks for your help...

dave

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

Dell 4300 + megaraid

[David L. Nicol]

Our Dell 4300, plus raid card, works okay with a 2.2.14 
kernel, which has a version 107 megaraid.o module.  This
is many versions behind the version present in 2.4.3.  More
recent driver modules for the card hand on booting, thus this
problem report.

The module source does not indicate a recent contact person for
discussing the module, all of the updates since 1998 are unsigned.

Advise?

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

Re: No 100 HZ timer !

[george anzinger]

mark salisbury wrote:
> 
> george anzinger wrote:
> 
> > f) As noted, the account timers (task user/system times) would be much
> > more accurate with the tick less approach.  The cost is added code in
> > both the system call and the schedule path.
> >
> > Tentative conclusions:
> >
> > Currently we feel that the tick less approach is not acceptable due to
> > (f).  We felt that this added code would NOT be welcome AND would, in a
> > reasonably active system, have much higher overhead than any savings in
> > not having a tick.  Also (d) implies a list organization that will, at
> > the very least, be harder to understand.  (We have some thoughts here,
> > but abandoned the effort because of (f).)  We are, of course, open to
> > discussion on this issue and all others related to the project
> > objectives.
> 
> f does not imply tick-less is not acceptable, it implies that better process time
> accounting is not acceptable.

My thinking is that a timer implementation that forced (f) would have
problems gaining acceptance (even with me :).  I think a tick less
system does force this and this is why we have, at least for the moment,
abandoned it.  In no way does this preclude (f) as it is compatible with
either ticks or tick less time keeping.  On the other hand, the stated
project objectives do not include (f) unless, of course we do a tick
less time system.
> 
> list organization is not complex, it is a sorted absolute time list.  I would
> argue that this is a hell of a lot easier to understand that ticks + offsets.

The complexity comes in when you want to maintain indexes into the list
for quick insertion of new timers.  To get the current insert
performance, for example, you would need pointers to (at least) each of
the next 256 centasecond boundaries in the list.  But the list ages, so
these pointers need to be continually updated.  The thought I had was to
update needed pointers (and only those needed) each time an insert was
done and a needed pointer was found to be missing or stale.  Still it
adds complexity that the static structure used now doesn't have.
> 
> still, better process time accounting should be a compile CONFIG option, not
> ignored and ruled out because some one thinks that is is to expensive in the
> general case.

As I said above, we are not ruling it out, but rather, we are not
requiring it by going tick less.
> 
> the whole point of linux and CONFIG options is to get you the kernel with the
> features you want, not what someone else wants.
> 
> there should be a whole range of config options associated with this issue:
> 
> CONFIG_JIFFIES   == old jiffies implementation
> CONFIG_TICKLESS  == tickless
> CONFIG_HYBRID  == old jiffies plus a tickless high-res timer system on
> the side but not assoc w/ process and global
> timekeeping
> 
> CONFIG_USELESS_PROCESS_TIME_ACCOUNTING = old style, cheap time acctg
> CONFIG_USEFUL_BUT_COSTS_TIME_ACCOUNTING = accurate but expensive time accounting
> 
> this way, users who want tickless and lousy time acctg can have it AND people who
> want jiffies and good time acctg could have it.

As I said, it is not clear how you could get
CONFIG_USELESS_PROCESS_TIME_ACCOUNTING unless you did a tick every
jiffie.  What did you have in mind?
> 
> these features are largely disjoint and easily seperable.  it is also relatively
> trivial to do this in such a way that drivers depending on the jiffie abstraction
> can be supported without modification no matter what the configuration.
> 
For the most part, I agree.  I am not sure that it makes a lot of sense
to mix some of these options, however.  I think it comes down to the
question of benefit vs cost.  If keeping an old version around that is
not any faster or more efficient in any way would seem too costly to
me.  We would like to provide a system that is better in every way and
thus eliminate the need to keep the old one around.  We could leave it
in as a compile option so folks would have a fall back, I suppose.

An Issue no one has raised is that the tick less system would need to
start a timer each time it scheduled a task.  This would lead to either
slow but very precise time slicing or about what we have today with more
schedule overhead.

George


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

Re: BH_Req question

[Rajagopal Ananthanarayanan]

Andrea Arcangeli wrote:
> 
[ ... ]
> 
> BH_Req is never unset until the buffer is destroyed (put back on the freelist).
> BH_Req only says if such a buffer ever did any I/O yet or not. It is basically
> only used to deal with I/O errors in sync_buffers().

Interesting. Thanks for the explanation. Since submit_bh was setting BH_Req,
I was misled into thinking that end_io would unset it ...


> 
> > PS: In case why the question: I've got a system with tons of
> > pages with buffers marked BH_Req, so try_to_free_buffers() bails
> > out thinking that the buffer is busy ...
> 
> Either your debugging is wrong or you broke try_to_free_buffers because a
> buffer with BH_Req must still be perfectly freeable.


Okay, I got distracted by BH_Req, which I mistook to be in BUFFER_BUSY_BITS.
There was also BH_Lock set on the buffers, which would qualify for BUFFER_BUSY_BITS ...
so may be it is a buffer_locking problem somewhere.

cheers,

ananth.

--
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Cannot unmount ramfs after chmod

[Pavel Roskin]

Hello!

This happens on RedHat Linux 7.0, i686 with Linux-2.4.3-ac3.
Chmod on the top-level inode of ramfs make it impossible to unmount the
filesystem.

Chmod on other files has no effect.

[root@fonzie /root]# umount t1
[root@fonzie /root]# mount -t ramfs none t1
[root@fonzie /root]# touch t1/foo
[root@fonzie /root]# umount t1
[root@fonzie /root]# mount -t ramfs none t1
[root@fonzie /root]# touch t1/foo
[root@fonzie /root]# chmod 600 t1/foo
[root@fonzie /root]# umount t1
[root@fonzie /root]# mount -t ramfs none t1
[root@fonzie /root]# chmod 600 t1
[root@fonzie /root]# umount t1
umount: /root/t1: device is busy

-- 
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: kswapd, kupdated, and bdflush at 99% under intense IO

[Alan Cox]

> Any time I start injecting lots of mail into the qmail queue, *one* of the
> two processors gets pegged at 99%, and it takes forever for anything typed
> at the console to actually appear (just as you describe).  But I don't see

Yes I've seen this case. Its partially still a mystery

> Upon powercycling, the qmail partition is loaded with thousands of errors -
> which could be caused by the power cycling, or by something kernel related.

Under heavy I/O loads the cerberus test suite has been showing real disk
corruption on all current trees until Ingo's patch today to fix the ext2
and minix problems combined with the earlier fixes for other races

In your case I suspect its the qmail thousands of files being created/deleted
not the corruption but its hard to be sure

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386 rw_semaphores fix

[Alan Cox]

> I guess 386 could live with an exception handler that emulates it.

386 could use a simpler setup and is non SMP

> (BTW an generic exception handler for CMPXCHG would also be very useful
> for glibc -- currently it has special checking code for 386 in its mutexes) 
> The 386 are so slow that nobody would probably notice a bit more slowness
> by a few exceptions.

Be serious. You can compile glibc without 386 support. Most vendors already
distribute 386/586 or 386/686 glibc sets.

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

Re: x86 cpu configuration (was: Re: [PATCH] i386 rw_semaphores fix)

[Alan Cox]

> The current way of doing things on x86 -- essentially selecting a
> minimal level of CPU support -- is nice for vendors like Mandrake who

That isnt how the current x86 one works. It just sort of looks like that
for a common subset.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386 rw_semaphores fix

[Alan Cox]

> That's no problem if we make this SMP-specific - I doubt anybody actually
> uses SMP on i486's even if the machines exist, as I think they all had

They do. There are two (total world wide) 486 SMP users I know about and they
mostly do it to be awkward ;)

> special glue logic that Linux would have trouble with anyway. But the

The Compaqs were custom, the non Compaq ones included several using Intel
MP 1.1.

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: BH_Req question

[Andrea Arcangeli]

On Tue, Apr 10, 2001 at 01:12:02PM -0700, Rajagopal Ananthanarayanan wrote:
> 
> Hi,
> 
> It seems BH_Req is set on a buffer_head by submit_bh.
> What part of the code unsets this flag during normal
> operations? One path seems to be block_flushpage->unmap_buffer
> ->clear_bit(BH_Req), but IIRC block_flushpage is used only
> for truncates. There must be another path to unset BH_Req
> under normal memory pressure, or (more unambiguously) on IO completion.
> 
> So: in what ways can BH_Req be unset?

BH_Req is never unset until the buffer is destroyed (put back on the freelist).
BH_Req only says if such a buffer ever did any I/O yet or not. It is basically
only used to deal with I/O errors in sync_buffers().

> PS: In case why the question: I've got a system with tons of
> pages with buffers marked BH_Req, so try_to_free_buffers() bails
> out thinking that the buffer is busy ...

Either your debugging is wrong or you broke try_to_free_buffers because a
buffer with BH_Req must still be perfectly freeable.

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: aic7xxx and newer kernels

[lists]

On Tue, Apr 10, 2001 at 08:00:19AM -0600, Justin T. Gibbs wrote:
> >
> I'm pretty sure you need to be up to at leaset 0005 of 
> the firmware to stabilize this drive.
  
  FYI, I contacted seagate and they say the firmware is the latest.
  
  Regards,


  Gene/
  
  

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

Re: Still IRQ routing problems with VIA

[Jeff Garzik]

"Manuel A. McLure" wrote:
> I'd do that if this wasn't also my Windows 98 gaming machine - I'm supposing
> that the Windows drivers do use the IRQ even if XFree86/Linux doesn't. I
> dunno if Windows is smart enough to assign an IRQ even if the BIOS doesn't.
> Anyway, things are working now (specially since the last tulip patches) and
> I like it that way :-)

Well, as the old saying goes, "if it ain't broke, don't fix it."

Theoretically, with PNP OS enabled, the driver will assign VGA an IRQ if
it needs one, under both Windows and Linux.

Jeff


-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Still IRQ routing problems with VIA

[Manuel A. McLure]

> > I do have an IRQ for my VGA since the instructions for my 
> card (a Voodoo 5
> > 5500) specifically say an IRQ is needed.
> 
> I wonder though... In my mind this is a driver not hardware issue.  If
> the XFree86 and/or Linux console driver do not use the IRQ, 
> you need not
> have BIOS assign one.  If you are feeling dangerous, try 
> turning the VGA
> IRQ assignment off in BIOS and see if things melt/explode/kick ass.

I'd do that if this wasn't also my Windows 98 gaming machine - I'm supposing
that the Windows drivers do use the IRQ even if XFree86/Linux doesn't. I
dunno if Windows is smart enough to assign an IRQ even if the BIOS doesn't.
Anyway, things are working now (specially since the last tulip patches) and
I like it that way :-)

--
Manuel A. McLure - Unify Corp. Technical Support <[EMAIL PROTECTED]>
Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What
about-?" M: "It's fixed." SG: "Eh, good. 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/

Patch for arch/ppc/8xx_io/fec.c

[Jean-Denis Boyer]

Hello.

I've attached to this mail a patch for the FEC driver
on the Motorola MPC8xx embedded CPU.

This patch includes both a bug fix, and a new PHYter implementation.

 Symptom
-
I was experiencing problems of "transmission timeout" when heavily
loading the network (throughput tests), particularly when the board
was wired to a 10MBits link (but I could also reproduce it on 100Mbits
using the packet sockets). The user process was then "held" by the IP
stack, I had no choice but to kill it.

 Bug description
-
When, in rare cases, the ring buffer became full, the driver was stopping
the network queue, which is OK. But, it did not set a flag to restart
the queue in the transmission interrupt service routine.

 Bug fix
-
I only had to set this flag, at the same time the network queue was stopped
(already wrapped in a spin lock).


Supplement:
 PHYter implementation
---
My board uses the NS chip model DP83843BVJE, for which I filled out the
needed structures.
However, I could not test the PHYter interrupt since it is not wired to the
PPC on our board
(but it is enabled in this patch). I had to code a polling routine (not
included in this patch).

It might be a good idea to move all these implementations outside of
"fec.c".
It might be also useful to choose the supported models through the kernel
configuration.
Perhaps I will work on that during the next weeks...

By the way, who is maintaining that part (MPC8xx, MPC82xx) of the kernel?


 Other issue 
-
I have another problem I will have to address. I'm experiencing a strange
behaviour
in the response time when I 'ping flood' my board.

Through the 10Mbits, everything works fine, the average response time is
468us,
with realist minimum and maximum values.

  > round-trip min/avg/max/mdev = 0.458/0.468/0.600/0.029 ms

But, through the 100Mbits, the response time ranges from 0.26ms to 10ms,
and an average of about 5ms, always different from test to test.

  > round-trip min/avg/max/mdev = 0.265/6.764/10.311/4.512 ms

Strangely, the board is not running anything but bash.
If a start 'top' with a refresh period of 1 second, I get a lower average,
but still the same min and max.

  > round-trip min/avg/max/mdev = 0.264/0.583/10.018/1.421 ms

If I start an NFS copy of a big file, the maximum gets down to 2ms.


The maximum of 10ms sounds like the timer tick.
Since it is working well in 10Mbps and not in 100Mbps,
can I suspect a problem with the Ethernet driver?


Thank you for your time.


 Jean-Denis Boyer, B.Eng., Technical Leader
 Mediatrix Telecom Inc.
 4229 Garlock Street
 Sherbrooke (Québec)
 J1L 2C8  CANADA



 ppc.8xx_io.fec.c.patch.gz

Re: Bug report: tcp staled when send-q != 0, timers == 0.

[Eugene B. Berdnikov]

  Hello.

On Tue, Apr 10, 2001 at 09:38:43PM +0400, [EMAIL PROTECTED] wrote:
> If my guess is right, you can easily put this socket to funny state
> just catting a large file and kill -STOP'ing ssh. ssh will close window,
> but sshd will not send zero probes.

 [1] I have checked your statement on 2 different machines, running 2.2.17.
 No confirmation. But this is much more funny than it simply sounds. :)

 The thing is that one machine (which run ssh client in my bug report)
 do send ACKs when ssh is SIGSTOP'ed. The other one does not send ACKs,
 but much more curious is that it does not send ACKs even when input
 buffer is filled, and client IS NOT stopped! :))) Hence connection dies
 due to retransmission timeout on the server side.

 I did not believe my own eyes and tried this test several times, with
 ssh1 and openssh, copying ssh configs, but results were always the same.

 Both hosts are running 2.2.17 on K6 processors, compiled via egcs-1.1.2,
 with minor differences in the kernel configuration. If you really check
 your statements before writing, you surely have a 2.2.17 which behave some
 another way, which I can't reproduce. Isn't funny? :)))

 I can send configs (and even binary kernels with modules) for verification.
 If this is not a complete fault, we have a very-very sad situation, when
 tcp core behaviour depends on the secondary configuration options.
 I have no other ideas how it can be explained.

 [2] Your second statement is that sshd with keepalive enabled does not send
 zero probes when input window is closed. Be sure, in my case it sends:

 01:04:05.025715 194.190.166.31.22 > 194.190.161.106.1006: . ack 1 win 32120 
 (DF) [tos 0x10]
 01:04:05.025816 194.190.161.106.1006 > 194.190.166.31.22: . ack 17376 win 0 
 (DF) [tos 0x10]
 01:06:05.953026 194.190.166.31.22 > 194.190.161.106.1006: . ack 1 win 32120 
 (DF) [tos 0x10]
 01:06:05.953122 194.190.161.106.1006 > 194.190.166.31.22: . ack 17376 win 0 
 (DF) [tos 0x10]

 BTW, I strongly rule out a possibility to stop my ssh client when I
 encounter the reported bug.

> Any socket with keepalives enabled
> enters this state after the first keepalive is sent.

 I do not understand how connection with closed window can wait until
 first keepalive - it must do zero probes instead.

> [ Note, that it is not Butenko's problem, it is still to be discovered. 8) ]
> 
> I think you will not able to reproduce full problem: socket will revive
> after the first received ACK. It is another bug and its probability is
> astronomically low.

 Hmm... I observed this bug on the host, which never performs more
 than 10 conn/sec and has peak loadvg ~ 0.15.
-- 
 Eugene Berdnikov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Still IRQ routing problems with VIA

[Jeff Garzik]

"Manuel A. McLure" wrote:
> Jeff Garzik said...
> > Changing '#undef DEBUG' to '#define DEBUG 1' in
> > arch/i386/kernel/pci-i386.h is also very helpful.  Can you guys do so,
> > and post the 'dmesg -s 16384' results to lkml?  This includes the same
> > information as dump_pirq, as well as some additional information.
> 
> Here's my dmesg output - I tried with both PNP: Yes and PNP: No and the
> dmesg outputs were exactly the same modulo a Hz or two in the processor
> speed detection.

Thanks.  I'm building a database of these.  There is definitely an issue
with Via and interrupt routing.  Hopefully I can collate this data soon
and figure out what's going on.  I need to find some Via hardware for
myself, too, since I only have an old Via-based laptop which works 100%
;-)


> I do have an IRQ for my VGA since the instructions for my card (a Voodoo 5
> 5500) specifically say an IRQ is needed.

I wonder though... In my mind this is a driver not hardware issue.  If
the XFree86 and/or Linux console driver do not use the IRQ, you need not
have BIOS assign one.  If you are feeling dangerous, try turning the VGA
IRQ assignment off in BIOS and see if things melt/explode/kick ass.

Regards,

Jeff


-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Still IRQ routing problems with VIA

[Manuel A. McLure]

Jeff Garzik said...
> Changing '#undef DEBUG' to '#define DEBUG 1' in
> arch/i386/kernel/pci-i386.h is also very helpful.  Can you guys do so,
> and post the 'dmesg -s 16384' results to lkml?  This includes the same
> information as dump_pirq, as well as some additional information.

Here's my dmesg output - I tried with both PNP: Yes and PNP: No and the
dmesg outputs were exactly the same modulo a Hz or two in the processor
speed detection.

I do have an IRQ for my VGA since the instructions for my card (a Voodoo 5
5500) specifically say an IRQ is needed.

--
Manuel A. McLure - Unify Corp. Technical Support <[EMAIL PROTECTED]>
Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What
about-?" M: "It's fixed." SG: "Eh, good. Good."


 dmesg_pnp_yes.txt.gz

Re: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available

[James Antill]

"Stephen D. Williams" <[EMAIL PROTECTED]> writes:

> James Antill wrote:
> > 
> >  I seemed to miss the original post, so I can't really comment on the
> > tests. However...
> 
> It was a thread in January, but just ran accross it looking for
> something else.  See below for results.

 Ahh, ok.

> > > Michael Lindner wrote:
> ...
> > > > <0.21>
> > > >  0.000173 select(8, [3 4 6 7], NULL, NULL, NULL) = 1 (in [6])
> > > > <0.47>
> > 
> >  The strace here shows select() with an infinite timeout, you're
> > numbers will be much better if you do (pseudo code)...

[snip ... ]

> > ...basically you completely miss the function call for __pollwait()
> > inside poll_wait (include/linux/poll.h in the linux sources, with
> > __pollwait being in fs/select.c).
> 
> Apparently the extra system call overhead outweighs any benefit.

 There shouldn't be any "extra" system calls in the fast path. If data
is waiting then you do one call to poll() either way, if not then you
are wasting time blocking so it doesn't matter what you do.

>   In any
> case, what you suggest would be better done in the kernel anyway.

 Possibly, however when this has come up before the kernel people have
said it's hard to do in kernel space.

>The
> time went from 3.7 to 4.4 seconds per 10.

 Ok here's a quick test that I've done. This passes data between 2
processes. Obviously you can't compare this to your code or Michael's,
however...

 The results with USE_DOUBLE_POLL on are...

% time ./pingpong
./pingpong  0.15s user 0.89s system 48% cpu 2.147 total
% time ./pingpong
./pingpong  0.19s user 0.91s system 45% cpu 2.422 total
% time ./pingpong
./pingpong  0.10s user 1.02s system 49% cpu 2.282 total

 The results with USE_DOUBLE_POLL off are...

% time ./pingpong
./pingpong  0.24s user 1.07s system 50% cpu 2.614 total
% time ./pingpong
./pingpong  0.21s user 1.00s system 44% cpu 2.695 total
% time ./pingpong
./pingpong  0.21s user 1.13s system 50% cpu 2.667 total

 Don't forget that the poll here is done with _1_ fd. Most real
programs have more, and so benifit more.

 I also did the TRY_NO_POLL, as I was pretty sure what the results
would be, that gives...

% time ./pingpong
./pingpong  0.03s user 0.41s system 50% cpu 0.874 total
% time ./pingpong
./pingpong  0.06s user 0.44s system 58% cpu 0.855 total
% time ./pingpong
./pingpong  0.07s user 0.35s system 51% cpu 0.820 total


 pingpong.c



-- 
# James Antill -- [EMAIL PROTECTED]
:0:
* ^From: .*james@and\.org
/dev/null

RE: kswapd, kupdated, and bdflush at 99% under intense IO

[Phil Oester]

I've seen similar 'unresponsiveness' running 2.4.3-ac2 on a Qmail server.
The hardware is dual-processor PIII 650 w/1GB of RAM.  SCSI is sym53c895
with dual Quantum 9gb drives.

Any time I start injecting lots of mail into the qmail queue, *one* of the
two processors gets pegged at 99%, and it takes forever for anything typed
at the console to actually appear (just as you describe).  But I don't see
any particular user process in top using a great deal of cpu - just the
system itself.  In my case, however, I usually have to powercycle the box to
get it back - it totally dies.

I've started the kernel with profile=2, and had a cron job running every
minute to capture a readprofile -r; sleep 10; readprofile, but when the
processor pegs, the cron jobs just stop without catching any useful
information before the freeze.  The interesting thing is, the box still
responds to pings at this time, even though it goes hours without any
profile captures.

Upon powercycling, the qmail partition is loaded with thousands of errors -
which could be caused by the power cycling, or by something kernel related.

In the meantime, I've had to revert to 2.2.19 any time I do intense
mailings.

-Phil Oester

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Lessem
Sent: Tuesday, April 10, 2001 1:01 PM
To: [EMAIL PROTECTED]
Subject: kswapd, kupdated, and bdflush at 99% under intense IO


My machine is an 8 processor Dell P-III 700Mhz with 8GB of memory.
The disk system I am using is a 12 drawer JBOD with 5 disks in a raid
5 arrangement attached to an AMI Megaraid 438/466/467/471/493
controller with a total of 145GB of space.  The machine has been in
use for about 6 months doing primarily cpu and memory intensive
scientific computing tasks.  It has been very stable in this role and
everybody involved has been pleased with its performance.  Recently a
decision was made to conglomerate people's home directories from
around the network and put them all on this machine (hence the JBOD
and RAID).

These tests are all being done with Linux 2.4.3 + the bigpatch fix for
knfsd and quotas.  The rest of the OS is Debian unstable.

Before moving the storage into production I am performing tests on it
to gauge its stability.  The first test I performed was a single
bonnie++ -s 16096 instance, and the timing results are inline with
what I would expect from fast SCSI disks.

However, multiple instance of bonnie++ completely kill the machine.
Once two or three bonnies are running kswapd, kupdated, and bdflush
each jump to using 99% of a cpu and the machine becomes incredibly
unresponsive.  Even using a root shell at nice -20 it can take several
minutes for "killall bonnie++" to appear after being typed and then
run.  After the bonnies are killed and kswapd, kupdated, and bdflush
are given a minute or two to finish whatever they are doing, the
machine becomes responsive again.

I don't think the machine should be behaving like this.  I certainly
expect some slowdowns with that much IO, but the computer should still
be resonably responsive, particularly because no system or user files
that need to be accessed are on that channel of the SCSI controller.

Any advice on approaching this problem would be appreciated.  I will
try my best to provide any debugging information that would be useful,
but the machine is on another continent from myself, so without a
serial console I have a hard time getting any information that doesn't
make it into a logfile.

--
Thanks,
Jeff Lessem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/

2.4.2 bug in handling vfat?

[Ulrich Lauther]

when I unmount and remount a vfat file system, the time stamp of a recently
created file changes by one hour.
This does not happen on the same system when running 2.2.17.

Script started on Mon Apr  9 13:59:26 2001
sh-2.03# uname -a
Linux tahiti 2.4.2 #7 Mon Mar 26 23:50:57 CEST 2001 i686 unknown
sh-2.03# touch /dos/fudge
sh-2.03# ls -l /dos/fudge
-rwxrwxrwx   1 root root0 Apr  9 13:59 /dos/fudge
sh-2.03# umount /dos
sh-2.03# mount /dos
sh-2.03# ls -l /dos/fudge
-rwxrwxrwx   1 root root0 Apr  9 14:59 /dos/fudge
 ^^
The relevant fstab entry is:
/dev/hda1  /dosvfat noauto,umask=0,defaults  10

the clock was set after booting using clock -s -u

Is the descibed behaviour a known problem?
-- 
-lauther


Ulrich Lauther  ph: +49 89 636 48834 fx: ... 636 42284
Siemens CT SE 6 Internet: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i386 rw_semaphores fix

[Linus Torvalds]

On Tue, 10 Apr 2001, Andi Kleen wrote:
>
> I guess 386 could live with an exception handler that emulates it.

That approach is fine, although I'd personally prefer to take the
exception just once and just rewrite the instuction as a "call". The
places that need xadd would have to follow some strict guidelines (long
modrms or other instructions to pad out to enough size, and have the
arguments in fixed registers)

> (BTW an generic exception handler for CMPXCHG would also be very useful
> for glibc -- currently it has special checking code for 386 in its mutexes)
> The 386 are so slow that nobody would probably notice a bit more slowness
> by a few exceptions.

Ehh. I find that the slower the machine is, the more easily I _notice_
that it is slow. So..

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/

BH_Req question

[Rajagopal Ananthanarayanan]

Hi,

It seems BH_Req is set on a buffer_head by submit_bh.
What part of the code unsets this flag during normal
operations? One path seems to be block_flushpage->unmap_buffer
->clear_bit(BH_Req), but IIRC block_flushpage is used only
for truncates. There must be another path to unset BH_Req
under normal memory pressure, or (more unambiguously) on IO completion.

So: in what ways can BH_Req be unset?

Thanks for any input, i've been staring at the code for long without avail ...

cheers,

ananth.

PS: In case why the question: I've got a system with tons of
pages with buffers marked BH_Req, so try_to_free_buffers() bails
out thinking that the buffer is busy ...

-- 
--
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.3

[Andre Manuel Rocha Lourenco]

 Hi!
I downloaded the patch to kernel 2.4.3 but it just doesn't compile on my
system! I have been using kernel 2.4 since 2.4.0-test8 without problems...
Here are the last lines of the compilation output: (in Portuguese)


make[2]: Saindo do diretório `/usr/src/linux/arch/i386/lib'
make[1]: Saindo do diretório `/usr/src/linux/arch/i386/lib'
ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o
init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o
fs/fs.o ipc/ipc.o \
drivers/block/block.o drivers/char/char.o drivers/misc/misc.o
drivers/net/net.o drivers/media/media.o  drivers/char/agp/agp.o
drivers/char/drm/drm.o drivers/net/fc/fc.o drivers/ide/idedriver.o
drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o
drivers/mtd/mtdlink.o drivers/pnp/pnp.o drivers/video/video.o
drivers/usb/usbdrv.o drivers/input/inputdrv.o drivers/i2o/i2o.o
drivers/i2c/i2c.o drivers/md/mddev.o \
net/network.o \
/usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a
/usr/src/linux/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
net/network.o(.data+0x2d84): undefined reference to
`sysctl_ipx_pprop_broadcasting'
make: ** [vmlinux] Erro 1
[root@localhost linux]#



It you reply to this message please reply also to [EMAIL PROTECTED] ,
'cause I am not receiving the kernel mailing list. Thanks,

Andre Lourenco

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386 rw_semaphores fix

[Andi Kleen]

On Tue, Apr 10, 2001 at 12:42:07PM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 10 Apr 2001, David Howells wrote:
> >
> > Here's a patch that fixes RW semaphores on the i386 architecture. It is very
> > simple in the way it works.
> 
> XADD only works on Pentium+.

My Intel manual says it 486+:

``
XADD-Exchange and Add
[...]
Intel Architecture Compatibility
Intel Architecture processors earlier than the Intel486TM processor do not recognize 
this instruc-
tion. If this instruction is used, you should provide an equivalent code sequence that 
runs on
earlier processors.
''

I guess 386 could live with an exception handler that emulates it.

(BTW an generic exception handler for CMPXCHG would also be very useful
for glibc -- currently it has special checking code for 386 in its mutexes) 
The 386 are so slow that nobody would probably notice a bit more slowness
by a few exceptions.

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

Re: memory usage

[gis88530]

Thanks.
cat /proc/slabinfo look like as follows.
Each row have three columns.
Could you tell me what do they mean in second and third column?
kmem_cache29 42
pio_request0  0

My second question is:
We can find memory usage of daemon(apache) by ps or top.
e.g. apache use 5400k physical memory 

Does the memory usage of /proc/slabinfo include some of 
5400k ? I guess 5400k can separate into two part
(kernel space part and user space part). 

Is any thing wrong? Thanks
Cheers,
Tom

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

Re: lockd trouble

[Jussi Hamalainen]

On Tue, 10 Apr 2001, Jussi Hamalainen wrote:

>program vers proto   port
> 102   tcp111  portmapper
> 102   udp111  portmapper
> 1000211   udp   1024  nlockmgr
> 1000213   udp   1024  nlockmgr
> 151   udp686  mountd
> 152   udp686  mountd
> 151   tcp689  mountd
> 152   tcp689  mountd
> 132   udp   2049  nfs
> 132   tcp   2049  nfs

Duhh. Obviously I should have read the documentation before bashing
my head against the wall. I wasn't running statd. Got it working now,
sorry about that.

I do have a question about lockd. How do I get it back if I need
to restart portmap? Running rpc.lockd doesn't seem to have any
effect whatsoever on the listed rpc services and I can't just
reload the module since nfs depends on it.

-- 
-=[ Count Zero / TBH - Jussi Hämäläinen - 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: [linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 Beta 7 available at www.sistina.com

[Martin K. Petersen]

> "Heinz" == Heinz J Mauelshagen <[EMAIL PROTECTED]> writes:

Heinz> a tarball of the Linux Logical Volume Manager 0.9.1 Beta 7 is
Heinz> available now at

The following code is bd, m'kay...

[...]

down(&_pe_lock);
if((pe_lock_req.lock == LOCK_PE) &&
   (rdev_map == pe_lock_req.data.pv_dev) &&
   (rsector_map >= pe_lock_req.data.pv_offset) &&
   (rsector_map < (pe_lock_req.data.pv_offset + vg_this->pe_size)) &&
   ((rw == WRITE) || (rw == WRITEA))) {
/* defer this bh until the PE has moved */
if(((int) bh) & 0x3) {
printk(KERN_ERR 
   "%s -- bh uses low 2 bits of pointer\n",
   lvm_name);
up(&_pe_lock);
goto bad;
}

bh->b_reqnext = _pe_requests;
_pe_requests = (struct buffer_head *) ((int) bh | rw);
up(&_pe_lock);
up(&lv->lv_snapshot_sem);
return 0;
}
up(&_pe_lock);

[...]

/* handle all deferred io for this PE */
while(q) {
struct buffer_head *d_bh = 
   (struct buffer_head *) (q & ~0x3);
int rw = q & 0x3;
q = (uint) d_bh->b_reqnext;
 
/* resubmit this buffer head */
d_bh->b_reqnext = 0;
generic_make_request(rw, d_bh);
}


Not only is this an evil hack from hell, I don't understand why you go
through such a huge effort of storing rw in the pointer.  Afaict, the
only valid value is WRITE.  And WRITEA is #defined to WRITE in lvm.c.

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

kswapd, kupdated, and bdflush at 99% under intense IO

[Jeff Lessem]

My machine is an 8 processor Dell P-III 700Mhz with 8GB of memory.
The disk system I am using is a 12 drawer JBOD with 5 disks in a raid
5 arrangement attached to an AMI Megaraid 438/466/467/471/493
controller with a total of 145GB of space.  The machine has been in
use for about 6 months doing primarily cpu and memory intensive
scientific computing tasks.  It has been very stable in this role and
everybody involved has been pleased with its performance.  Recently a
decision was made to conglomerate people's home directories from
around the network and put them all on this machine (hence the JBOD
and RAID).

These tests are all being done with Linux 2.4.3 + the bigpatch fix for
knfsd and quotas.  The rest of the OS is Debian unstable.

Before moving the storage into production I am performing tests on it
to gauge its stability.  The first test I performed was a single
bonnie++ -s 16096 instance, and the timing results are inline with
what I would expect from fast SCSI disks.

However, multiple instance of bonnie++ completely kill the machine.
Once two or three bonnies are running kswapd, kupdated, and bdflush
each jump to using 99% of a cpu and the machine becomes incredibly
unresponsive.  Even using a root shell at nice -20 it can take several
minutes for "killall bonnie++" to appear after being typed and then
run.  After the bonnies are killed and kswapd, kupdated, and bdflush
are given a minute or two to finish whatever they are doing, the
machine becomes responsive again.

I don't think the machine should be behaving like this.  I certainly
expect some slowdowns with that much IO, but the computer should still
be resonably responsive, particularly because no system or user files
that need to be accessed are on that channel of the SCSI controller.

Any advice on approaching this problem would be appreciated.  I will
try my best to provide any debugging information that would be useful,
but the machine is on another continent from myself, so without a
serial console I have a hard time getting any information that doesn't
make it into a logfile.

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

Re: No 100 HZ timer !

[Andi Kleen]

On Tue, Apr 10, 2001 at 02:45:15PM -0400, Stephen D. Williams wrote:
> When this is rewritten, I would strongly suggest that we find a way to
> make 'gettimeofday' nearly free.  Certain applications need to use this
> frequently while still being portable.  One solution when you do have
> clock ticks is a read-only mapped Int.  Another cheap solution is
> library assembly that adds a cycle clock delta since last system call to
> a 'gettimeofday' value set on every system call return.

The upcoming x86-64 port supports vsyscalls for just that purpose.



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

Re: No 100 HZ timer !

[mark salisbury]

george anzinger wrote:

> f) As noted, the account timers (task user/system times) would be much
> more accurate with the tick less approach.  The cost is added code in
> both the system call and the schedule path.
>
> Tentative conclusions:
>
> Currently we feel that the tick less approach is not acceptable due to
> (f).  We felt that this added code would NOT be welcome AND would, in a
> reasonably active system, have much higher overhead than any savings in
> not having a tick.  Also (d) implies a list organization that will, at
> the very least, be harder to understand.  (We have some thoughts here,
> but abandoned the effort because of (f).)  We are, of course, open to
> discussion on this issue and all others related to the project
> objectives.

f does not imply tick-less is not acceptable, it implies that better process time
accounting is not acceptable.

list organization is not complex, it is a sorted absolute time list.  I would
argue that this is a hell of a lot easier to understand that ticks + offsets.

still, better process time accounting should be a compile CONFIG option, not
ignored and ruled out because some one thinks that is is to expensive in the
general case.

the whole point of linux and CONFIG options is to get you the kernel with the
features you want, not what someone else wants.

there should be a whole range of config options associated with this issue:

CONFIG_JIFFIES   == old jiffies implementation
CONFIG_TICKLESS  == tickless
CONFIG_HYBRID  == old jiffies plus a tickless high-res timer system on
the side but not assoc w/ process and global
timekeeping

CONFIG_USELESS_PROCESS_TIME_ACCOUNTING = old style, cheap time acctg
CONFIG_USEFUL_BUT_COSTS_TIME_ACCOUNTING = accurate but expensive time accounting

this way, users who want tickless and lousy time acctg can have it AND people who
want jiffies and good time acctg could have it.

these features are largely disjoint and easily seperable.  it is also relatively
trivial to do this in such a way that drivers depending on the jiffie abstraction
can be supported without modification no matter what the configuration.

Mark Salisbury

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

x86 cpu configuration (was: Re: [PATCH] i386 rw_semaphores fix)

[Jeff Garzik]

Linus Torvalds wrote:
> That's no problem if we make this SMP-specific - I doubt anybody actually
> uses SMP on i486's even if the machines exist, as I think they all had
> special glue logic that Linux would have trouble with anyway. But the
> advantages of being able to use one generic kernel that works on plain UP
> i386 machines as well as SMP P6+ machines is big enough that I would want
> to be able to say "CONFIG_X86_GENERIC" + "CONFIG_SMP".

(slight tangent)
FWIW I think the i386 CPU selection logic in make config should be
reconsidered in 2.5+...

The alpha presents you with a list of platforms, and allows you to
select a specific one, or a generic option that includes all platforms. 
The current way of doing things on x86 -- essentially selecting a
minimal level of CPU support -- is nice for vendors like Mandrake who
drops support for older CPUs.  But it isn't nice for the case where a
user wants support for their specific processor and no other.  I have a
P-II, why include code that only works on K7 or P-III?  The embedded
people, I think, would find such a change useful too.

The only problem with an alpha-like configuration is that Mandrake
cannot select a minimum CPU level of support anymore... I guess that
could be solved by an "advanced" sub-menu, similar to that which is
found in drivers/video/Config.in, which allows fine-grained Y/N
selections of CPU support.

-- 
Jeff Garzik   | Sam: "Mind if I drive?"
Building 1024 | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft  |   and shrieking like a cheerleader."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: No 100 HZ timer !

[Zdenek Kabelac]

Jamie Lokier wrote:
> 
> Alan Cox wrote:
 > 
> Except for cards which don't generate an irq on vsync but do let you see
> how the raster is proceeding.  (I vaguely recall these).  For which a
> PLL and, wait for it high resolution timer is needed.
> 
> Perhaps that's a 1990s problem that doesn't need a 2000s solution though :-)

I think it would be wrong if we could not add new very usable features
to the system just because some old hardware doesn't support it.
(I also believe this was the original idea why XFree has no user
interface
for such important thing like VBI screen switch - because not all device
could provide such information)
I think those who use such old system probably don't need any
synchronized
video or game output - simply because it will not work in such system
anyway :)
so we should not worry about this.

[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: Kernel 2.4.3 Crash - (Kernel BUG at highmem.c:155)

[Jeff Lessem]

I also have seen the Kernel BUG at highmem.c:155 problem on a machine
I am testing.  It is a Dell 8 processor P-III 700Mhz with 8GB of
memory and Linux 2.4.3 + a knfsd and quota patch for reiserfs.  When
doing 5 simultaneous kernel compiles from another machine mounting the
8 processor one over nfs the 8 processor machine hung with an error
message somewhat like

nfsd: terminating on signal 2
kernel BUG at highmem.c: 155!
invalid operand: 
CPU: 6

I apologize for the nearly useless error information, but I am 5000
miles and 7 time zones away from this machine, so I have to depend on
others for getting me on console information until I can get it moved
over to a serial console.

>Occassional lockups lasting 5-20 seconds were experienced when working on the 
>box under 2.4.2 but seem to be much better in 2.4.3.

The machine is also having these odd lockup problems under intense
disk IO, but I will detail that in another message (look for "kswapd,
kupdated, and bdflush at 99%").

Any advice to alleviate this problem would be appreciated, and I will
provide any more information I can upon request.

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

Re: No 100 HZ timer !

[Stephen D. Williams]

When this is rewritten, I would strongly suggest that we find a way to
make 'gettimeofday' nearly free.  Certain applications need to use this
frequently while still being portable.  One solution when you do have
clock ticks is a read-only mapped Int.  Another cheap solution is
library assembly that adds a cycle clock delta since last system call to
a 'gettimeofday' value set on every system call return.

sdw

Andi Kleen wrote:
> 
> On Tue, Apr 10, 2001 at 01:12:14PM +0100, Alan Cox wrote:
> > Measure the number of clocks executing a timer interrupt. rdtsc is fast. Now
> > consider the fact that out of this you get KHz or better scheduling
> > resolution required for games and midi. I'd say it looks good. I agree
> 
> And measure the number of cycles a gigahertz CPU can do between a 1ms timer.
> And then check how often the typical application executes something like
> gettimeofday.
> 
...

sdw
-- 
[EMAIL PROTECTED]  http://sdw.st
Stephen D. Williams
43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax 
Dec2000
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386 rw_semaphores fix

[Linus Torvalds]

On Tue, 10 Apr 2001, David Howells wrote:
>
> Here's a patch that fixes RW semaphores on the i386 architecture. It is very
> simple in the way it works.

XADD only works on Pentium+.

That's no problem if we make this SMP-specific - I doubt anybody actually
uses SMP on i486's even if the machines exist, as I think they all had
special glue logic that Linux would have trouble with anyway. But the
advantages of being able to use one generic kernel that works on plain UP
i386 machines as well as SMP P6+ machines is big enough that I would want
to be able to say "CONFIG_X86_GENERIC" + "CONFIG_SMP".

Even if it would be noticeably slower (ie a fallback to a spinlock might
be perfectly ok).

If you do this, I woul dsuggest having asm-i386/{rwsem.h|rwsem-xadd.h},
and just having a

#ifndef CONFIG_XADD
#include 
#else
#include 
#endif

(And adding "CONFIG_XADD" to the list of generated optimization
configuration options in arch/i386/config.in, of course).

That way we don't make the semaphore.h file even more unreadable.


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: No 100 HZ timer !

[Zdenek Kabelac]

Alan Cox wrote:
> 
> > Games would like to be able to page flip at vertical refresh time --
> > <1ms accuracy please.  Network traffic shaping benefits from better than
> 
> This is an X issue. I was talking with Jim Gettys about what is needed to
> get the relevant existing X extensions for this working

I've already proposed my /dev/vbi device (currently works only for MGA
card)
- read returns when VBI occures - works quite well...
(currently in avifile CVS tree)

Anyway in good all days AmigaOS had interrupt service where devices
where sending timer request - they were queued and timer device was
serving
them in order - I don't see the reason why we should implement this
differently.
If there is no real reason to interrupt system more then 100Hz
periodicity
then this is ok - scheduler will simple send time request for
rescheduling in 10ms.

Why we should create 1KHz timers or so when this way seems to be much
more
elegant and will work even on XXGHz systems.


bye

[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: No 100 HZ timer !

[george anzinger]

Just for your information we have a project going that is trying to come
up with a good solution for all of this:

http://sourceforge.net/projects/high-res-timers

We have a mailing list there where we have discussed much of the same
stuff.  The mailing list archives are available at sourceforge.

Lets separate this into findings and tentative conclusions :)

Findings:

a) The University of Kansas and others have done a lot of work here.

b) High resolution timer events can be had with or without changing HZ.

c) High resolution timer events can be had with or without eliminating
the 1/HZ tick.

d) The organization of the timer list should reflect the existence of
the 1/HZ tick or not.  The current structure is not optimal for a "tick
less" implementation.  Better would be strict expire order with indexes
to "interesting times".

e) The current organization of the timer list generates a hiccup every
2.56 seconds to handle "cascading".  Hiccups are bad.

f) As noted, the account timers (task user/system times) would be much
more accurate with the tick less approach.  The cost is added code in
both the system call and the schedule path.  

Tentative conclusions:

Currently we feel that the tick less approach is not acceptable due to
(f).  We felt that this added code would NOT be welcome AND would, in a
reasonably active system, have much higher overhead than any savings in
not having a tick.  Also (d) implies a list organization that will, at
the very least, be harder to understand.  (We have some thoughts here,
but abandoned the effort because of (f).)  We are, of course, open to
discussion on this issue and all others related to the project
objectives.

We would reorganize the current timer list structure to eliminate the
cascade (e) and to add higher resolution entries.  The higher resolution
entries would carry an addition word which would be the fraction of a
jiffie that needs to be added to the jiffie value for the timer.  This
fraction would be in units defined by the platform to best suit the sub
jiffie interrupt generation code.  Each of the timer lists would then be
ordered by time based on this sub jiffie value.  In addition, in order
to eliminate the cascade, each timer list would carry all timers for
times that expire on the (jiffie mod (size of list)).  Thus, with the
current 256 first order lists, all timers with the same (jiffies & 255)
would be in the same list, again in expire order.  We also think that
the list size should be configurable to some power of two.  Again we
welcome discussion of these issues.

George

Alan Cox wrote:

>> It's also all interrupts, not only syscalls, and also context switch if you
>> want to be accurate.

>We dont need to be that accurate. Our sample rate is currently so low the
>data is worthless anyway
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: select() on TCP socket sleeps for 1 tick even if data available

[Stephen D. Williams]

James Antill wrote:
> 
> "Stephen D. Williams" <[EMAIL PROTECTED]> writes:
> 
> > An old thread, but important to get these fundamental performance
> > numbers up there:
> >
> > 2.4.2 on an 800mhz PIII Sceptre laptop w/ 512MB ram:
> >
> > elapsed time for 10 pingpongs is
> > 3.81327
> > 10/3.81256
> > ~26229.09541095746689888159
> > 1/.379912
> > ~26321.88506812103855629724
...
>  I seemed to miss the original post, so I can't really comment on the
> tests. However...

It was a thread in January, but just ran accross it looking for
something else.  See below for results.


> > Michael Lindner wrote:
...
> > >  0.052371 send(7, "\0\0\0
> > > \177\0\0\1\3243\0\0\0\2\4\236\216\341\0\0\v\277"..., 32, 0) = 32
> > > <0.000529>
> > >  0.000882 rt_sigprocmask(SIG_BLOCK, ~[], [RT_0], 8) = 0 <0.21>
> > >  0.000242 rt_sigprocmask(SIG_SETMASK, [RT_0], NULL, 8) = 0
> > > <0.21>
> > >  0.000173 select(8, [3 4 6 7], NULL, NULL, NULL) = 1 (in [6])
> > > <0.47>
> > >  0.000328 read(6, "\0\0\0 ", 4) = 4 <0.31>
> > >  0.000179 read(6,
> > > "\177\0\0\1\3242\0\0\0\2\4\236\216\341\0\0\7\327\177\0\0"..., 28) = 28
> > > <0.75>
> 
>  The strace here shows select() with an infinite timeout, you're
> numbers will be much better if you do (pseudo code)...
> 
>   struct timeval zerotime;
> 
>   zerotime.tv_sec = 0;
>   zerotime.tv_usec = 0;
> 
>  if (!(ret = select( ... , &zerotime)))
>   ret = select( ... , NULL);
> 
> ...basically you completely miss the function call for __pollwait()
> inside poll_wait (include/linux/poll.h in the linux sources, with
> __pollwait being in fs/select.c).

Apparently the extra system call overhead outweighs any benefit.  In any
case, what you suggest would be better done in the kernel anyway.  The
time went from 3.7 to 4.4 seconds per 10.

> 
> --
> # James Antill -- [EMAIL PROTECTED]
> :0:
> * ^From: .*james@and\.org
> /dev/null

-- 
[EMAIL PROTECTED]  http://sdw.st
Stephen D. Williams
43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax 
Dec2000
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: (ide.2.2.19.04092001.patch:) DiskPerf compile problem

[Gunther Mayer]

Andre Hedrick wrote:
> 
...
> DiskPerf /dev/hde
> Device: IBM-DTLA-307075 Serial Number: YSDYSFA5874
> LBA 0 DMA Read Test  = 63.35 MB/Sec (3.95 Seconds)
> Outer Diameter Sequential DMA Read Test  = 35.89 MB/Sec (6.97 Seconds)
> Inner Diameter Sequential DMA Read Test  = 17.64 MB/Sec (14.17 Seconds)

Where can I get the latest DiskPerf?

The version on:
http://www.xx.kernel.org/pub/linux/kernel/people/hedrick/utility-patches/DiskPerf-1.0.1.tar.gz
does not compile at all:

linux:~/DiskPerf-1.0 # make
gcc -o DiskPerf -O3 -lglib DiskPerf.c
DiskPerf.c: In function `ataRead':
DiskPerf.c:155: storage size of `reqtask' isn't known
DiskPerf.c:156: storage size of `taskfile' isn't known
DiskPerf.c:157: `ide_reg_valid_t' undeclared (first use in this function)
...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 Directory Index - File Structure

[Andreas Dilger]

Daniel writes:
> > Are you going to go to a COMPAT flag before final release?  This is
> > pretty much needed for e2fsck to be able to detect/correct indexes.
> 
> I will if I know what the exact semantics are.  I have only an
> approximate idea of how this works and I'd appreciate a more precise
> definition.

OK, on ext2 the {,RO_,IN_}COMPAT flags work as follows for the kernel:

COMPAT:Means that the on-disk format is 100% compatible with older on-disk
   formats, so a kernel which didn't know anything about this feature
   could read/write the filesystem without corrupting the filesystem.
   This is essentially just a flag which says "this filesystem has a
   (hidden) feature" for e2fsck (more on e2fsck later).  The ext3
   HAS_JOURNAL is a COMPAT feature, because the journal is simply a
   regular file with data blocks in it, nothing special.  DIR_PREALLOC
   is a COMPAT feature, since all it does is pre-allocate empty
   directory blocks for directories growing over 1 block.
RO_COMPAT: Means the on-disk format is 100% compatible with older on-disk
   formats for reading (i.e. the feature does not change the visible
   on-disk format).  However, an old kernel writing to such a
   filesystem would/could corrupt the filesystem, so this is
   prevented(*).  SPARSE_SUPER is such a feature, because sparse
   groups allow data blocks where superblock/GDT backups used to
   live, and the old ext2_free_blocks() would refuse to free these
   blocks, leading to inconsistent bitmaps.  Old ext2_free_blocks()
   would also get an error if a series of blocks crossed a group
   boundary.
INCOMPAT:  Means the on-disk format has changed in some way that makes it
   unreadable by older kernels.  FILETYPE is this because older
   kernels would think the directory name_len was > 256, so that
   would be bad.  COMPRESSION is obvious - you would just get
   garbage back from read().  The ext3 RECOVER flag is needed to
   prevent ext2 from mounting the filesystem without replaying the
   journal.  In most cases, an unrecovered ext3 filesystem is in
   no worse a state than an unchecked ext2 filesystem (so at one
   time I wanted an RO_COMPAT_RECOVER flag to at least allow you
   to mount an ext3 filesystem as ext2 for e3fsck), but a lot
   more inconsistencies can accumulate in the journal than was
   previously possible so that was shot down.

Now for e2fsck, slightly different semantics are needed.  Basically, if
a filesystem has ANY unsupported feature (COMPAT, RO_COMPAT, INCOMPAT),
it will refuse to run on the filesystem, because it doesn't know how to
deal with the feature.  For example, ext3 COMPAT_HAS_JOURNAL is not supported
by older e2fsck, because it is possible for ext3 to use a reserved inode
(number 8) to hold the journal, so this would fail.  It also didn't know
what was a valid or invalid ext3 journal, so allowing an old e2fsck to pass
on an ext3 filesystem would be a false sense of security.

Because (with the change to dx_root_info), an indexed filesystem is 100%
safe to write into even for kernels that know nothing about the directory
indexes, it could be a COMPAT flag in the superblock.  This would force
users to have an updated e2fsck to verify that the directory indexes
are valid.  Otherwise, the indexes could (somehow) become corrupt and an
old e2fsck would not detect this because it would just think the index
blocks were empty directory blocks.

(*) kernels before 2.4.0 didn't check RO_COMPAT on remount, so root could
be mounted RO with an RO_COMPAT feature, and then be remounted RW.  I
submitted a patch for this which made it into 2.4.0, but it is still
not in 2.2.19.  We also didn't check *COMPAT flags for rev 0 ext2
filesystems (i.e. those created by default with mke2fs 1.15 or earlier,
and still may be around), so COMPAT flags were totally ignored in this
case.  My patch also fixed that for 2.4.0.  Alan has said he will put
it into 2.2.20-pre1.

> > For that matter, I'm not even sure if ext2 supports directory files larger
> > than 2GB?  Anyone?  I'm not 100% sure, but it may be that e2fsck considers
> > directories >2GB as invalid.

Actually, as I think about this more, it is currently invalid for
directories to become > 2GB.  The i_size_high field in the inode is
actually the i_dir_acl pointer, so this is only "available" for regular
files and not directories.  Given that the ext2 EA/ACL code does not use
this field, we may allow this in the future, but for now we are limited
to 2GB directories.  Should be enough for now.

> > Have you been testing this with different kinds of input for filenames,
> > or only synthetic input data?
> 
> Because I'm not relying on any particular properties of coherence of
> names, i.e., my hash function is a

Re: Still IRQ routing problems with VIA

[Axel Thimm]

On Tue, Apr 10, 2001 at 01:38:32PM -0400, Jeff Garzik wrote:
> Axel Thimm wrote:
> > 0.7.[2,3] are the usb devices. BIOS (and 2.2 kernels) had them at IRQ 5.
> > 2.4 somehow picks the irq of the ethernet adapter, iqr 11, instead.
> > At least usb is then unusable.
> > As you say that you have the same board, what is the output of dump_pirq -
> > are your link values in the set of {1,2,3,5} or are they continuous 1-4? 
> > Maybe you are lucky - or better say, I am having bad luck :(
> Changing '#undef DEBUG' to '#define DEBUG 1' in arch/i386/kernel/pci-i386.h
> is also very helpful.  Can you guys do so, and post the 'dmesg -s 16384'
> results to lkml?  This includes the same information as dump_pirq, as well
> as some additional information.

OK, gzip-attached to this mail.

> Note that turning "Plug-n-Play OS" off in BIOS setup typically fixes many
> interrupt routing problems -- but Linux 2.4 should now have support for PNP
> OS:Yes.  Clearly there appear to be problems with that support on some Via
> hardware.

I had the problems with both settings (but I have tried so many patches and
kernels, that I cannot be sure about the combinations).

> Note that you should have "Plug-n-Play OS: Yes" when generated the
> requested 'dmesg' output.
O.K.

On Tue, Apr 10, 2001 at 01:01:07PM -0500, Jeff Garzik wrote:
> On Tue, 10 Apr 2001, Manuel A. McLure wrote:
> > This may be the difference - I always set "Plug-n-Play OS: No" on all my
> > machines. Linux works fine and it doesn't seem to hurt Windows 98 any.
> 
> Correct, it's perfectly fine to do that on all machines (not just Via).
> Users should also set "PNP OS: No" for Linux 2.2...
> 
> Other BIOS settings to verify:
> Assign IRQ to VGA: no (optional, but you probably don't need a VGA IRQ)
left to yes then, to keep the same BIOS settings/errors.
> Operating System: other (or Unix, depending on the BIOS)
n/a
> Memory hole: no
O.K.

> Unless you are using ISA cards, make sure all your PCI plug-n-play
> IRQ settings are set to "PCI/PnP" not "ISA/ICU".
O.K.

> hmmm, maybe I should write a Linux kernel BIOS guide/FAQ...

Yes, please!

And here are my FAQs with what I think are the answers (which means they are
possibly wrong, but then you get the idea, what some ppl might misunderstand):

Q) What does Plug-and-Play BIOS setting do?
A) It allows the OS to reassign IRQ/ports to devices (?)

Q) When should I turn it on or off?
A) If your BIOS is doing the right thing for you it's safe to turn it
   off. If you trust your OS more, turn it on. (?)

Q) Which OSes should I trust? What about multiboot systems?
A) Linux > 2.4.x, M$ xxx, etc. (?)

Q) What bad thing might happen, if a non P&P OS has in the BIOS a P&P setting
   or vice versa?
A) ... (?)

Thanks, Axel.
-- 
[EMAIL PROTECTED]

 dmesg.2.4.3-puredebug.log.gz

Re: ppp + kernel 2.4.3

[William Park]

On Tue, Apr 10, 2001 at 12:57:43PM -0500, Ryan Hairyes wrote:
> Could some one tell me what modules need to be selected to 
> make ppp successfully dialup and stay connected with 2.4.3?
> Or give me somewhere to look for this answer. 

ppp_async.  You can load it by 'modprobe ppp_async'.

--William Park, Open Geometry Consulting, Linux/Python/LaTeX/vim, 8 CPUs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

out-of-band message causing read on socket to be corrupted.

[Audrey Wong]

This is my problem:

My server program is continually sending the client a whole lot of
messages. 

The client sends the server an MSG_OOB(out-of-band) message, goes to
sleeps in a loop and waits for the server to reply.  

The server's reply to this message will raise the signal SIGURG, which
wakes up the client. 

The client then proceeds to read the reply and continues to process the 
rest of the messages. But the messages that it reads after that are all
corrupted. 

Does anyone know why this is?  This only happens on linux (2.2.16, 2.2.17,
2.4.1) but not irix or suns.


thanks
audrey

ps: i've enclosed my simple test case below.
---
/* client.c */


#include "tcpDefs.h"

static void
sigUrgHandler(int sig)
{
fprintf(stderr, " \n!!!sigUrgHandler\n");
signal(SIGURG, sigUrgHandler);
}

static int
getOOBReply( int sd ) {

int rv;
char msg;

fprintf(stderr, " -> getOOBReply! ");
for (;;) {

rv = recv( sd, &msg, sizeof( msg ), MSG_OOB );
fprintf(stderr, ".");
if (rv == sizeof(msg)) {
fprintf(stderr, " rv= %d \n", rv);
return msg;
}
sleep(1);
}
}

void sendOOBMsg(int sd) {

fprintf(stderr, " -> SendOOBMsg \n");
if (!SendMsg( sd, CP_EH_DELETEQ ))
return;
getOOBReply(sd);
}

void getNextMsg(int sd) {

int cnt=0;
int br, rr, flag;
CpMsg msg;
fd_set fdset;
struct timeval timeout;

fprintf(stderr, " -- GetNextMsg! -- \n");
for (;;) {

FD_ZERO(&fdset);
FD_SET(sd, &fdset);
timeout.tv_sec = 0;
timeout.tv_usec = 0;

/* see if there are any events to read. */
flag = select(sd+1, &fdset, 0, 0, &timeout);
if (flag <= 0)
continue; /* no events to read, sorry. */

if (ReadMsg(sd, &msg)) {
fprintf(stderr, " Msg= (%s %c)\n", PrintMsgId(msg.id), msg.data);

if (msg.id == CP_EH_LUXO_DONE) {
fprintf(stderr, " quitting!\n");
return;
}

if (msg.id == CP_EH_HELLO) {
SendMsg(sd, CP_EH_HELLO);
continue;
}
cnt++;
if ( cnt >= 5) 
sendOOBMsg(sd);
}
}

}

int main (int argc, char *argv[]) {

struct sockaddr_in localAddr, servAddr;
struct utsname host;
struct hostent *hp;

int one = 1;
int p_proto;

int sd, rc, i, pid;

hp = gethostbyname(argv[1]);
if(hp==NULL) {
printf("%s: unknown host'\n");
return -1;
} else 
fprintf(stderr, " Host= %s\n", argv[1]);

/* create socket */
sd = socket(AF_INET, SOCK_STREAM, 0);
if(sd<0) {
perror("cannot open socket ");
return -1;
} else
fprintf(stderr, " creating socket! sd=%d\n", sd);

/* bind any port number */
memset((caddr_t) &localAddr, 0, sizeof(localAddr));
localAddr.sin_family = AF_INET;
localAddr.sin_addr.s_addr = htonl(INADDR_ANY);
localAddr.sin_port = htons(0);
  
rc = bind(sd, (struct sockaddr *) &localAddr, sizeof(localAddr));
if(rc<0) {
fprintf(stderr, "%s: cannot bind port TCP \n");
exit(1);
}

servAddr.sin_port = htons(CP_EH_PORT);
servAddr.sin_family = hp->h_addrtype;
memcpy((char *) &servAddr.sin_addr.s_addr, hp->h_addr_list[0], hp->h_length);

/* connect to server */
rc = connect(sd, (struct sockaddr *) &servAddr, sizeof(servAddr));
if(rc<0) {
fprintf(stderr, "cannot connect ");
return -1;
}

p_proto = getprotobyname("tcp")->p_proto;
if ( setsockopt( sd, p_proto, TCP_NODELAY, (char *)&one, sizeof(one) )
 < 0 ) {
fprintf(stderr, "cannot setsockopt\n");
return -1;
}

pid = getpid();
if ( fcntl(sd, F_SETOWN, pid) < 0)
fprintf(stderr, " fcntl didnt succeed\n");

signal( SIGURG, sigUrgHandler);

usleep(900);
getNextMsg(sd);

return 0;
  
}

---
/* server.c */


#include "tcpDefs.h"

int client_fd = -1;

int ProcessMsg( int fd, CpMsg *msg) {
int i;
char rv = 1;
switch (msg->id) {
case CP_EH_LUXO_DONE:
fprintf(stderr, " quitting!\n");
return -1;
case CP_EH_HELLO: {
fprintf(stderr, "Sending 10 messg!\n");
for (i=0; i<20; i++) {
  SendMsg(fd, CP_EH_SEND_EVENT);
}
break; }
case CP_EH_DELETEQ:
fprintf(stderr, " sending client OOB message!\n");
send(fd, &rv, sizeof(rv), MSG_OOB);
break;
}
return 1;
}

static void Quit() {
fprintf(stderr, " .. quiting .. \n");
SendMsg(client_fd, CP_EH_LUXO_DONE);
exit(1);
}


int main (int argc, char *argv[]) {

CpMsg msg;
int i, sd, newSd, cliLen, flag;
int hiFd;
fd_set fdset, readfdset;
struct timeval timeout;
struct sockaddr_in cliAddr, servAddr;

   

lockd trouble

[Jussi Hamalainen]

I have two PCs running Slackware 7.1. I can't get lockd to work
properly with NFS:

Apr 10 21:03:59 sputnik kernel: nsm_mon_unmon: rpc failed, status=-93
Apr 10 21:03:59 sputnik kernel: lockd: cannot monitor xxx.xxx.xxx.xxx
Apr 10 21:03:59 sputnik kernel: lockd: failed to monitor xxx.xxx.xxx.xxx

Yet rpcinfo -p gives the following:

magellan:~$ rpcinfo -p mir
   program vers proto   port
102   tcp111  portmapper
102   udp111  portmapper
1000211   udp   1024  nlockmgr
1000213   udp   1024  nlockmgr
151   udp686  mountd
152   udp686  mountd
151   tcp689  mountd
152   tcp689  mountd
132   udp   2049  nfs
132   tcp   2049  nfs
magellan:~$ rpcinfo -p sputnik
   program vers proto   port
102   tcp111  portmapper
102   udp111  portmapper
1000211   udp   1024  nlockmgr
1000213   udp   1024  nlockmgr
151   udp721  mountd
152   udp721  mountd
151   tcp724  mountd
152   tcp724  mountd
132   udp   2049  nfs
132   tcp   2049  nfs

The NFS share in question is mounted as locking. Every time procmail
tries to get a kernel lock for a file in my home directory, I get an
error as described above. Both boxes are running exactly the same
2.2.19 kernel. Am I doing something wrong or is this a bug?

-- 
-=[ Count Zero / TBH - Jussi Hämäläinen - 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/

Need clues on possible brokenness.

[Chad Schwartz]

Hiya, list.

Think i've found a rather nasty bug in the kernel, and I need some clues
as to where to look for the issue.

Stats:

Quad Xeon (PIII core) 700mhz machine (1mb cache on each)
4gb RAM
5x36gb SCSI disks - on a DAC1100 RAID controller
3 EEPro 100 cards

The box functions as a database server that runs at about 40% load on
each CPU, and about 1.5gb memory usage.

Kernel: 2.2.18pre11-va2.0smp (Although completely reproducible on stock
2.2.18)

If dmesg output from kernel - or any other info is required, i'd be more
than happy to provide it.


Problem:

Box appears to stop responding to network requests for 30 seconds at a
time.  it appears to be happening when we get this error:

wait_on_bh, CPU 0:
irq:  0 [0 0]
bh:   1 [0 0]
<[c010bb29]> <[c011d07b]> <[c011d1ed]> <[c0116658]> <[c01099fc]>

it LOOKS like the virtaddr's provided are a call trace, however, I can't
be sure - as SOME of the addresses don't show up as a ksym..

the problem LOOKS to be, from my perspective (And light code reading) -
that the function synchronize_bh() is called SOMEWHERE, and then,
wait_on_bh() is called from that.  It also appears that wait_on_bh() loops
through MAXCOUNT times (1 times), and fails - therefore exiting
the function.  (it also appears that the 1 global interrupt that is OPEN
is a TIMER interrupt.)

Can SOMEONE give me a clue as to where to start looking for this problem -
and/or perhaps some input from people who work on this code? (The really
confusing thing about this, is that the wait_for_bh() function should NOT
take 30 seconds to jump through the maximum loop count.)

Thanks in advance,

Chad


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

Re: No 100 HZ timer !

[Jamie Lokier]

Alan Cox wrote:
> > > This is an X issue. I was talking with Jim Gettys about what is needed to
> > > get the relevant existing X extensions for this working
> > 
> > Last time I looked at XF86DGA (years ago), it seemed to have the right
> > hooks in place.  Just a matter of server implementation.  My
> > recollection is dusty though.
> 
> There is also a timing extension for synchronizing events to happenings. The
> stopper is the kernel interface for the vblank handling since the irq must
> be handled and cleared in kernel context before we return to X. We now think
> we know how to handle that cleanly

Except for cards which don't generate an irq on vsync but do let you see
how the raster is proceeding.  (I vaguely recall these).  For which a
PLL and, wait for it high resolution timer is needed.

Perhaps that's a 1990s problem that doesn't need a 2000s solution though :-)

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

Re: aic7xxx and 2.4.3 failures - fix, it is interrupt routing

[Gérard Roudier]

On Mon, 9 Apr 2001, Jim Studt wrote:

> G*rard Roudier insightfully opined..
> > Looks like an IRQ problem to me.
> > I mean the kernel wants to change IRQ routing and just do the wrong job.
> 
> Give the man a prize!  
> 
> After failing to work with 2.4.0, 2.4.1, 2.4.3, and 2.4.3-ac3 I
> enabled X86_UP_IOAPIC to stir up the interrupt code and it works.
> 
> I'll keep one of these servers set aside for testing and see if I can't
> figure out a little more specifically what the problem is, but IOAPIC
> is fine.  

Probably because the code that messes with IRQs isn't involved when IOAPIC
is used. If I had to guess I would point "arch/i386/kernel/pci-irq.c",
function "pcibios_lookup_irq()".

  Gérard.

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

Re: No 100 HZ timer !

[Alan Cox]

> > This is an X issue. I was talking with Jim Gettys about what is needed to
> > get the relevant existing X extensions for this working
> 
> Last time I looked at XF86DGA (years ago), it seemed to have the right
> hooks in place.  Just a matter of server implementation.  My
> recollection is dusty though.

There is also a timing extension for synchronizing events to happenings. The
stopper is the kernel interface for the vblank handling since the irq must
be handled and cleared in kernel context before we return to X. We now think
we know how to handle that cleanly

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/

PROBLEM: kernel bug in page_alloc 191 !

[Xevi]

The information is in the file ...

If you want make some question, I hope respond as soon as I can do it.

Xevi Serrats
[EMAIL PROTECTED]



REPORTING-BUGS

[1.] One line summary of the problrm:

When I boot linux (usinb lilo) appears an error message : kernel bug at page_alloc 191

[2.] Full description of the problem:

Two times, when I boot my linux - 2.4.3 appears this message after start deamon httpd.
I use linuix mandrake 7.2 and I upgrade with kernel 2.4.3 few weeks ago. I load linux 
in lilo,
it begin "entering" in the sistem and two times, after start httpd success a bug.
I'm sorry because I can't descrive it more, but I have some information ...

starting httpd: [ OK ]

Kernel BUG al page_alloc.c 191 !
invalid operand 
CPU:0
EIP: 0010:[]
EFLAGS: 00010082

eax: 0020 ebx: c03ed324  ecx: 002e   edx: 0001
esi: c02a71a0 ed:    edp: 0001   esp: c1e97e84

ds: 018  es: 018  ss: 018

Process S85httpd (pid: 821, stackpage= c1e97000)

stack: c024ca05  c024cb13  00bf  c02a7178  c02a7350    0001  
   0286    c02a7178  c012a3d3  c1079a90  080f51ec  c19c20c0  0001
   0005  0001  c02a734c  c011f8c2  c19c20c0  080f51es    0001

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

Code: 0f 0b 83 c4 0c 90 8b 53 04 8b 03 89 50 04 8d 4f 01 89 02 89

[3.] Keywords (i.e., modules, networking, kernel);

I don't what you are asking here, excuse me ...

[4.] kernel version

I use kernel 2.4.3

[5.] Output of Oops.. message (if applicable) with symbolic information
resolved ...

I think this information is in the point 2, I copies it manually, I hope it
hasn't errors, I was very carefully.

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

I think it is not possible because the bug succes when i tried entering linux ...

[7.] Environment

I don't undestand this point, but I use linux because I am a programmer, I use
specially gcc and now I begin use apache and PHP ... perhaps the reason the bug
kernel occurs after httpd is because I used apache and PHP ... I don't know ...
I use apache but my PC isn't a server that host a web pages. My PC don't use any
local area network, and I specially use by doing C programs ...

[8.] Software (add the output of the ver_linux here).

If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux localhost.localdomain 2.4.3 #3 SMP dg. abr. 1 06:21:47 /etc/localtime 2001 i586 
unknown

Gnu C  2.95.3
Gnu make   3.79.1
binutils   2.10.0.24
util-linux 2.10p
modutils   2.4.0
e2fsprogs  1.19
PPP2.4.0
isdn4k-utils   3.1beta7
Linux C Library2.1.3
Dynamic linker (ldd)   2.1.3
Procps 2.0.7
Net-tools  1.57
Console-tools  0.2.3
Sh-utils   2.0
Modules Loaded sb sb_lib uart401 vfat fat

[7.2.] Processor information

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 5
model   : 4
model name  : Pentium MMX
stepping: 4
cpu MHz : 167.047
fdiv_bug: no
hlt_bug : no
f00f_bug: yes
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr mce cx8 mmx
bogomips: 333.41

[7.3] Module information

sb  7296   0
sb_lib 34912   0 [sb]
uart401 6384   0 [sb_lib]
vfat   10512   3 (autoclean)
fat31488   0 (autoclean) [vfat]

[7.4 ] Load driver and harware information

/proc/ioports:

-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0213-0213 : isapnp read
0220-022f : soundblaster
02f8-02ff : serial(auto)
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0a79-0a79 : isapnp write
0cf8-0cff : PCI conf1
4000-403f : Intel Corporation 82371AB PIIX4 ACPI
5000-501f : Intel Corporation 82371AB PIIX4 ACPI
6400-641f : Intel Corporation 82371AB PIIX4 USB
f000-f00f : Intel Corporation 82371AB PIIX4 IDE

/proc/iomen:

-0009fbff : System RAM
0009fc00-0009 : System RAM
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-01ff : System RAM
  0010-00240424 : Kernel code
  00240425-002bdd9f : Kernel data
e000-e3ff : S3 Inc. 86c764/765 [Trio32/64/64V+]
- : reserved


[7.5] PCS information

00:00.0 Host bridge: Intel Corporation 430TX - 82439TX MTXC (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR

RE: Still IRQ routing problems with VIA

[Jeff Garzik]

On Tue, 10 Apr 2001, Manuel A. McLure wrote:
> This may be the difference - I always set "Plug-n-Play OS: No" on all my
> machines. Linux works fine and it doesn't seem to hurt Windows 98 any.

Correct, it's perfectly fine to do that on all machines (not just Via).
Users should also set "PNP OS: No" for Linux 2.2...

Other BIOS settings to verify:
Assign IRQ to VGA: no (optional, but you probably don't need a VGA IRQ)
Operating System: other (or Unix, depending on the BIOS)
Memory hole: no

Unless you are using ISA cards, make sure all your PCI plug-n-play
IRQ settings are set to "PCI/PnP" not "ISA/ICU".

hmmm, maybe I should write a Linux kernel BIOS guide/FAQ...

Jeff



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

Re: [CHECKER] amusing copy_from_user bug

[David S. Miller]

Petru Paler writes:
 > On Tue, Apr 10, 2001 at 06:41:28AM -0400, Jakub Jelinek wrote:
 > > some architectures don't care at all, because verify_area is a noop
 > > (sparc64).
 > 
 > Why (and how) is this?

On sparc64, the user lives in an entirely different address space.
The user cannot even generate addresses in kernel space.  Basically,
addresses are prefix'd by an 8-bit tag called an ASI (Address Space
Identifier), which tells the cpu which TLB context to use etc.
When running in user space or accessing user space in kernel mode
we make the cpu use the special userspace ASI.

In fact the user can be given the complete 32-bit or 64-bit virtual
address space, the kernel takes up none of it.

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

[PATCH] i386 rw_semaphores fix

[David Howells]

Here's a patch that fixes RW semaphores on the i386 architecture. It is very
simple in the way it works.

The lock counter is dealt with as two semi-independent words: the LSW is the
number of active (granted) locks, and the MSW, if negated, is the number of
active writers (0 or 1) plus the number of waiting lockers of any type.

The fast paths are either two or three instructions long.

This algorithm should also be totally fair! Contentious lockers get put on the
back of the wait queue, and a waker function wakes them starting at the front,
but only wakes either one writer or the first consecutive bundle of readers.

The disadvantage is that the maximum number of active locks is 65535, and the
maximum number of waiting locks is 32766 (this can be extended to 65534 by not
relying on the S flag).

I've included a revised testing module (rwsem.c) that allows read locks to be
obtained as well as write locks and a revised driver program (driver.c) that
can use rwsem.c. Try the following tests:

driver -200 & driver 200 # fork 200 writers and then 200 readers
driver 200 & driver -200 # fork 200 readers and then 200 writers

David Howells


diff -uNr linux-2.4.3/arch/i386/kernel/semaphore.c linux/arch/i386/kernel/semaphore.c
--- linux-2.4.3/arch/i386/kernel/semaphore.cThu Apr  5 14:38:34 2001
+++ linux/arch/i386/kernel/semaphore.c  Tue Apr 10 18:23:55 2001
@@ -14,7 +14,6 @@
  */
 #include 
 #include 
-
 #include 
 
 /*
@@ -237,19 +236,10 @@
 __down_read_failed:
pushl   %edx
pushl   %ecx
-   jnc 2f
-
-3: calldown_read_failed_biased
-
-1: popl%ecx
+   calldown_read_failed
+   popl%ecx
popl%edx
ret
-
-2: calldown_read_failed
-   " LOCK "subl$1,(%eax)
-   jns 1b
-   jnc 2b
-   jmp 3b
 "
 );
 
@@ -260,169 +250,204 @@
 __down_write_failed:
pushl   %edx
pushl   %ecx
-   jnc 2f
-
-3: calldown_write_failed_biased
-
-1: popl%ecx
+   calldown_write_failed
+   popl%ecx
popl%edx
ret
-
-2: calldown_write_failed
-   " LOCK "subl$" RW_LOCK_BIAS_STR ",(%eax)
-   jz  1b
-   jnc 2b
-   jmp 3b
 "
 );
 
-struct rw_semaphore *FASTCALL(rwsem_wake_readers(struct rw_semaphore *sem));
-struct rw_semaphore *FASTCALL(rwsem_wake_writer(struct rw_semaphore *sem));
+asm(
+"
+.align 4
+.globl __rwsem_wake
+__rwsem_wake:
+   pushl   %edx
+   pushl   %ecx
+   callrwsem_wake
+   popl%ecx
+   popl%edx
+   ret
+"
+);
 
-struct rw_semaphore *FASTCALL(down_read_failed_biased(struct rw_semaphore *sem));
-struct rw_semaphore *FASTCALL(down_write_failed_biased(struct rw_semaphore *sem));
+struct rw_semaphore *FASTCALL(rwsem_wake(struct rw_semaphore *sem));
 struct rw_semaphore *FASTCALL(down_read_failed(struct rw_semaphore *sem));
 struct rw_semaphore *FASTCALL(down_write_failed(struct rw_semaphore *sem));
 
-struct rw_semaphore *down_read_failed_biased(struct rw_semaphore *sem)
-{
-   struct task_struct *tsk = current;
-   DECLARE_WAITQUEUE(wait, tsk);
 
-   add_wait_queue(&sem->wait, &wait);  /* put ourselves at the head of the 
list */
-
-   for (;;) {
-   if (sem->read_bias_granted && xchg(&sem->read_bias_granted, 0))
-   break;
-   set_task_state(tsk, TASK_UNINTERRUPTIBLE);
-   if (!sem->read_bias_granted)
-   schedule();
-   }
+static inline int atomic_add_and_read_orig(int delta, atomic_t *v)
+{
+   int oldmem;
 
-   remove_wait_queue(&sem->wait, &wait);
-   tsk->state = TASK_RUNNING;
+   __asm__ __volatile__(
+   LOCK_PREFIX "xadd %0,%2"
+   : "=r"(oldmem)
+   : "r0"(delta), "m"(*__xg(v))
+   : "memory");
 
-   return sem;
+   return oldmem;
 }
 
-struct rw_semaphore *down_write_failed_biased(struct rw_semaphore *sem)
+static inline int atomic_add_and_read(int delta, atomic_t *v)
 {
-   struct task_struct *tsk = current;
-   DECLARE_WAITQUEUE(wait, tsk);
-
-   add_wait_queue_exclusive(&sem->write_bias_wait, &wait); /* put ourselves at 
the end of the list */
-
-   for (;;) {
-   if (sem->write_bias_granted && xchg(&sem->write_bias_granted, 0))
-   break;
-   set_task_state(tsk, TASK_UNINTERRUPTIBLE);
-   if (!sem->write_bias_granted)
-   schedule();
-   }
-
-   remove_wait_queue(&sem->write_bias_wait, &wait);
-   tsk->state = TASK_RUNNING;
+   return atomic_add_and_read_orig(delta,v)+delta;
+}
 
-   /* if the lock is currently unbiased, awaken the sleepers
-* FIXME: this wakes up the readers early in a bit of a
-* stampede -> bad!
-*/
-   if (atomic_read(&sem->count) >= 0)
-   wake_up(&sem->wait);
+static inline int atomic_sub_and_read_orig(in

RE: Still IRQ routing problems with VIA

[Manuel A. McLure]

Axel Thimm said...
> On Tue, Apr 10, 2001 at 09:51:18AM -0700, Manuel A. McLure wrote:
> > I have the same motherboard with the same lspci output 
> (i.e. I get the "pin
> > ?" part), but I don't see any problems running 2.4.3 or 
> 2.4.3-ac[23]. I am
> > only using a trackball on my USB port - what problems are 
> you seeing?
> 
> Well, a part of the attached dmesg output yields:
> 
> > PCI: Found IRQ 11 for device 00:07.2
> > IRQ routing conflict in pirq table for device 00:07.2
> > IRQ routing conflict in pirq table for device 00:07.3
> > PCI: The same IRQ used for device 00:0e.0
> > uhci.c: USB UHCI at I/O 0x9400, IRQ 5
> 
> and later:
> 
> > uhci: host controller process error. something bad happened
> > uhci: host controller halted. very bad
> 
> 0.7.[2,3] are the usb devices. BIOS (and 2.2 kernels) had 
> them at IRQ 5. 2.4
> somehow picks the irq of the ethernet adapter, iqr 11, instead.
> 
> At least usb is then unusable.
> 
> As you say that you have the same board, what is the output 
> of dump_pirq - are
> your link values in the set of {1,2,3,5} or are they 
> continuous 1-4? Maybe you
> are lucky - or better say, I am having bad luck :(
> -- 
> [EMAIL PROTECTED]
> 

I am getting IRQ routing conflict messages:

Apr  8 21:32:47 ulthar kernel: usb.c: registered new driver usbdevfs
Apr  8 21:32:47 ulthar kernel: usb.c: registered new driver hub
Apr  8 21:32:47 ulthar kernel: usb-uhci.c: $Revision: 1.251 $ time 18:28:42
Apr
  6 2001
Apr  8 21:32:47 ulthar kernel: usb-uhci.c: High bandwidth mode enabled
Apr  8 21:32:47 ulthar kernel: PCI: Found IRQ 11 for device 00:07.2
Apr  8 21:32:47 ulthar kernel: IRQ routing conflict in pirq table for device
00
:07.2
Apr  8 21:32:47 ulthar kernel: IRQ routing conflict in pirq table for device
00
:07.3
Apr  8 21:32:47 ulthar kernel: PCI: The same IRQ used for device 00:0a.0
Apr  8 21:32:47 ulthar kernel: PCI: The same IRQ used for device 00:0e.0
Apr  8 21:32:47 ulthar kernel: usb-uhci.c: USB UHCI at I/O 0xa400, IRQ 9
Apr  8 21:32:47 ulthar kernel: usb-uhci.c: Detected 2 ports
Apr  8 21:32:47 ulthar kernel: usb.c: new USB bus registered, assigned bus
numb
er 1
Apr  8 21:32:47 ulthar kernel: hub.c: USB hub found
Apr  8 21:32:47 ulthar kernel: hub.c: 2 ports detected
Apr  8 21:32:47 ulthar kernel: PCI: Found IRQ 11 for device 00:07.3
Apr  8 21:32:47 ulthar kernel: IRQ routing conflict in pirq table for device
00
:07.2
Apr  8 21:32:47 ulthar kernel: IRQ routing conflict in pirq table for device
00
:07.3
Apr  8 21:32:47 ulthar kernel: PCI: The same IRQ used for device 00:0a.0
Apr  8 21:32:47 ulthar kernel: PCI: The same IRQ used for device 00:0e.0
Apr  8 21:32:47 ulthar kernel: usb-uhci.c: USB UHCI at I/O 0xa800, IRQ 9
Apr  8 21:32:47 ulthar kernel: usb-uhci.c: Detected 2 ports
Apr  8 21:32:47 ulthar kernel: usb.c: new USB bus registered, assigned bus
numb
er 2
Apr  8 21:32:47 ulthar kernel: hub.c: USB hub found
Apr  8 21:32:47 ulthar kernel: hub.c: 2 ports detected

However I am not seeing any problems caused by this (however I do not use
USB very much, as I mentioned - only for a trackball). I also got the same
messages on my K7T Pro which used the KT133 chipset, however, so I don't
think this is a KT133/KT133A issue.
I can't seem to find dump_pirq on my system (Red Hat 7) - I can run it if I
find it...

Jeff Garzik said:
>Changing '#undef DEBUG' to '#define DEBUG 1' in
>arch/i386/kernel/pci-i386.h is also very helpful.  Can you guys do so,
>and post the 'dmesg -s 16384' results to lkml?  This includes the same
>information as dump_pirq, as well as some additional information.

I'll do that and get back to you - I'll have to physically be at my machine
to reset the BIOS to "PNP: Yes" so it won't be until I get home from work.

>Note that turning "Plug-n-Play OS" off in BIOS setup typically fixes
>many interrupt routing problems -- but Linux 2.4 should now have support
>for PNP OS:Yes.  Clearly there appear to be problems with that support
>on some Via hardware.
>
>Note that you should have "Plug-n-Play OS: Yes" when generated the
>requested 'dmesg' output.

This may be the difference - I always set "Plug-n-Play OS: No" on all my
machines. Linux works fine and it doesn't seem to hurt Windows 98 any.

--
Manuel A. McLure - Unify Corp. Technical Support <[EMAIL PROTECTED]>
Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What
about-?" M: "It's fixed." SG: "Eh, good. 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: memory usage

[Andi Kleen]

On Wed, Apr 11, 2001 at 01:42:55AM +0800, gis88530 wrote:
> Hello,
> 
> I can use "ps" to see memory usage of daemons and user programs.
> I can't find any memory information of kernel with "top" and "ps".
> 
> Do you know how to take memory usage information of kernel ?

Try cat /proc/slabinfo


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

Re: No 100 HZ timer !

[yodaiken]

On Tue, Apr 10, 2001 at 04:43:36AM -0700, David Schleef wrote:
> However, on machines without a monotonically increasing counter,
> i.e., the TSC, you have to use 8254 timer 0 as both the timebase
> and the interval counter -- you end up slowly losing time because
> of the race condition between reading the timer and writing a
> new interval.  RTAI's solution is to disable kd_mksound and
> use timer 2 as a poor man's TSC.  If either of those is too big
> of a price, it may suffice to report that the timer granularity
> on 486's is 10 ms.

Just for the record, Michael Barabanov did this in RTLinux from before
kd_mksound was a function pointer in 1995. Michael had an optimization
attempt using channel 1 for a while, but on very slow machines this 
was not sufficient and he went back to channel 2. Of course, the 
fundamental problem is that board designers keep putting an 1920s
part in machines built in 2001. 

Here's the comment from the RTLinux 0.5 patch -- all available on the archives
on rtlinux.com.

+/* The main procedure; resets the 8254 timer to generate an interrupt.  The
+ * tricky part is to keep the global time while reprogramming it.  We latch
+ * counters 0 and 2 atomically before and after reprogramming to figure it out.
+ */


-- 
-
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.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: Bug report: tcp staled when send-q != 0, timers == 0.

[kuznet]

Hello!

>  In brief: a stale state of the tcp send queue was observed for 2.2.17
>  while send-q counter and connection window sizes are not zero: 

I think I pinned down this. The patch is appended.


>  diagnostic, I'll try to get it. In any case, I plan to run something through
>  this connection in hope to reproduce this state again.

If my guess is right, you can easily put this socket to funny state
just catting a large file and kill -STOP'ing ssh. ssh will close window,
but sshd will not send zero probes. Any socket with keepalives enabled
enters this state after the first keepalive is sent.
[ Note, that it is not Butenko's problem, it is still to be discovered. 8) ]

I think you will not able to reproduce full problem: socket will revive
after the first received ACK. It is another bug and its probability is
astronomically low.

Alexey


--- linux/net/ipv4/tcp_input.c.orig Mon Apr  9 22:46:56 2001
+++ linux/net/ipv4/tcp_input.c  Tue Apr 10 21:23:33 2001
@@ -733,8 +733,6 @@
if (tp->retransmits) {
if (tp->packets_out == 0) {
tp->retransmits = 0;
-   tp->fackets_out = 0;
-   tp->retrans_out = 0;
tp->backoff = 0;
tcp_set_rto(tp);
} else {
@@ -781,8 +779,10 @@
if(sk->zapped)
return(1);  /* Dead, can't ack any more so why bother */
 
-   if (tp->pending == TIME_KEEPOPEN)
+   if (tp->pending == TIME_KEEPOPEN) {
tp->probes_out = 0;
+   tp->pending = 0;
+   }
 
tp->rcv_tstamp = tcp_time_stamp;
 
@@ -850,8 +850,6 @@
if (tp->retransmits) {
if (tp->packets_out == 0) {
tp->retransmits = 0;
-   tp->fackets_out = 0;
-   tp->retrans_out = 0;
}
} else {
/* We don't have a timestamp. Can only use
@@ -878,6 +876,8 @@
tcp_ack_packets_out(sk, tp);
} else {
tcp_clear_xmit_timer(sk, TIME_RETRANS);
+   tp->fackets_out = 0;
+   tp->retrans_out = 0;
}
 
flag &= (FLAG_DATA | FLAG_WIN_UPDATE);
--- linux/net/ipv4/tcp_output.c.origMon Apr  9 22:47:06 2001
+++ linux/net/ipv4/tcp_output.c Tue Apr 10 21:23:33 2001
@@ -546,6 +546,8 @@
 */
kfree_skb(next_skb);
sk->tp_pinfo.af_tcp.packets_out--;
+   if (sk->tp_pinfo.af_tcp.fackets_out)
+   sk->tp_pinfo.af_tcp.fackets_out--;
}
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/