Re: test10-pre7

[Peter Samuelson]

[Vladislav Malyshkin <[EMAIL PROTECTED]>]
> Also, the function remove_duplicates can be written using make rules
> and functions.  Using functions "foreach" "if" from make and
> comparison you can easily build a function remove_duplicates in make,
> no shell involved.

Could you please write me this function?  I am curious to see how you
do it.

I am also a bit skeptical.  About 3 months ago, I thought it would be
possible to do this, so I spent a few hours fiddling around and reading
documentation.  I failed; nothing I tried worked.

> so instead of $(sort) your will have $(remove_duplicates) written
> entirely in make.

That would make me happy.

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

Re: test10-pre7

[Peter Samuelson]

[hpa]
> I would tend to agree with Linus on that.  If that's truly what
> you're doing, it would be rather nonobvious.

Well, ok, opinion vs. opinion.  The thing is, userspace code almost
*never* needs to care about link order -- and, not counting boot loader
magic, kernel code didn't care about it either until 2.3.16 or so
(debut of __initcall).  The reason link order suddenly became an issue
is that people started cutting out explicit lists of init code like
net/Space.c and relying on ld.  All in all that was a Good Thing -- it
made code more modular, etc.

My point here is that in most of the world, people are not accustomed
to caring about link order.  So I don't see why it's seen as such a
horrible thing to now say "ok link order is once again something you
ideally should not care about, *but* if there's a really good reason
otherwise, add your entry to LINK_FIRST."  Because the link-order-
*does*-matter paradigm is less than a year old, here.

> But the question, perhaps, is when does ordering matter.  I'm a
> little concerned about things highly dependent on link ordering.

Agreed.  And that is another point: we (Keith, Michael and I wrote all
this expecting link order to usually *not* matter -- LINK_FIRST was
just to cover corner cases.  Then we get Linus back saying the whole
drivers/scsi/ must be ordered *just so* (presumably so people don't
have to use boot flags for their multiple scsi host adapters) which is
either an unproven claim or, since it's Linus, a fiat.  (Which is OK,
don't get me wrong, better him than me making these decisions!)

And as for "rather nonobvious" -- it's not as if our stuff isn't
documented, at least.  Keith's patch includes several paragraphs added
to Documentation/kbuild/makefiles.txt, a file every kernel developer
should read anyway so that they know how to write correct makefiles.

Oh well.  Life goes on.  We can do fine without LINK_FIRST, but
possibly at the cost of increased cruft in the rest of the makefile
system.  (That depends on taste, I suppose.)

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

Linus's poll variation

[Lyle Coder]

Hello,
Is someone working on Linus's poll variation discussed in this list a week
ago?

Thanks
Lyle

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

Re: test10-pre7

[H. Peter Anvin]

Peter Samuelson wrote:
> 
> To Keith, Michael and me, the cleanest way to remove duplicates is
> $(sort).  Since some object files must *not* be sorted, we came up with
> a simple, readable way to declare that certain things had to come in a
> certain order -- the idea being that most of the time it would not be
> needed.  Linus disagrees that our solution is simple, readable or
> otherwise desirable.  That's basically the whole issue in a nutshell.
> 

I would tend to agree with Linus on that.  If that's truly what you're
doing, it would be rather nonobvious.

But the question, perhaps, is when does ordering matter.  I'm a little
concerned about things highly dependent on link ordering.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

test10 compile fails on alpha

[Tom Holroyd]

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe -mno-fp-regs -ffixed-8
-mcpu=ev6 -Wa,-mev6-c -o binfmt_elf.o binfmt_elf.c
binfmt_elf.c: In function `create_elf_tables':
binfmt_elf.c:166: `CLOCKS_PER_SEC' undeclared (first use in this function)
binfmt_elf.c:166: (Each undeclared identifier is reported only once
binfmt_elf.c:166: for each function it appears in.)

Um, is there any reason why you don't just use HZ instead of
CLOCKS_PER_SEC (which is pretty much Hz by definition)?
All the arches seem to define it as HZ anyway.

--- linux/include/asm-alpha/#param.hWed Nov  1 14:11:11 2000
+++ linux/include/asm-alpha/param.h Wed Nov  1 14:54:59 2000
@@ -26,5 +26,9 @@
 #endif
 
 #define MAXHOSTNAMELEN 64  /* max length of hostname */
+
+#ifdef __KERNEL__
+# define CLOCKS_PER_SEC HZ  /* frequency at which times() counts */
+#endif
 
 #endif /* _ASM_ALPHA_PARAM_H */


Also CONFIG_ALPHA_LARGE_VMALLOC is not recognized by "make xconfig".

Dr. Tom Holroyd
"I am, as I said, inspired by the biological phenomena in which
chemical forces are used in repetitious fashion to produce all
kinds of weird effects (one of which is the author)."
-- Richard Feynman, _There's Plenty of Room at the Bottom_

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

Re: Linux-2.4.0-test10

[Linus Torvalds]

On Tue, 31 Oct 2000, Miles Lane wrote:
> 
> Were there no changes between test10-pre7 and test10?
> I notice you didn't send out a Changelist.
> 
> The Changelists help me focus my testing.

Sorry. Here it is..

Linus
-
 - final:
- Jeff Garzik: ISA network driver cleanup, wrapper.h fixes, 8139too
  update, etc
- Mike Coleman: fix TracerPid in /proc//status
- Thomas Molina: mark NAT packet drop message KERN_DEBUG
- Marcelo Tosatti: nbd should use GFP_BUFFER, not GFP_ATOMIC
- Steve Pratt: TLB flush order fix
- David Miller: network and sparc updates
- Alan Cox: various details (NULL ptr checks in SCSI etc)
- Daniel Roesen: pretty up microcode revision printouts
- Mike Coleman: fix ptrace ambiguity issues
- Paul Mackerras: make yenta work even in the absense of ISA irqs
- me: make USB Makefile do the right thing for export-objs.
- Randy Dunlap, USB: fix race conditions, usb enumeration etc.

 - pre7:
- Niels Jensen: remove no-longer-needed workarounds for old gcc versions
- Ingo Molnar & Rik v Riel: VM inactive list maintenance correction
- Randy Dunlap, USB: printer.c, usb-storage, usb identification and
  memory leak fixes
- David Miller: networking updates
- David Mosberger: add AT_CLKTCK to elf information. And make AT_PAGESZ work
  for static binaries too.
- oops. pcmcia broke by mistake
- Me: truncate vs page access race fix.

 - pre6:
- Jeremy Fitzhardinge: autofs4 expiry fix
- David Miller: sparc driver updates, networking updates
- Mathieu Chouquet-Stringer: buffer overflow in sg_proc_dressz_write
- Ingo Molnar: wakeup race fix (admittedly the window was basically
  non-existent, but still..)
- Rasmus Andersen: notice that "this_slice" is no longer used for
  scheduling - delete the code that calculates it.
- ALI pirq routing update. It's even uglier than we initially thought..
- Dimitrios Michailidis: fix ipip locking bugs
- Various: face it - gcc-2.7.2.3 miscompiles structure initializers.
- Paul Cassella: locking comments on dev_base
- Trond Myklebust: NFS locking atomicity. refresh inode properly.
- Andre Hedrick: Serverworks Chipset driver, IDE-tape fix
- Paul Gortmaker: kill unused code from 8390 support.
- Andrea Arcangeli: fix nfsv3d wrong truncates over 4G
- Maciej W. Rozycki: PIIX4 needs the same USB quirk handling as PIIX3.
- me: if we cannot figure out the PCI bridge windows, just "inherit"
  the window from the parent. Better than not booting.
- Ching-Ling Lee: ALI 5451 Audio core support update

 - pre5:
- Mikael Pettersson: more Pentium IV cleanup.
- David Miller: non-x86 platforms missed "pte_same()".
- Russell King: NFS invalidate_inode_pages() can do bad things!
- Randy Dunlap: usb-core.c is gone - module fix
- Ben LaHaise: swapcache fixups for the new atomic pte update code
- Oleg Drokin: fix nm256_audio memory region confusion
- Randy Dunlap: USB printer fixes
- David Miller: sparc updates
- David Miller: off-by-one error in /proc socket dumper
- David Miller: restore non-local bind() behaviour.
- David Miller: wakeups on socket shutdown()
- Jeff Garzik: DEPCA net drvr fixes and CodingStyle
- Jeff Garzik: netsemi net drvr fix
- Jeff Garzik & Andrea Arkangeli: keyboard cleanup
- Jeff Garzik: VIA audio update
- Andrea Arkangeli: mxcsr initialization cleanup and fix
- Gabriel Paubert: better twd_i387_to_fxsr() emulation
- Andries Brouwer: proper error return in ext2 mkdir()

 - pre4:
- disable writing to /proc/xxx/mem. Sure, it works now, but it's still
  a security risk.
- IDE driver update (Victroy66 SouthBridge support)
- i810 rng driver cleanup
- fix sbus Makefile
- named initializers in module..
- ppoe: remove explicit initializer - it's done with initcalls.
- x86 WP bit detection: do it cleanly with exception handling
- Arnaldo Carvalho de Melo: memory leaks in drivers/media/video
- Bartlomiej Zolnierkiewicz: video init functions get __init
- David Miller: get rid of net/protocols.c - they get to initialize themselves
- David Miller: get rid of dev_mc_lock - we hold dev->xmit_lock anyway.
- Geert Uytterhoeven: Zorro (Amiga) bus support update
- David Miller: work around gcc-2.7.2 bug
- Geert Uytterhoeven: mark struct consw's "const".
- Jeff Garzik: network driver cleanups, ns558 joystick driver oops fix
- Tigran Aivazian: clean up __alloc_pages(), kill_super() and
  notify_change()
- Tigran Aivazian: move stuff from .data to .bss
- Jeff Garzik: divert.h typename cleanups
- James Simmons: mdacon using spinlocks
- Tigran Aivazian: fix BFS free block calculation
- David Miller: sparc32 works again
- Bernd Schmidt: fix undefined C code (set/use without a sequence point)
- Mikael Pettersson: nicer Pentium IV setup handling.
- 

Re: [patch] NE2000

[Paul Gortmaker]

Jeff Garzik wrote:
> 
> Paul Gortmaker wrote:
> > There is no urgency in trying to squeeze a patch like this in the back
> > door of a 2.4.0 release.  For example, there are people out there now
> > who are using the ne.c driver to run both ISA and PCI cards in the same
> > box without having to use 2 different drivers.  We can wait until 2.5.0
> > to break their .config file.
> 
> IMNSHO this is a bug, though...

Maybe I wasn't 100% clear - these are people who have intentionally
chosen to do so. (There is probably a slight icache benefit in sharing
the same driver like this, FWIW)

> Since ne2k-pci.c supports all boards ne.c does, and includes some fixes
> that ne.c does not, it seems like removing the PCI support in ne.c is a
> bug fix change.

If you want to roll it into the merge (and can get it past Linus) then
please feel free to do so - I'll be glad to cross it off my list sooner
as opposed to later.

In addition to removing all remains of PCI support from ne.c this patch
also has three trivial changes that were also in my queue for ne.c.

1) Two new ID signatures added to the bad_clone_list

2) int base_addr promoted to unsigned int base_addr in ne_probe,
   as required for SuperH CPU systems that have ne2000 cards.

3) ISA PnP card info printk'd *before* the actual probe, and
   not after (just in case the probe silently hangs or whatever).

Paul.

--- 2400-t10/linux-g/drivers/net/ne.c~  Tue Jul 11 02:29:10 2000
+++ 2400-t10/linux-g/drivers/net/ne.c   Wed Nov  1 00:02:17 2000
@@ -29,6 +29,7 @@
 occur after memory is allocated for dev->priv. Deallocated memory
 last in cleanup_modue()
 Richard Guenther: Added support for ISAPnP cards
+Paul Gortmaker : Discontinued PCI support - use ne2k-pci.c instead.
 
 */
 
@@ -43,7 +44,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -75,23 +75,6 @@
 };
 #endif
 
-#ifdef CONFIG_PCI
-/* Ack! People are making PCI ne2000 clones! Oh the horror, the horror... */
-static struct { unsigned short vendor, dev_id; char *name; }
-pci_clone_list[] __initdata = {
-   {PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8029, 
"Realtek 8029" },
-   {PCI_VENDOR_ID_WINBOND2,PCI_DEVICE_ID_WINBOND2_89C940,  
"Winbond 89C940" },
-   {PCI_VENDOR_ID_COMPEX,  PCI_DEVICE_ID_COMPEX_RL2000,
"Compex ReadyLink 2000" },
-   {PCI_VENDOR_ID_KTI, PCI_DEVICE_ID_KTI_ET32P2,   "KTI 
ET32P2" },
-   {PCI_VENDOR_ID_NETVIN,  PCI_DEVICE_ID_NETVIN_NV5000SC,  
"NetVin NV5000" },
-   {PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C926,   "VIA 
82C926 Amazon" },
-   {PCI_VENDOR_ID_SURECOM, PCI_DEVICE_ID_SURECOM_NE34, 
"SureCom NE34"},
-   {0,}
-};
-
-static int probe_pci = 1;
-#endif
-
 static struct { unsigned short vendor, function; char *name; }
 isapnp_clone_list[] __initdata = {
{ISAPNP_VENDOR('E','D','I'), ISAPNP_FUNCTION(0x0216),   "NN NE2000" },
@@ -114,7 +97,9 @@
 {"ET-100","ET-200", {0x00, 0x45, 0x54}}, /* YANG and YA clone */
 {"COMPEX","COMPEX16",{0x00,0x80,0x48}}, /* Broken ISA Compex cards */
 {"E-LAN100", "E-LAN200", {0x00, 0x00, 0x5d}}, /* Broken ne1000 clones */
-{"PCM-4823", "PCM-4823", {0x00, 0xc0, 0x6c}}, /* Broken Advantech MoBo */
+{"PCM-4823", "PCM-4823", {0x00, 0xc0, 0x6c}}, /* Broken Advantech MoBo */
+{"REALTEK", "RTL8019", {0x00, 0x00, 0xe8}}, /* no-name with Realtek chip */
+{"LCS-8834", "LCS-8836", {0x04, 0x04, 0x37}}, /* ShinyNet (SET) */
 {0,}
 };
 #endif
@@ -132,15 +117,9 @@
 #define NESM_START_PG  0x40/* First page of TX buffer */
 #define NESM_STOP_PG   0x80/* Last page +1 of RX ring */
 
-/* Non-zero only if the current card is a PCI with BIOS-set IRQ. */
-static unsigned int pci_irq_line = 0;
-
 int ne_probe(struct net_device *dev);
 static int ne_probe1(struct net_device *dev, int ioaddr);
 static int ne_probe_isapnp(struct net_device *dev);
-#ifdef CONFIG_PCI
-static int ne_probe_pci(struct net_device *dev);
-#endif
 
 static int ne_open(struct net_device *dev);
 static int ne_close(struct net_device *dev);
@@ -180,16 +159,9 @@
 {"ne", ne_probe1, NE_IO_EXTENT, netcard_portlist};
 #else
 
-/*
- * Note that at boot, this probe only picks up one card at a time, even for
- * multiple PCI ne2k cards. Use "ether=0,0,eth1" if you have a second PCI
- * ne2k card.  This keeps things consistent regardless of the bus type of
- * the card.
- */
-
 int __init ne_probe(struct net_device *dev)
 {
-   int base_addr = dev ? dev->base_addr : 0;
+   unsigned int base_addr = dev ? dev->base_addr : 0;
 
/* First check any supplied i/o locations. User knows best.  */
if (base_addr > 0x1ff)  /* Check a single specified location. */
@@ -197,12 +169,6 @@
else if (base_addr != 0)/* Don't probe at all. */
return 

Re: Linux-2.4.0-test10

[adrian]

On Tue, 31 Oct 2000, Linus Torvalds wrote:

[snip]
> Naah, he mainly just does some browsing with netscape, and (don't tell a
> soul) plays QuakeIII with the door locked.
> 
>   Linus

Although he might find that 2.2.18pre18 gives better frame rates.  :)

1024x768, Max detail, 32bit, 2.2.18pre18: 81fps

1024x768, Max detail, 32bit, 2.4.0-test10: 68fps


If he's really divine, he might notice a difference, unlike us mere
mortals.

Regards,
Adrian




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

Re: Linux-2.4.0-test10

[Miles Lane]

Linus,

Were there no changes between test10-pre7 and test10?
I notice you didn't send out a Changelist.

The Changelists help me focus my testing.

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

Re: 2.2.18Pre Lan Performance Rocks!

[Daniel Phillips]

"Jeff V. Merkey" wrote:
> A "context" is usually assued to be a "stack".  The simplest of all
> context switches is:
> 
>movx, esp
>movesp, y

Presumeably you'd immediately do a ret to some address, and there pop a
base address off the stack to get some global memory.  Is that right? 
Your context switches would be inline, and you'd have hardcoded which
process to execute next in most cases.

I'll buy the concept that changing stacks amounts to changing contexts,
so long as you follow certain rules.  Obviously, rules are what define a
context.  What are the two instructions that precede and the two
instructions that follow?  I'd guess, something like this:

   push bp
   push $1
   mov x, esp
   mov esp, y
   ret
$1 pop bp

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

Re: 2.2.18Pre Lan Performance Rocks!

[Peter Samuelson]

  [me]
> > So the real question is, how many gettimeofday() per sec can Linux
> > do?

[Larry McVoy]
> Oh, about 3,531,073 on a 1Ghz AM thunderbird running 
> Linux disks.bitmover.com 2.4.0-test5.

So, at two "context switches" (Jeff's term) per syscall, we're
somewhere around half the speed of Netware's longjmp.

Not bad. (:

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

Re: 2.2.18Pre Lan Performance Rocks!

[Larry McVoy]

On Tue, Oct 31, 2000 at 11:01:20PM -0600, Peter Samuelson wrote:
> So the real question is, how many gettimeofday() per sec can Linux do?

Oh, about 3,531,073 on a 1Ghz AM thunderbird running 
Linux disks.bitmover.com 2.4.0-test5.

That's 283.2 nanoseconds per call, to save you the math.
-- 
---
Larry McVoy  lm at bitmover.com   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.0-test10 AM53C974 driver cannot get kernel boot parameters. [patch]

[Kaz Sasayama]

I just tried version 2.4.0-test10 and found the AM53C974
driver does not get any kernel boot parameters when compiled
in the kernel.

This is my quick fix for it.  It seems some other drivers
need similar changes too, but I do not have fixes for them
yet.

Thanks.

diff -ur -x *~ -x .depend ../linux-2.4.0-test10/drivers/scsi/AM53C974.c 
linux-2.4.0-test10/drivers/scsi/AM53C974.c
--- ../linux-2.4.0-test10/drivers/scsi/AM53C974.c   Thu Oct  5 11:08:38 2000
+++ linux-2.4.0-test10/drivers/scsi/AM53C974.c  Wed Nov  1 13:22:59 2000
@@ -572,18 +572,23 @@
 }
 
 /**
-* Function : AM53C974_setup(char *str, int *ints)
+* Function : AM53C974_setup(char *str)
 *
 * Purpose : LILO command line initialization of the overrides array,
 * 
-* Inputs : str - unused, ints - array of integer parameters with ints[0]
-*  equal to the number of ints.
+* Input : str - parameter string.
+*
+* Returns : 1.
 *
 * NOTE : this function needs to be declared as an external function
 * in init/main.c and included there in the bootsetups list
 ***/
-void AM53C974_setup(char *str, int *ints)
+int AM53C974_setup(char *str)
 {
+   int ints[5];
+
+   get_options(str, ARRAY_SIZE(ints), ints);
+
if (ints[0] < 4)
printk("AM53C974_setup: wrong number of parameters;\n correct syntax 
is: AM53C974=host-scsi-id, target-scsi-id, max-rate, max-offset\n");
else {
@@ -604,7 +609,10 @@
} else
printk("AM53C974_setup: too many overrides\n");
}
+
+   return 1;
 }
+__setup("AM53C974=", AM53C974_setup);
 
 #if defined (CONFIG_PCI)
 /**
diff -ur -x *~ -x .depend ../linux-2.4.0-test10/drivers/scsi/AM53C974.h 
linux-2.4.0-test10/drivers/scsi/AM53C974.h
--- ../linux-2.4.0-test10/drivers/scsi/AM53C974.h   Tue Sep 26 11:55:39 2000
+++ linux-2.4.0-test10/drivers/scsi/AM53C974.h  Wed Nov  1 13:33:06 2000
@@ -68,7 +68,7 @@
 use_clustering: DISABLE_CLUSTERING   \
 }
 
-void AM53C974_setup(char *str, int *ints);
+int AM53C974_setup(char *str);
 int AM53C974_detect(Scsi_Host_Template * tpnt);
 int AM53C974_release(struct Scsi_Host *shp);
 int AM53C974_biosparm(Disk * disk, int dev, int *info_array);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux-2.4.0-test10

[M.H.VanLeeuwen]

FYI,

My list of 2.4.0-testX problems

Further details, .config, etc...available if needed

Martin

2.4.0-test10 and earlier problem list:
 
Problem |   UP  UP-APIC SMP
|
1   |   OK  OK  HARDLOCK
2   |   OK  FAILS   OK
3   |   HARDLOCKHARDLOCKHARDLOCK
4   |   BROKEN  BROKEN  BROKEN

Problem description:
 
1.  kernel compiled w/o FB support.  When attempting to switch
back to X from VC1-6 system locks hard for SMP.  Nada thing
fixes this except hard reset... no Alt-SysRq-B, nothing
DRI not enabled.  Video card has r128 chipset.
 
2.  System is a NFS root machine, after a period of heavy ntwk
activity, eg. "make clean" in /usr/src/linux ETH0 no longer
works or sometimes just ntwk activity during system boot is
enough to cause the ETH activity to cease.
The only recourse is to Alt-SysRq-B the system.
NIC = NE2K ISA
 
3. Enabling PIIX4, kernel locks hard when printing the partition
   tables for hdc.   hdc has no partitions.
   I think this problem is on Ted's problem list???
 
4. ISAPNP assigns an invalid/unusable IRQ to NE2K NIC card.
   Previously reported to Linux & Ingo, they asked for an MPTABLE
   dump, haven't heard back since providing said data.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Peter Samuelson]

[Jeff Merkey]
> > > The numbers don't lie. [...]
> > 
  [Ingo Molnar]
> > sure ;) I can do infinite context switches! You dont believe? See:
> > 
> > #define schedule() do { } while (0)

[Jeff]
> Actually, I think the compiler would optimize this statement
> completely out of the code.

That was Ingo's point.  He is doing infinite context switches per
second, where a context switch is defined as "schedule()", because he
turned it into a noop.

I.e. the numbers can easily be made to lie, by playing with the rules
of the game.

The point of confusion, Jeff, is that to *you* a context switch means
stack switch, with no baggage like scheduling or reloading registers.
Everyone else here thinks of a context switch as meaning a pre-emptive
switch between two unrelated processes -- which as you know involves
not only the stack, but MM adjustments, registers, floating point
registers (expensive on pre-P6), IP, and some form of scheduling.

Obviously some of these can be optimized out if you can make
assumptions about the processes: you might drop memory protection if
you like the stability of Windows 95, floating point if you can get
away with telling people they can't use it, maybe use FIFO scheduling
if you don't care about fairness and you know the processes are more or
less uniform.  Linux cannot make any of these assumptions -- it is far
too general-purpose.

In Linux, in fact, jumping from ring 3 to ring 0 (ie system call) is
not considered a context switch.  I suppose you would consider it one.
So the real question is, how many gettimeofday() per sec can Linux do?

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

Re: scsi-cdrom lockup and ide-scsi problem (both EFS related)

[Miles Lane]

Jens Axboe wrote:
> 
> On Tue, Oct 31 2000, Paul Jakma wrote:
> > I have 2 problems related to reading IRIX EFS cd's.
> >
> > ---problem 1:
> >
> > mounting an EFS cd from my Yamaha CDR-4416S SCSI CDRW consistently
> > causes a lockup when i try to read directory/file data from the CD. I
> > observed this initially with EFS CDR's, and assumed something had
> > gone wrong when burning that CD. But the exact same thing happens
> > with original SGI IRIX media. I have no problems with any of my EFS
> > CDs when accesed from an ATAPI CDROM.
> 
> Known problem, blocksizes != 2kb does not currently work
> correctly with SCSI CD-ROM (it's even on Ted's list).

Could this have something to do with the problem I reported where
running:

dd if=/dev/zero of=/dev/sda bs=1k count=2G

to write data to my ORB drive over a USB connection causes
all writing to my hard drive to cease?  The USB Storage
driver uses a virtual SCSI interface.

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

Repeatable oops mounting snapshot fs on 2.4.0-test10

[J Sloan]

Greetings,

I'm just getting started playing around with the lvm.
I've used the HP-UX lvm, and was giving the Linux
version a spin for the very first time when I ran into
some big problems:

Let me know if I'm doing something really stupid, but
something tells me a kernel oops is not a good sign!

An excerpt from the fateful session:
-
wintermute: /root
(tty/dev/pts/0): bash: 1014 > lvcreate -L 2000 -s -n snap1
/dev/lxlvm/lvm1
lvcreate -- INFO: using default snapshot chunk size of 64 KB
lvcreate -- doing automatic backup of "lxlvm"
lvcreate -- logical volume "/dev/lxlvm/snap1" successfully created

wintermute: /root
(tty/dev/pts/0): bash: 1015 > mount /dev/lxlvm/snap1 /snapshots/d1/
segmentation fault
--

The volume was not mounted.

oops -> ksymoops follows:

ksymoops 0.7c on i686 2.4.0-test10.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test10/ (default)
 -m /boot/System.map (specified)

CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 178a   ebx: d16d6570   ecx: d16d6400   edx: 
esi: 178c   edi: 0002   ebp:    esp: d16d1c34
ds: 0018   es: 0018   ss: 0018
Process mount (pid: 2947, stackpage=d16d1000)
Stack: d16d6570 178c 0002  0243  080566f4
06f4
    d2885fa2 d16d1cce d16d1cd0 178a d16d6400 d16beba0
0002
   00e8 0002 d16d c0142f1c d288e000 090c c014424b
080566f4
Call Trace: [] [] [] []
[] [] []
   [] [] [] [] []
[] [] []
   [] [] [] [] []
[] []
   [] [] []
Code: f7 b1 64 01 00 00 8b 44 24 2c 89 d3 8b 30 89 f7 29 df 89 f8

>>EIP; d2887f31 <[lvm-mod]lvm_snapshot_remap_block+11/f4>   <=
Trace; d2885fa2 <[lvm-mod]lvm_map+446/4b8>
Trace; c0142f1c 
Trace; d288e000 <[lvm-mod]__module_using_checksums+2024/11084>
Trace; c014424b 
Trace; c014367c 
Trace; d288604b <[lvm-mod]lvm_make_request_fn+f/18>
Trace; c01584e0 
Trace; c01586b3 
Trace; c01332db 
Trace; c0129259 <__alloc_pages+e1/2c8>
Trace; c011f4d7 
Trace; c011f554 
Trace; c011f6d0 
Trace; c0110620 
Trace; c0110767 
Trace; c0110620 
Trace; c0129259 <__alloc_pages+e1/2c8>
Trace; c011f4d7 
Trace; c011f554 
Trace; c0136624 
Trace; c0136f8f 
Trace; c0133b53 
Trace; c012c41f 
Trace; c012c356 
Trace; c012ca5e 
Trace; c010a3ff 
Code;  d2887f31 <[lvm-mod]lvm_snapshot_remap_block+11/f4>
 <_EIP>:
Code;  d2887f31 <[lvm-mod]lvm_snapshot_remap_block+11/f4>   <=
   0:   f7 b1 64 01 00 00 div0x164(%ecx),%eax   <=
Code;  d2887f37 <[lvm-mod]lvm_snapshot_remap_block+17/f4>
   6:   8b 44 24 2c   mov0x2c(%esp,1),%eax
Code;  d2887f3b <[lvm-mod]lvm_snapshot_remap_block+1b/f4>
   a:   89 d3 mov%edx,%ebx
Code;  d2887f3d <[lvm-mod]lvm_snapshot_remap_block+1d/f4>
   c:   8b 30 mov(%eax),%esi
Code;  d2887f3f <[lvm-mod]lvm_snapshot_remap_block+1f/f4>
   e:   89 f7 mov%esi,%edi
Code;  d2887f41 <[lvm-mod]lvm_snapshot_remap_block+21/f4>
  10:   29 df sub%ebx,%edi
Code;  d2887f43 <[lvm-mod]lvm_snapshot_remap_block+23/f4>
  12:   89 f8 mov%edi,%eax


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

1.2.45 Linux Scheduler

[Anonymous]

In the Linux scheduler they use a circular queue implementation with round
robin. What is the advantage of this over just using a normal queue with a
back and front. Also does anyone know what a test plan for such a design
would even begin to look like. This is a project for a proposal going around
in my neighborhood and I am wondering why in the world someone would want to
modify the Linux scheduler to this extent.


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

[ANN] 1st release of USAGI IPv6 environment

[usagi-core]

Sorry for our mess mail, but we want to improve linux kernel.

We are glad to announce the 1st release of USAGI Project. The "USAGI"
means UniverSAl playGround for Ipv6. It is the IPv6 development project
for Linux operating systems mainly.

As many other operating systems and routers, the Linux kernel has
its original IPv6 implementation.  However, the development was done
long time ago and the implementation is not up-to-dated. Many important
features such as IPsec and NDP are missing or miss-implemented.

Considering the situation, we have started USAGI Project with WIDE Project,
KAME Project and TAHI Project in August 2000. 

The USAGI Project is managed by volunteers and aims to provide
better IPv6 environment on Linux freely. We try to improve Linux kernel,
IPv6 related libraries and IPv6 applications.

Please visit http://www.linux-ipv6.org/ for further details.

Today, November 1st, we are glad to announce 1st official release from
USAGI Project. At the release, we include the following three packages.

- Linux Kernel-2.4.0-test9-usagi-20001101a
Based on Linux Kernel-2.4.0-test9, we have improved and
implemented
+ better source address selection,
+ ICMPv6 Node Information Queries,
+ SNMP statistics per device,
+ IPv6 khttpd,
+ joining all-node multicast address on network devices and
+ many bug fixes.

- glibc-2.1.3-usagi-20001101a
Based on glibc-2.1.3, we have improved
+ supporting sin6_scope_id,
+ adding AF_ADDRCONFIG flag,
+ some RFC2292 functions,
+ adding getifaddrs API and
+ some bug fixes.

- iputils-ss000418-usagi-20001101a
Based on iputils-ss000418, we have improved
+ supporting sin6_scope_id,
+ IPMPv6 Node Information Queries and
+ supporting Autoconfigure.

You can get above source codes from the following URL.
ftp://ftp.linux-ipv6.org/pub/usagi/stable/patch/


USAGI Project will release snapshot codes on each two weeks and
after implementing some features, we will release stable codes.
We will announce latest information regarding releasing codes
via web page. Please check our web site.

We also provide the binary packages for some distributions.
Some of the binary packages have diffrent code version with original
USAGI code because of packaging policy. You can get the packages from
following sites.

Debian GNU/Linux 2.2 (potato)
ftp://ftp.linux-ipv6.org/pub/usagi/stable/package/debian/

Kondara MNU/Linux (Jirai)
ftp://ftp.linux-ipv6.org/pub/usagi/stable/package/kondara/

RedHat Linux 7.0
ftp://ftp.linux-ipv6.org/pub/usagi/stable/package/redhat/

TurboLinux 6.0 (or later) (for Japanese version)
ftp://ftp.linux-ipv6.org/pub/usagi/stable/package/turbo/

By the way, we manage the mailing list for USAGI users. If you have 
questions or advices, please join the mailing list. For more ditails, 
please see http://www.linux-ipv6.org/ml/ .

Thanks.

Related Web sites.
WIDE Projecthttp://www.wide.ad.jp/
KAME Projecthttp://www.kame.net/
TAHI Projecthttp://www.tahi.org/

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

Re: Linux-2.4.0-test10

[Jeremy Fitzhardinge]

On Tue, Oct 31, 2000 at 08:55:13PM +, Alan Cox wrote:
>   Does autofs4 work yet

Autofs4 was fixed in 2.4.0-test10-pre6 or so.  Autofs4 for 2.2.x has
been working for some time, though I just updated the 2.2 patch so it
doesn't stomp on autofs (v3).

J

 PGP signature

Re: 2.2.18Pre Lan Performance Rocks!

[Jesse Pollard]

On Tue, 31 Oct 2000, Horst von Brand wrote:
>Jesse Pollard <[EMAIL PROTECTED]> said:
>
>[...]
>
>> Also pay attention to the security aspects of a true "zero copy" TCP stack.
>> It means that SOMETIMES a user buffer will recieve data that is destined
>> for a different process.
>
>Why? AFAIKS, given proper handling of the issues involved, this can't
>happen (sure can get tricky, but can be done in principle. Or am I
>off-base?)

As I understand the current implementation, this can't. One of the optimizations
I had read about (for a linux test) used zero copy to/from user buffer as well
as zero copy in the kernel. I believe the DMA went directly to the users memory.

This causes a problem when/if there is a context switch before the data is
actually transferred to the proper location. The buffer isn't ready for use,
but could be examined by the user application (hence the security problem).

It was posed that this is not a problem IF the cluster (and it was a beowulf
cluster under discussion) is operated in a single user, dedicated mode.
In which case, to examine the buffer would either be a bug in the program,
or a debugger looking at a buffer directly.

To my knowlege, zero copy is only done to/from device and kernel. Userspace
has to go through a buffer copy (one into user space; one output from user
space) for all IP handling. All checksums are either done by the device,
or done without copying the data.

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

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

user-mode port 0.32-2.4.0-test10

[Jeff Dike]

The user-mode port of 2.4.0-test10 is available.

The stack overflows seen in test9 are fixed.  The stack is now allocated as 
four pages, the top two used as a kernel stack, the third is inaccessible and 
acts as a guard page, and the lowest page contains the task structure.

Host devices can again be mounted inside the virtual machine.  This was broken 
a few releases ago when I made the block driver check io requests against the 
device size.

It will no longer crash if the main console is not a terminal.

I fixed a race which was causing strange kernel memory faults.

In the sources (the patch and cvs), but not the binaries, there is the 
beginning of a hostfs filesystem.  This gives you access to the host root 
filesystem.  Doing 'mount none /wherever -t hostfs' will mount the host root 
filesystem on /wherever.  Right now, you can mount it and cd into it, but ls 
will crash the kernel.

The project's home page is http://user-mode-linux.sourceforge.net

The project's download page is http://sourceforge.net/project/filelist.php?grou
p_id=429

Jeff


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

Patch: linux-2.4.0-test10-pre7/drivers/usb/usb.c driver matching bug

[Adam J. Richter]

linux-2.4.0-test10-pre7/drivers/usb/usb.c introduced a really
cool feature, where USB drivers can declare a data structure that
describes the various ID bytes of the USB devices that they are
relevant to.  Updated versions of depmod and hotplug are then
used so that the appropriate USB drivers can then be loaded
automatically as soon as you plug in a device, without any
need to create additional system configuration files.

Anyhow, the USB implementation of this has a tiny bug,
where it does an apples-and-oranges comparison.  The patch is
attached below.

Since the USB device table support is in
linux-2.4.0-test10-pre7 and not in the HEAD branch of the
linux-usb CVS tree on sourceforge.net, and since the bug fix
is very clear and small, I am sending this patch to Linus and 
linux-kernel in addition to linux-usb-devel.  If there is some
better way that I should submit a patch in this sort of situation,
please let me know.  I don't mean to step on anyone's toes.

By the way, I was able to test this all the way to the
point of plugging in a USB printer and watching the module
automatically load and bind to the printer interface.  (I
will submit the usb/printer.c device table support patch to
linux-usb-devel momentarily.)

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

--- linux-2.4.0-test10-pre7/drivers/usb/usb.c   Tue Oct 31 02:42:50 2000
+++ linux/drivers/usb/usb.c Tue Oct 31 19:26:14 2000
@@ -540,7 +540,7 @@
if (id->bInterfaceClass
&& id->bInterfaceClass == intf->bInterfaceClass) {
if (id->bInterfaceSubClass && id->bInterfaceSubClass
-   != intf->bInterfaceClass)
+   != intf->bInterfaceSubClass)
continue;
if (id->bInterfaceProtocol && id->bInterfaceProtocol
!= intf->bInterfaceProtocol)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre7

[Peter Samuelson]

  [Peter Samuelson]
> > There are two ways to handle this:
> >
> >   obj-$(CONFIG_WD80x3) += wd.o 8390.o
> >   obj-$(CONFIG_EL2) += 3c503.o 8390.o
> >   obj-$(CONFIG_NE2000) += ne.o 8390.o
> >   obj-$(CONFIG_NE2_MCA) += ne2.o 8390.o
> >   obj-$(CONFIG_HPLAN) += hp.o 8390.o

[John Alvord <[EMAIL PROTECTED]>]
> You can avoid duplicates with
>   obj-$(CONFIG_WD80x3) += wd.o
>   ifneq (,$(findstring 8390.o,obj-$(CONFIG_WD80x3))
>  obj-$(CONFIG_WD80x3) += 8390.o
>   endif
>  
> Which is wordy but accomplishes the objective of avoiding duplicates.

I said "there are two ways to handle this".  You snipped the second,
which was:

> > ...Or do horrible games with 'if' statements and temporary
> > variables with names like $(NEED_8390) to ensure that it gets
> > included once if needed and not if not -- thereby pretty much
> > defeating the readability of the new-style makefiles.

I would consider your approach a variant of the "horrible games with if
statements and temporary variables". (:

Here's an exercise to the reader: reformat drivers/net/Makefile using
John Alford's approach, diff the two, and take a look.  Then come back
and tell me LINK_FIRST -- 0-2 lines in the Makefile depending on your
ordering requirements, plus about five lines in Rules.make (*yes*, it
really is that simple) -- is really uglier.

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

Re: test10-pre7

[Peter Samuelson]

[hpa]
> I was going to ask to what extent we genuinely need sorting, and if
> we might be better off trying to eliminate that need as much as
> possible.

We don't need sorting.  We need removing of duplicates.  The GNU make
sort function removes duplicates as a side effect, which is why we want
to use it.

As has been discussed, there are lots of ways to remove duplicates.
You can spawn a shell script, you can keep track of each "common" file
with a tristate make variable, you can play with deeply nested if
statements, and rumor has it you may be able to write a custom GNU make
function (though I have doubts, as I have tried this before and
couldn't get anything to work).

To Keith, Michael and me, the cleanest way to remove duplicates is
$(sort).  Since some object files must *not* be sorted, we came up with
a simple, readable way to declare that certain things had to come in a
certain order -- the idea being that most of the time it would not be
needed.  Linus disagrees that our solution is simple, readable or
otherwise desirable.  That's basically the whole issue in a nutshell.

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

release: packet-0.0.2d

[Jens Axboe]

Hello,

I've just uploaded a new release of the packet writing patch, this time
against the 2.4.0-test10 kernel. The bugs fixes that I've actually
cared/remembered to write down are:

- (scsi) use implicit segment recounting for all hba's
- fix speed setting, was consistenly off on most drives
- only print capacity when opening for write
- fix off-by-two error in getting/setting write+read speed (affected
  reporting as well as actual speed used)
- possible to enable write caching on drive
- do ioctl marshalling on sparc64 from Ben Collins <[EMAIL PROTECTED]>
- avoid unaligned access on flags, should have been unsigned long of course
- fixed missed wakeup in kpacketd
- b_dev error (two places)
- fix buffer head b_count bugs
- fix hole merge bug, where tail could be added twice
- fsync and invalidate buffers on close
- check hash table for buffers first before using our own
- add read-ahead
- fixed several list races
- fix proc reporting for more than one device
- change to O_CREAT for creating devices
- added media_change hook
- added free buffers config option
- pkt_lock_tray fails on failed open (and oopses), remove it. unlock
  is done explicitly in pkt_remove dev anyway.
- added proper elevator insertion (should probably be part of elevator.c)
- moved kernel thread info to private device, spawn one for each writer
- added separate buffer list for dirty packet buffers
- fixed nasty data corruption bug
- remember to account request even when we don't gather data for it
- add ioctl to force wakeup of kernel thread (for debug)
- fixed packet size setting bug on zero detected
- changed a lot of the proc reporting to be more readable to "humans"
- set full speed for read-only opens

People wanting to give it a go, should also remember to update their
UDF cvs tree (CDRW branch) and install new cdrwtool and pktsetup
binaries.

Interoperability with DirectCD has been tested, and that seems to work.

Bugs / success stories (yeah right) should be repoted to the
packet-writing list.

*.kernel.org/pub/linux/kernel/people/axboe/packet/packet-0.0.2d.diff.bz2

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

Re: test10-pre7

[Peter Samuelson]

[Russell King]
> Since someone kindly enlightened me that LINK_FIRST was unsorted, I'm
> finding it very hard to grasp what the difference is between an
> unsorted LINK_FIRST and unsorted LINK_LAST list, and an unsorted
> obj-y list.  From what I understand, obj-y = $(LINK_FIRST)
> $(LINK_LAST) ?

Not quite.  If that's how you understand it, I see why you think it's a
bad idea.  Here's what is *really* happening:

  obj-y = {subset of LINK_FIRST that is in obj-y} \
  {subset of obj-y that is not in LINK_FIRST or LINK_LAST} \
  {subset of LINK_LAST that is in obj-y}

GNU make has extensions that make this easy to implement -- no more
verbose than the pseudocode, in fact.

The biggest difference between LINK_FIRST and obj-y is that LINK_FIRST
is meant to be a static list, not dependent on CONFIG_*, and specifies
*only* those objects which must be linked before (or after, for
LINK_LAST) other objects.  In the common case, most object files do
*not* appear in LINK_FIRST or LINK_LAST, but just in O_OBJS.

In the pathological case of strict requirements for the whole
directory, LINK_FIRST would contain all of obj-y.  Keith and I think
this is a rare case -- a more common case is the opposite:
LINK_FIRST/LAST are empty because there are *no* ordering requirements.


Again, anything that appears in O_OBJS but not in LINK_FIRST is linked
in arbitrary order.  Anything that appears in LINK_FIRST but not in
O_OBJS is ignored.  That is why it can be a static list.

Since LINK_FIRST is a (usually short) static list, it is easy for the
author to guarantee that it has no duplicate files in it.  By contrast,
O_OBJS (or obj-y) frequently has duplicates, because of things like

  obj-$(CONFIG_FOO) := foo.o xxx.o
  obj-$(CONFIG_BAR) := bar.o xxx.o

where xxx.o is something like 8390 support for network cards.

Removing duplicates is a side effect of the GNU make 'sort' function,
which is THE ONLY REASON we want to sort $(O_OBJS).  The reordering is
the "other" side effect, the less desirable one.  GNU make does not
provide a 'uniq-without-sort' function, and while one is trivial to
write in e.g. shell, some of us consider a shell hack to be, well, more
hackish than LINK_FIRST.

** BTW, the only reason I'm still posting to this thread, which seems
   pretty moot because "Linus Has Spoken", is that I believe there is
   still a lot of misunderstanding about what LINK_FIRST actually does.
   When I'm satisfied that the opponents truly *understand* LINK_FIRST
   and still oppose it, I'll shut up.

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

Re: test10-pre7

[Keith Owens]

On Tue, 31 Oct 2000 09:31:09 -0800 (PST), 
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>On Wed, 1 Nov 2000, Keith Owens wrote:
>>
>> LINK_FIRST is processed in the order it is specified, so a.o will be
>> linked before z.o when both are present.  See the patch.
>
>So why don't you do the same thing for obj-y, then?
>
>Why can't you do
>
>   LINK_FIRST=$(obj-y)
>
>and be done with it?

You are assuming that every object in obj-y has a link order
requirement.  This is *not* true.  To use your own example

  O_OBJS is all objects.
  OX_OBJS is the subset of O_OBJS that have SYMTABS.
  LINK_FIRST is the subset of O_OBJS that have link order dependencies
  and must be linked first if present.
  LINK_LAST is the subset of O_OBJS that have link order dependencies
  and must be linked last if present.

You see - OX_OBJS, LINK_FIRST, LINK_LAST are subset indicators which
modify the set of O_OBJS.

>You need to have 
>   LINK_FIRST1
>   LINK_FIRST2
>   LINK_FIRST3
>   ...
>etc to get the proper ordering.

No.  LINK_FIRST := $(LINK_FIRST1) $(LINK_FIRST2) $(LINK_FIRST3)
The existing declaration order is a linear list so LINK_FIRST can
always be a linear list, no need for multiple lists.  If you really did
need multiple LINK_FIRSTn entries than the existing single order would
not be good enough either.

In almost all cases, LINK_FIRST will be one or two objects, LINK_LAST
will be zero, one or two objects.  The rest of the objects will have no
link order dependencies.  Some Makefiles already sort their obj-y list
because they have _zero_ link order requirements, they have no problems.

Look at the possible cases :-

* No link order requirements.  Do not specify LINK_FIRST/LAST.

  Object A must precede B, C must precede D, no other dependencies, in
  particular A and C can be in any order, B and D can be in any order.
LINK_FIRST := A.o C.o
  or 
LINK_FIRST := C.o A.o
  You do not specify _all_ the ordering, just the ones that must come
  first.  The rest of the order drops out automatically.

* Card foo is supported by drivers baz, bar, foop.  Try baz last.
  LINK_LAST := baz.o.
  You do not specify _all_ the ordering, just the ones that must come
  last.  The rest of the order drops out automatically.

* SCSI.  This is poorly documented (one of the problems that LINK_xxx
  will solve) but AFAIK the requirements are
buslogic must be before aha1542
NCR53c406a must be before qlogic
st, sd_mod, sr_mod, sg must be after all drivers.
  LINK_FIRST := BusLogic.o NCR53c406a.o
  LINK_LAST  := st.o sd_mod.o sr_mod.o sg.o 

>In many other cases, like SCSI, we need almost _total_ ordering. For such
>a case, theer is no "first" or "last" - there is a well-specific ORDER.

I refuse to believe that SCSI needs a total order.  There are only a
few inter driver problems that require the probe to run in a specific
order.  The rest of the drivers can run in any order.

If all of the 82 config options in SCSI really need to be in that exact
order, where is it documented and why do they need to be in that order?
Having a single fixed probe order to handle machines with mutiple types
of SCSI cards is not a good enough reason.  People with multiple SCSI
cards already change the order of scsi entries to get the probe order
that suits them, LINK_FIRST will make that even easier.

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

Re: test10-pre7

[Peter Samuelson]

[Linus]
> But it doesn't even WORK.
> 
> You need to have 
> 
>   LINK_FIRST1
>   LINK_FIRST2
>   LINK_FIRST3
>   ...
> 
> etc to get the proper ordering.

???  No you don't.  Perhaps you mean something else.  Here's how
LINK_FIRST works:

Say you have foo.o, bar.o, baz.o and lots of other objects.  foo.o must
come before bar.o which must come before baz.o which must come before
some other object.  But of course all of the above are conditional:
they can be configured as modules, or not at all.

  LINK_FIRST := foo.o bar.o baz.o

  obj-$(CONFIG_BAR) += bar.o
  obj-$(CONFIG_BAZ) += baz.o
  obj-$(CONFIG_BLURFL) += blurfl.o
  obj-$(CONFIG_FOO) += foo.o
  obj-$(CONFIG_...).

Problem solved.  If CONFIG_FOO=y CONFIG_BAR=n CONFIG_BAZ=y etc, link
order is

  foo.o baz.o {everything else}

In short, LINK_FIRST/LINK_LAST take care of any case I can think of in
the kernel.  Including things like "buslogic and aha174x must come
before aha1520, but the two parallel zip drivers must come last in
drivers/scsi because you don't want to renumber scsi drives more than
you have to" or "certain ISA cards must come after ne.c because of
autoprobe lockups on cheap ne clones, but ne2kpci should come *before*
ne so ne won't get the pci cards".

> In many other cases, like SCSI, we need almost _total_ ordering. For such
> a case, theer is no "first" or "last" - there is a well-specific ORDER.

I don't understand why we need *total* ordering -- I am only aware of a
few specific requirements.

Anyway, we still need to remove duplicates.  NCR53c9x.o appears a lot.
If we can make all those cases go away by use of CONFIG_SCSI_53C9X or
something, I will be a lot happier.  Your proposed method,

  obj-53C9X-$(CONFIG_SCSI_MCA_53C9X) := y
  obj-53C9X-$(CONFIG_SCSI_OKTAGON) := y
  obj-$(obj-53C9X-y) := y
  obj-$(obj-53C9X-m) := m

is definitely less ugly than a lot of what we do now ... but I still
don't like it.  Mostly because each shared object file creates
special-case code in the makefile.

> The only way it would work is to make LINK_FIRST maintain the order,
> but once you do that LINK_FIRST is completely superfluous, as it ends
> up being exactly the same as $(obj-y).

The theory behind LINK_FIRST is that most drivers do not care about
their order: the ones that do are the exception, not the rule.  If in
fact you *do* care about the order of every last driver in the kernel,
then I agree that LINK_FIRST is a bad idea.

> So trust me, LINK_FIRST/LINK_LAST is not going to happen. 

> And if you really want to remove duplicates, at worst we can even use
> an external program for it - which would solve all these things once
> and for all.

This is true.  Mainly what we disagree on is which method is the bigger
kludge. (:

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

Re: 2.2.18Pre Lan Performance Rocks!

[Horst von Brand]

"Jeff V. Merkey" <[EMAIL PROTECTED]> said:
> One more optimization it has.  NetWare never "calls" functions in the
> kernel.  There's a template of register assignments in between kernel
> modules that's very strict (esi contains a WTD head, edi has the target
> thread, etc.) and all function calls are jumps in a linear space. 
> layout of all functions are 16 bytes aligned for speed, and all
> arguments in kernel are passed via registers.  It's a level of
> optimization no C compiler does -- all of it was done by hand, and most
> function s in fast paths are layed out in 512 byte chunks to increases
> speed.  Stack memory activity in the NetWare kernel is almost
> non-existent in almost all of the "fast paths"

Nice! Now run that (i386 optimized?) beast on a machine that works
different (latest K7s perhaps?), and many optimizations break.

When you got that fixed, would you please port it to Alpha?

Sure, using C (with a not-overly-bright compiler) has a non-negligible
cost. But huge benefits too. The whole of software (including OS) design is
an excercise in delicate juggling among conflicting goals. Had Linus gone
down the "all-assembler, bummed to its limits" route, Linux would have been
dead by 0.03 or so, depending on the stubborness of its creator to be sure.
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616

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

ipac usb abnt2 (others?) keyboard fix

[Carlos E. Gorges]

Hi all,

This fixes "/" key in abnt2 ( pt_BR ) keyboard of ipac ( compac computer ).
2.2.17 fix need a suse usb backport patch ( I use test2-pre2 ).

-- 
 _
 Carlos E Gorges  
 ([EMAIL PROTECTED])
 Tech informática LTDA
 Brazil   
 _


 ipac-usbabnt2-2.2.17.diff.gz
 ipac-usbabnt2-2.4.0-test10.diff.gz

Re: Linux-2.4.0-test10

[Tom Rini]

On Tue, Oct 31, 2000 at 12:41:55PM -0800, Linus Torvalds wrote:
 
> Ok, test10-final is out there now. This has no _known_ bugs that I
> consider show-stoppers, for what it's worth.

Sure, it's not a critical bug or anything but hey.  One more time:
This is a very minor patch for fs/nls/Config.in, which Petr Vandrovec came up
with.  The problem is that if CONFIG_INET is n, CONFIG_SMB_FS is never set
so fs/nls/Config.in assumes that the user wants to select some NLS options.
This fixes it and works on config/menuconfig/xconfig.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


--- fs/nls/Config.in.orig   Thu Oct 19 12:54:09 2000
+++ fs/nls/Config.inThu Oct 19 12:54:32 2000
@@ -2,10 +2,17 @@
 # Native language support configuration
 #
 
+# smb wants NLS
+if [ "$CONFIG_SMB_FS" = "m" -o "$CONFIG_SMB_FS" = "y" ]; then
+  define_bool CONFIG_SMB_NLS y
+else
+  define_bool CONFIG_SMB_NLS n
+fi
+
 # msdos and Joliet want NLS
 if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \
-o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \
-   -o "$CONFIG_SMB_FS" != "n" ]; then
+   -o "$CONFIG_SMB_NLS" = "y" ]; then
   define_bool CONFIG_NLS y
 else
   define_bool CONFIG_NLS n

Re: test10-pre7 (LINK ordering)

[Keith Owens]

On Tue, 31 Oct 2000 17:24:24 -0800, 
"Dunlap, Randy" <[EMAIL PROTECTED]> wrote:
>Is it valid to run depmod like this before
>booting the kernel that has usbcore in-kernel?
>depmod -ae works after I boot that kernel + usbcore.

To run depmod against a new 2.4.0-test10 kernel,
  make modules_install
  depmod -ae -F System.map 2.4.0-test10
Without -F, depmod reads /proc/ksyms which are for the old kernel.
make modules_install runs depmod with those parameters anyway.

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

small fix in 2.4.0-test10

[linuxx]

The version of udf in this kernel version has a bug in the access at the end of the 
device (usually used in DVDs) the patch is currently in new versions of
udf 0.9.2 and 0.9.2.1 from linux-udf.sourceforge.net.  bye.

-- 
 Luis Toro Teijeiro
AÑO 3021 de la era del pinguino :-) tux rules.
ICQ : 42466380
pasate por http://www.gulic.org  y veras Canarias y los linuxeros
http://jaya.dyndns.org  --pagina personal
Firma gnupg disponible en http://jaya.dyndns.org/linuxx/gnupg/
GnupgFingerprint: 8F06 3E9A F610 89BF 0B09  3DEB 0C7E 9AE1 6CE0 B251 
  Windows Where do you want to go today?
  MacOS   Where do you want to be tomorrow?
  Linux   Are you coming, or what?




 PGP signature

Re: scsi-cdrom lockup and ide-scsi problem (both EFS related)

[Jens Axboe]

On Wed, Nov 01 2000, Alan Cox wrote:
> > It's untested behaviour at this point, all bets are off. It
> > hasn't oopses here though...
> 
> Not just CD either. SCSI disk has the same problem in 2.4 but not 2.2

Disk too? I guess Eric broke more than he bargained for :)

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

Re: scsi-cdrom lockup and ide-scsi problem (both EFS related)

[Alan Cox]

> > > correctly with SCSI CD-ROM (it's even on Ted's list).
> > 
> > doesn't work is one thing.. but an instant lockup? that's a bit
> > unfriendly. :)
> 
> It's untested behaviour at this point, all bets are off. It
> hasn't oopses here though...

Not just CD either. SCSI disk has the same problem in 2.4 but not 2.2

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

Re: 2.2.18Pre Lan Performance Rocks!

[Horst von Brand]

Jesse Pollard <[EMAIL PROTECTED]> said:

[...]

> Also pay attention to the security aspects of a true "zero copy" TCP stack.
> It means that SOMETIMES a user buffer will recieve data that is destined
> for a different process.

Why? AFAIKS, given proper handling of the issues involved, this can't
happen (sure can get tricky, but can be done in principle. Or am I
off-base?)
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux-2.4.0-test10

[Paul Jakma]

On Tue, 31 Oct 2000, Alan Cox wrote:

> Less Critical:
>   Does autofs4 work yet

has been apparently working fine for me for a while on 2.4test and
2.2+patch. (while==not noticed any major problems in last couple of
months)

> Alan

regards,
-- 
Paul Jakma  [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
Save energy:  Drive a smaller shell.

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

Re: 2.2.18Pre Lan Performance Rocks!

[Andrea Arcangeli]

> Larry McVoy wrote:
>> Are there processes with virtual memory?
On Tue, Oct 31, 2000 at 03:38:00PM -0700, Jeff V. Merkey wrote:
> Yes.

If that stack switch is your context switch then you share the same VM for all
tasks. I think the above answer "yes" just means you have pagetables so you can
swap, but you _must_ miss memory protection across different processes.  That
also mean any program can corrupt the memory of all the other programs.  Even
on the Palm that's a showstopper limitation (and on the Palm that's an hardware
limitation, not a software deficiency of PalmOS).

That will never happen in linux, nor in windows, nor internally to kde2. It
happens in uclinux to deal with hardware without MMU. And infact the agenda
uses mips with memory protection even on a organizer with obvious advantages.

Just think kde2 could have all the kde app sharing the same VM skipping all the
tlb flushes by simply using clone instead of fork. Guess why they aren't doing
that? And even if they would do that, the first bug would _only_ destabilize
kde, so kill it and restart and everything else will keep running fine (you
don't even need to kill X). With your ring 0 linux _everything_ will crash, not
just kde.

And on sane architectures like alpha you don't even need to flush the TLB
during "real" context switching so all your worry to share the same VM for
everything is almost irrelevant there since it happens all the time anyways
(until you overflow the available ASN bits that takes a lots of forks to
happen).

So IMHO for you it's much saner to move all your performance critical code into
kernel space (that will be just stability-risky enough as khttpd and tux are).
In 2.4.x that will avoid all the cr3 reloads and that will be enough as what
you really care during fileserving are the copies that you must avoid.

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

Re: scsi-cdrom lockup and ide-scsi problem (both EFS related)

[Jens Axboe]

On Wed, Nov 01 2000, Paul Jakma wrote:
> > Known problem, blocksizes != 2kb does not currently work
> > correctly with SCSI CD-ROM (it's even on Ted's list).
> > 
> 
> doesn't work is one thing.. but an instant lockup? that's a bit
> unfriendly. :)

It's untested behaviour at this point, all bets are off. It
hasn't oopses here though...

> > Same deal, SCSI CD-ROM driver. As you noted, pure ATAPI drive will
> > work just fine.
> > 
> 
> so once the scsi cdrom is fixed then ide-scsi should work too?

Yup

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

RE: test10-pre7 (LINK ordering)

[Dunlap, Randy]

> > > With CONFIG_USB=y and all other USB modules built as
> > > modules (=m), linking usbdrv.o into the kernel image
> > > gives this:
> > 
> > > drivers/usb/usbdrv.o(.data+0x2f4): undefined reference to
> > 
> > Works for me here, .config attached.  Local changes, merge error, or
> > similar?  I don't have any local USB patches...
> 
> I agree.  My (rushed) bad.
> Didn't rm usb/*.o .
> 
> Thanks for catching me.  I'm pleased that there's
> no problem here.

Hi Jeff,

Did I speak too quickly again?

Can you successfully do 'depmod -ae' _before_
booting this kernel?

I still get lots of unresolved USB symbols in
all USB modules.

Is it valid to run depmod like this before
booting the kernel that has usbcore in-kernel?
depmod -ae works after I boot that kernel + usbcore.

~Randy

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

Re: scsi-cdrom lockup and ide-scsi problem (both EFS related)

[Paul Jakma]

On Tue, 31 Oct 2000, Jens Axboe wrote:

> Known problem, blocksizes != 2kb does not currently work
> correctly with SCSI CD-ROM (it's even on Ted's list).
> 

doesn't work is one thing.. but an instant lockup? that's a bit
unfriendly. :)

> Same deal, SCSI CD-ROM driver. As you noted, pure ATAPI drive will
> work just fine.
> 

so once the scsi cdrom is fixed then ide-scsi should work too?

> rmmod ide-scsi ; insmod ide-cd
> mount, etc
> rmmod ide-cd ; insmod ide-scsi
> burn
> 

didn't think this was possible. will try that. thanks.

> 

regards,
-- 
Paul Jakma  [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
The gent who wakes up and finds himself a success hasn't been asleep.

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

2.2.17 -- can't power-down on halt?

[Mike Oliver]

I have Linux RH 6.2 installed, Soyo motherboard, Athlon K7.
When using the kernel that came with the distro (2.2.14-5.0),
the "shutdown -h" commend worked correctly, causing the
computer to power down after exiting Linux.

But when I compiled myself a 2.2.17 kernel, it didn't
work anymore (it hung on halt).  So I turned on
CONFIG_APM_REAL_MODE_POWER_OFF, which is supposed to
fix some bugs.  But after that, while it no longer
hung, it *restarted* rather than powering down as
I wanted it to.

I find that the CONFIG_APM_REAL_MODE_POWER_OFF symbol
causes apm_power_off() to call
machine_real_restart(po_bios_call, sizeof(po_bios_call));
which certainly *looks* like it's trying to restart
the machine rather than powering down (line 641 of
apm.c, version 1.13).  What's the reason for
this?

When the symbol is not defined, apm_power_off() calls
(void) apm_set_power_state(APM_STATE_OFF);
which is the same call as in apm.c from the
2.2.14 kernel (version 1.9 of apm.c).  So
how come this causes a hang when I try
it in 2.2.17, but not in 2.2.14?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test10-pre7 (LINK ordering)

[Jeff Garzik]

Randy Dunlap wrote:
> With CONFIG_USB=y and all other USB modules built as
> modules (=m), linking usbdrv.o into the kernel image
> gives this:

> drivers/usb/usbdrv.o(.data+0x2f4): undefined reference to

Works for me here, .config attached.  Local changes, merge error, or
similar?  I don't have any local USB patches...

-- 
Jeff Garzik | "Mind if I drive?"  -Sam
Building 1024   | "Not if you don't mind me clawing at the
MandrakeSoft|  dash and shrieking like a cheerleader."
| -Max
 config.bz2

ISSUE: Locks up on boot with HPT370

[Christopher Thompson]

(using the bug report form.  if you wish to contact me, please 
do so off-list as I am not subscribed.)

1.  Locks up on boot with HPT370
2.  Using kernel 2.4.0-test10, my machine gets to the part of 
the bootup where it has detected drives and CD-ROM's on hda, 
hdc, hdd.  It then locks up, the floppy light is on and the 
keyboard is non-responsive.  Alt-SysRq-foo does nothing.  Have 
to hard-reset.  On 2.2.17 with the IDE backport, the kernel 
boots up fine, showing that it has found /dev/hde and continuing 
as usual.  Have not tested with anything before test9-pre-foo, 
just got this motherboard.
3.  HPT370, Highpoint, HPT366, IDE, boot
4.  2.4.0-test10
5.  No oops shown.  Machine just locks up hard.
6.  Reproducable 100% of the time when booting my machine with 
2.4.0-test10.  Please note that the HPT366 is, of course, 
compiled in and is not a module.
7.1 Debian Potato install with the 2.4.0-test10 kernel from 
ftp.kernel.org
7.2 $ cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 4
model name  : AMD Athlon(tm) Processor
stepping: 2
cpu MHz : 900.059
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr 6 mce cx8 sep mtrr pge 
14 cmov pat 17 psn mmxext mmx fxsr 3dnowext 3dnow
bogomips: 1795.69

Note that this is with an Abit KT7-RAID motherboard.  The hard 
drives are NOT in raid mode.
7.3  No module information to show as the kernel does not boot.
7.4  No SCSI drives installed, nothing compiled in.
7.5  Works perfectly fine with kernel 2.2.17, Win98SE, Win2k.
X.  Have found no workaround.  Cannot tell if the problem is in 
the HPT366/370 support or is caused elsewhere.  Please contact 
me if you have any suggestions or have a patch you wish me to 
try out.  Please note that on Thursday and Friday, I will be 
away from the Internet.
I realise that the highpoint controllers are somewhat 
problematic but note that this system works fine in 2.2.17.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

PCMCIA-USB (non-cardbus). Any support pending?

[Ian Stirling]

Along with many others, I have an older laptop.
I also notice the large number of USB things released, some of which I'd like
to connect to it.
Is there hardware around? Is anyone working on drivers?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

RE: USB Printer, in 2.4.0-test9

[Dunlap, Randy]

Hi,

Can you try the USB printer driver in 2.4.0-test10 and
let me know if it works for you?  [It works for me.]

~Randy_
|randy.dunlap_at_intel.com503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
---

> Strange things here.
> 
> I'm testing out 2.4.0-test9 kernel with USB, (reiserfs built in, but,
> hopefully this has nothing to do with it).
> 
> Hardware is a 440FX Dual PPro200/Natoma + 82371SB PIIX3/USB.
> Printer: HP DeskJet 880C USB/Parallel
> Mouse: Microsoft Intellimouse with Intellieye USB
> Other stuff: Belkin "Macintosh" USB hub
> 
> Symptoms:
> 
> USB Mouse appears to work totally fine.
> 
> USB Printer will print a few bytes, and suddenly print garbage
> (bitmap/pcl). I tried printing out some plain text and it's 
> MANGLING bits
> - corrupting random bytes of data.  The general structure of bytes are
> still there, but the resultant printout is gibberish.  
> (source print file
> is a text file printed via "cat file >/dev/usblp0" (which is device
> 180,0))
> 
> I get a bunch of form feeds too but it continues to print a 
> few characters
> fine and some that are totally wrong.  It looks like it's 
> corrupting about
> 5% of the characters, including some high bit 7 characters.
> 
> Any ideas what's going on, and is this repeatable by anyone else?  Bad
> hardware?  This SMP box only supports one form of the MPS, and I'm not
> sure how to tell the difference... I also tried using the 
> printer w/o the hub, and same results...

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

Re: 2.2.18Pre Lan Performance Rocks!

[Michael H. Warfield]

On Wed, Nov 01, 2000 at 12:07:50AM +, Alan Cox wrote:
> > users must be fairly recent (4.x and about - 3.x has come into discussion
> > but doesn't count here) customers.  Obviously, they are big and SIGNIFICANT
> > customers.  Do we know that Linux can't handle the load, though, or is
> > this just more supposition based on statistics?

> On the same hardware netware 3 at least tended to beat us flat, but then it
> wasnt a general purpose OS. I think what Jeff is trying to build is basically
> a box that runs netware in the netware 3/4 style - ie fast and a little 
> unprotected with a standard linux application space protected mode on top of it
> - its an interesting concept.

Alan, I'll grant that what Jeff is attempting to do is laudable.
It's just that I have experience with Netware 3.x and 4.x in the field
(Ok...  More 3.x than 4.x) and I have more than passing familiarity with
5.x security problems.  I know he wants to achieve some of the good things
that Novell managed.  I know, from first hand experience, what cost some
of those come at.  Can he achieve the goal of matching the good while
avoiding the bad?  I hope so.  He won't do it by promoting what he
perceives as the advantages of Novell over Linux without at least some
passing acknowledgement of the failures of Novell, the disadvantages, and
the costs.  I think his goals are good and his head is in the right spot,
I just don't want to see history repeat itself.  He has my best wishes,
since both he and Linux will benefit.

My $0.02.

Mike
-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

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

Re: 2.2.18Pre Lan Performance Rocks!

[Alan Cox]

> users must be fairly recent (4.x and about - 3.x has come into discussion
> but doesn't count here) customers.  Obviously, they are big and SIGNIFICANT
> customers.  Do we know that Linux can't handle the load, though, or is
> this just more supposition based on statistics?

On the same hardware netware 3 at least tended to beat us flat, but then it
wasnt a general purpose OS. I think what Jeff is trying to build is basically
a box that runs netware in the netware 3/4 style - ie fast and a little 
unprotected with a standard linux application space protected mode on top of it
- its an interesting concept.

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

Re: test10-pre7 (LINK ordering)

[Randy Dunlap]

Linus Torvalds wrote:
> 
[snip]
> 
> That was going to be my next question if somebody actually said "sure".
> 
> The question was rhetorical, since the way LINK_FIRST is implemented
> means
> that it has all the same problems that $(obj-y) has, and is hard to get
> right in the generic case (but you can get it trivially right for the
> subset case, like for USB).


So now we have something in 2.4.0-test10, but there's
still a problem.  Help is appreciated^W wanted. !!!

With CONFIG_USB=y and all other USB modules built as
modules (=m), linking usbdrv.o into the kernel image
gives this:

ld -m elf_i386 -T /work/linsrc/240-test10/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/parport/parport.a 
drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/cdrom.a
drivers/sound/sounddrivers.o drivers/pci/pci.a drivers/video/video.o
drivers/usb/usbdrv.o drivers/input/inputdrv.o drivers/i2c/i2c.o \
net/network.o \
/work/linsrc/240-test10/arch/i386/lib/lib.a
/work/linsrc/240-test10/lib/lib.a
/work/linsrc/240-test10/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
drivers/usb/usbdrv.o(.data+0x2f4): undefined reference to
`__this_module'
make: *** [vmlinux] Error 1
[rdunlap@dragon linux]$ 


I believe that this is caused by drivers/usb/inode.c:

static DECLARE_FSTYPE(usbdevice_fs_type, "usbdevfs",
usbdevfs_read_super, 0);

in which this macro uses "THIS_MODULE".  inode.c already #includes
module.h.  What else does it need to do?
(inode.c is part of the usbcore in this case, so it shouldn't be
compiled with -DMODULE.)

Help ?!?

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

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Alan Cox wrote:
> 
> > One more optimization it has.  NetWare never "calls" functions in the
> > kernel.  There's a template of register assignments in between kernel
> > modules that's very strict (esi contains a WTD head, edi has the target
> > thread, etc.) and all function calls are jumps in a linear space.
> 
> What if I jump to an invalid address - does it crash ?

The jumps are all to defined labels in the code, so there's never one
that's invalid.  The only exception are the jump tables in the MSM and
TSM lan modules, and yes it does crash is a bad driver gets loaded, but
that's the same as Linux.  NetWare avoids using jump tables since they
cause an AGI to get generated, which will interlock the processor
pipelines.  If you load an address on Intel, then immediately attempt to
use it, the processor will generate and Address Generation Interlock
(AGI) that will interlock the piplines so the request can be serviced
immediately.  This cost 2 clocks per address jump used, plus it shuts
down the paralellism in the piplines.

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

Re: 2.2.18Pre Lan Performance Rocks!

[Richard B. Johnson]

On Tue, 31 Oct 2000, Jeff V. Merkey wrote:

> 
> A "context" is usually assued to be a "stack".  The simplest of all
> context switches 
> is:
> 
>movx, esp
>movesp, y
> 
> A context switch can be as short as two instructions, or as big as a TSS
> with CR3 hardware switching,
> 
> i.e.  
> 
>ltrax
>jmptask_gate
> 
> (500 clocks later)
> 
>ts->eip gets exec'd
> 
> you can also have a context switch that does an int X where X is a gate
> or TSS.
> 
> you can also have a context switch (like linux) that does
> 
> movx, esp
> movesp, y
> movz, CR3
> movCR3, w
> 
> etc.
> 
> In NetWare, a context switch is an in-line assembly language macro that
> is 2 instructions long for a stack switch and 4 instructions for a CR3
> reload -- this is a lot shorter than Linux.
> Only EBX, EBP, ESI, and EDI are saved and this is never done in the
> kernel, but is a natural
> affect of the Watcom C compiler.  There's also strict rules about
> register assignments that re enforced between assembler modules in
> NetWare to reduce the overhead of a context switch.  The code path is
> very complex in NetWare, and priorities and all this stuff exists, but
> these code paths are segragated so these types of checks only happen
> once in a while and check a pre-calc'd "scoreboard" that is read only
> across processors and updated and recal'd by a timer every 18 ticks.
> 
> Jeff
> 
>

I have this feeling that this is an April Fools joke. Unfortunately
it's Halloween.

One could create a 'kernel' that does:
for(;;)
{
  proc0();
  proc1();
  proc2();
  proc3();
  etc();
}

... and loop forever. All 'tasks' would just be procedures and no
context-switching would even be necessary. This is how some network
file-servers worked in the past (Vines comes to mind). Since all
possible 'tasks' are known at compile-time, there isn't even any
need for memory protection because every task cooperates and doesn't
destroy anything that it doesn't own.

The only time you need to save anything is for interrupt handlers.
This was some simple push/pops of only the registers actually
used in the ISR.

Now, the above example may seem absurd, however it's not. Inside
each of the proc()'s is a global state-variable that allows the
code to start executing at the place it left off the last time
through. If the code was written in 'C' it would be a 'switch'
statement. The state-variable for each of the procedures is global
and can be changed in an interrupt-service-routine. This allows
interrupts to change the state of the state-machines.

This kind of 'kernel' is very fast and very effective for things
like file-servers and routers, things that do the same stuff over
and over again.

However, there techniques are not useful with a kernel that
has an unknown number of tasks that execute 'programs' that are
not known to the kernel at compile-time, such as a desk-top
operating system.

These operating systems require context-switching. This requires
that every register that a user could possibly alter, be saved
and restored. It also requires that the state of any hardware
that a user could be using, also be save and restored. This
cannot be done in 2 instructions as stated. Further, this saving
and restoring cannot be a side-effect of a particular compiler, as
stated.

Cheers,
Dick Johnson

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

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


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

Re: 2.2.18Pre Lan Performance Rocks!

[Michael H. Warfield]

On Tue, Oct 31, 2000 at 04:20:30PM -0700, Jeff V. Merkey wrote:

> Nathan Paul Simons wrote:

> > On Tue, Oct 31, 2000 at 03:38:00PM -0700, Jeff V. Merkey wrote:
> > > It's makes more money in a week than Linux has ever made.

> > The same could be said about Windows; that doesn't make it a
> > technically superior solution.
> > Speaking of Windows, a lot of your arguments are starting to sound
> > more and more like arguments made a while back by a certain OS vendor from
> > Seattle . . .

> Not really.  We ship Linux.  I just want a Linux NetWare customers won't
> laugh at when they try to put over 1000 people on it (which the NetWare
> server was already handling we ate trying to replace).

Oh!  That's funny!

Back in "the bad old days" Novell got laughed right off several
campuses for this very reason.  Why?  Because Netware, at the time, could
not handle more than 256 users on a given server.  One admin I knew
here at Georgia Tech reported on the expression on the face of the Novell
presales support person when he was informed that the average public
server had several thousand accounts.

Netware customers that are worried about more than a few hundred
users must be fairly recent (4.x and about - 3.x has come into discussion
but doesn't count here) customers.  Obviously, they are big and SIGNIFICANT
customers.  Do we know that Linux can't handle the load, though, or is
this just more supposition based on statistics?

> Jeff

> > 
> > Wish not to seem, but to be, the best.
> > -- Aeschylus
> > 
> > --
> > Nathan Paul Simons, Junior Software Engineer for FSMLabs
> > http://www.fsmlabs.com/

Mike
-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

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

Re: 2.2.18Pre Lan Performance Rocks!

[Ingo Molnar]

On Tue, 31 Oct 2000, Richard B. Johnson wrote:

> However, these techniques are not useful with a kernel that has an
> unknown number of tasks that execute 'programs' that are not known to
> the kernel at compile-time, such as a desk-top operating system.

yep, exactly. It simply optimizes the wrong thing and restricts
architectural flexibility. It is very easy to optimize by making
a system more specific. (this is fact is a more or less automatic
engineering work) The real optimizations are the ones that do not
take away from the generic nature of the system.

Ingo

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

Re: 2.2.18Pre Lan Performance Rocks!

[Davide Libenzi]

On Wed, 01 Nov 2000, Jeff V. Merkey wrote:
> 
> moveax, addr
> mov[addr], ebx
> 

Probably You mean this :

mov r/imm, %eax
mov (%eax), %ebx


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

Re: 2.2.18Pre Lan Performance Rocks!

[David Weinehall]

On Wed, Nov 01, 2000 at 01:21:03AM +0200, Matti Aarnio wrote:
> On Tue, Oct 31, 2000 at 01:36:32PM -0800, Paul Menage wrote:
> > On Tue, 31 Oct 2000, Rik van Riel wrote:
> > >Ummm, last I looked Linux held the Specweb99 record;
> > >by a wide margin...
> > 
> > ... but since then IBM/Zeus appear to have taken the lead:
> > 
> > http://www.spec.org/osg/web99/results/res2000q3/
> > 
> > But they were using a somewhat beefier machine - has anyone got Tux
> > SpecWeb99 figures for a 12 CPU, 64 GB, 12 NIC system?
> 
>   Good grief, what monster hardware...
> 
>   Those are (of course) system results which give some impression of
>   how much users can pull out of the box.
> 
>   Trying to make them a bit more comparable, scaling the number with
>   the number of processors:
> 
>   Zeus 12x600MHz IBM RS64-III 7288 SpecWEB99  ~ 607 SpecWEB99/CPU
>   Zeus 4x375MHz IBM Power3-II 2175 SpecWEB99  ~ 544 SpecWEB99/CPU
>   TUX 1.0  8x700MHz Pentium-III-Xeon  6387 SpecWEB99  ~ 798 SpecWeb99/CPU
>   IIS  2x800MHz Pentium-III-Xeon  1060 SpecWEB99  ~ 530 SpecWEB99/CPU
>   IIS  1x700MHz Pentium-III-Xeon   971 SpecWEB99  = 971 SpecWEB99/CPU
> 
>   Ok, more workers to do the thing, but each can achieve a bit less in
>   the IBM/Zeus case than TUX 1.0.   The smaller IBM/Zeus test case with
>   older and slower processors yields almost as good results per CPU as
>   the big one.   CPU clock speed increase has been lost into inter-CPU
>   collisions ?  (that is, bad scaling)
> 
>   The IIS results are also interesting in their own.  Single-CPU IIS
>   yields impressive PER CPU result, but adding second CPU is apparently
>   quite useless excercise.   Hmm... Can't be..  As if that DUAL CPU
>   result is actually run in single-CPU mode.  The difference can
>   directly be explained by the clock rate difference..
>   (Surely the runners of that test *can't* make such an elementary
>mistake!)
> 
> 
>   To be able to compare apples and apples, I would like to see single,
>   and dual CPU SpecWEB99 results with TUX.  Then that apparent 20%
>   better "per CPU result" of the single-CPU IIS could not be explained
>   away with SMP inter-CPU communication overhead/collisions.

You mean like:

TUX 1.0 1x667MHz Pentium-IIIEB  1270 SpecWeb99
TUX 1.0 2x800MHz Pentium-III-Xeon   2200 SpecWeb99
TUX 1.0 4x700MHz Pentium-III-Xeon   4200 SpecWeb99

(Check out quarter 2 instead of q3)

Truly impressive figures imho.


/David Weinehall
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Roger Larsson]

"Jeff V. Merkey" wrote:
> 
> David/Alan,
> 
> Andre Hedrick is now the CTO of TRG and Chief Scientist over Linux
> Development.  After talking
> to him, we are going to do our own ring 0 2.4 and 2.2.x code bases for
> the MANOS merge.
> the uClinux is interesting, but I agree is limited.
> 

Jeff,

What would be missed out in this approach:
* Use Montavista "fully" preemtible kernel.
* Using Kernel threads for all services (File, Print, Web, etc.).

/RogerL

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

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Nathan Paul Simons wrote:
> 
> On Tue, Oct 31, 2000 at 03:38:00PM -0700, Jeff V. Merkey wrote:
> > It's makes more money in a week than Linux has ever made.
> 
> The same could be said about Windows; that doesn't make it a
> technically superior solution.
> Speaking of Windows, a lot of your arguments are starting to sound
> more and more like arguments made a while back by a certain OS vendor from
> Seattle . . .

Not really.  We ship Linux.  I just want a Linux NetWare customers won't
laugh at when they try to put over 1000 people on it (which the NetWare
server was already handling we ate trying to replace).

Jeff

> 
> Wish not to seem, but to be, the best.
> -- Aeschylus
> 
> --
> Nathan Paul Simons, Junior Software Engineer for FSMLabs
> http://www.fsmlabs.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Ingo Molnar wrote:
> 
> On Tue, 31 Oct 2000, Jeff V. Merkey wrote:
> 
> > > One could create a 'kernel' that does:
> > > for(;;)
> > > {
> > >   proc0();
> > >   proc1();
> > >   proc2();
> > >   proc3();
> > >   etc();
> > > }
> >
> > would be coded like this (no C compiler):
> >
> > proc0:
> >
> > proc1:
> >
> > proc2:
> >
> > proc3:
> >
> > etc:
> >
> > label:
> >  jmp  proc0
> 
> oh, and what happens if it turns out that some other place wants to call
> proc3 as well? Recode the assembly - cool! Not.

They would load the registers to the proper values and jump to it.  The
return address would be stored in the ESI register, and when the routie
completed, it would do

jmp   esi  

to return, with 0 stack usage.

> 
> > I just avoided 5 x 20 bytes of pushes and pops on the stack ad optimized
> > for a simple fall through case.
> 
> FYI, GCC does not generate 5 x 20 bytes of pushes and pops. In fact in the
> above specific case it will not generate a single push (automatically -
> you dont have to worry about it).

If the compiler were set to optimize.  

Jeff

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

Re: 2.2.18Pre Lan Performance Rocks!

[Ingo Molnar]

On Tue, 31 Oct 2000, Jeff V. Merkey wrote:

> > One could create a 'kernel' that does:
> > for(;;)
> > {
> >   proc0();
> >   proc1();
> >   proc2();
> >   proc3();
> >   etc();
> > }
> 
> would be coded like this (no C compiler):
> 
> proc0:
> 
> proc1:
> 
> proc2:
> 
> proc3:
> 
> etc:
> 
> label:
>  jmp  proc0

oh, and what happens if it turns out that some other place wants to call
proc3 as well? Recode the assembly - cool! Not.

> I just avoided 5 x 20 bytes of pushes and pops on the stack ad optimized
> for a simple fall through case.  

FYI, GCC does not generate 5 x 20 bytes of pushes and pops. In fact in the
above specific case it will not generate a single push (automatically -
you dont have to worry about it).

Ingo

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

Re: 2.2.18Pre Lan Performance Rocks!

[Matti Aarnio]

On Tue, Oct 31, 2000 at 01:36:32PM -0800, Paul Menage wrote:
> On Tue, 31 Oct 2000, Rik van Riel wrote:
> >Ummm, last I looked Linux held the Specweb99 record;
> >by a wide margin...
> 
> ... but since then IBM/Zeus appear to have taken the lead:
> 
> http://www.spec.org/osg/web99/results/res2000q3/
> 
> But they were using a somewhat beefier machine - has anyone got Tux
> SpecWeb99 figures for a 12 CPU, 64 GB, 12 NIC system?

  Good grief, what monster hardware...

  Those are (of course) system results which give some impression of
  how much users can pull out of the box.

  Trying to make them a bit more comparable, scaling the number with
  the number of processors:

  Zeus 12x600MHz IBM RS64-III 7288 SpecWEB99  ~ 607 SpecWEB99/CPU
  Zeus 4x375MHz IBM Power3-II 2175 SpecWEB99  ~ 544 SpecWEB99/CPU
  TUX 1.0  8x700MHz Pentium-III-Xeon  6387 SpecWEB99  ~ 798 SpecWeb99/CPU
  IIS  2x800MHz Pentium-III-Xeon  1060 SpecWEB99  ~ 530 SpecWEB99/CPU
  IIS  1x700MHz Pentium-III-Xeon   971 SpecWEB99  = 971 SpecWEB99/CPU

  Ok, more workers to do the thing, but each can achieve a bit less in
  the IBM/Zeus case than TUX 1.0.   The smaller IBM/Zeus test case with
  older and slower processors yields almost as good results per CPU as
  the big one.   CPU clock speed increase has been lost into inter-CPU
  collisions ?  (that is, bad scaling)

  The IIS results are also interesting in their own.  Single-CPU IIS
  yields impressive PER CPU result, but adding second CPU is apparently
  quite useless excercise.   Hmm... Can't be..  As if that DUAL CPU
  result is actually run in single-CPU mode.  The difference can
  directly be explained by the clock rate difference..
  (Surely the runners of that test *can't* make such an elementary
   mistake!)


  To be able to compare apples and apples, I would like to see single,
  and dual CPU SpecWEB99 results with TUX.  Then that apparent 20%
  better "per CPU result" of the single-CPU IIS could not be explained
  away with SMP inter-CPU communication overhead/collisions.

> Paul

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

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Ingo Molnar wrote:
> 
> On Tue, 31 Oct 2000, Jeff V. Merkey wrote:
> 
> > [...] These types of optimizations are possible when people have
> > acccess to Intel Red Cover documents, [...]
> 
> optimizing away AGIs has been documented by public Intel PDFs for years:
> 
>  [...] Since the Pentium processor has two integer pipelines, a register
>  used as the base or index component of an effective address calculation
>  (in either pipe) causes an additional clock cycle if that register is the
>  destination of either instruction from the immediately preceding clock
>  cycle. This effect is known as Address Generation Interlock (AGI).
> 
> (ditto for the p6 core CPUs), and GCC (IIRC) tries to avoid AGI conflicts
> as much as possible. (and this kind of stuff belongs into the compiler)

Odd.  When I profile Linux with EMON, I see tons of them.  Anywhere code
does

moveax, addr
mov[addr], ebx

one will get generated.  Even something as simple as:

moveax, addr
inceax
deceax
mov[addr]. ebx

will avoid an AGI (since the other pipeline has now been allowed a few
clocks to fetch the address and load it).

Jeff



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

Re: 2.2.18Pre Lan Performance Rocks!

[Nathan Paul Simons]

On Tue, Oct 31, 2000 at 03:38:00PM -0700, Jeff V. Merkey wrote:
> It's makes more money in a week than Linux has ever made.  

The same could be said about Windows; that doesn't make it a
technically superior solution.
Speaking of Windows, a lot of your arguments are starting to sound
more and more like arguments made a while back by a certain OS vendor from
Seattle . . . 

Wish not to seem, but to be, the best.
-- Aeschylus

-- 
Nathan Paul Simons, Junior Software Engineer for FSMLabs
http://www.fsmlabs.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

"Richard B. Johnson" wrote:
> 

Dick,

In NetWare this:

> 
> One could create a 'kernel' that does:
> for(;;)
> {
>   proc0();
>   proc1();
>   proc2();
>   proc3();
>   etc();
> }

would be coded like this (no C compiler):

proc0:

proc1:

proc2:

proc3:

etc:

label:
 jmp  proc0


I just avoided 5 x 20 bytes of pushes and pops on the stack ad optimized
for a simple fall through case.  

:-)

Jeff

> 
> Cheers,
> Dick Johnson
> 
> Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
> 
> "Memory is like gasoline. You use it up when you are running. Of
> course you get it all back when you reboot..."; Actual explanation
> obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Ingo Molnar]

On Tue, 31 Oct 2000, Jeff V. Merkey wrote:

> [...] These types of optimizations are possible when people have
> acccess to Intel Red Cover documents, [...]

optimizing away AGIs has been documented by public Intel PDFs for years:

 [...] Since the Pentium processor has two integer pipelines, a register
 used as the base or index component of an effective address calculation
 (in either pipe) causes an additional clock cycle if that register is the
 destination of either instruction from the immediately preceding clock
 cycle. This effect is known as Address Generation Interlock (AGI).

(ditto for the p6 core CPUs), and GCC (IIRC) tries to avoid AGI conflicts
as much as possible. (and this kind of stuff belongs into the compiler)

Ingo

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

Re: 2.2.18Pre Lan Performance Rocks!

[David Lang]

I don't doubt it. a port of netware that can run linux apps would be very
useful to people who want to run netware, but this is not the same thing
as what it has sounded like you were working on.

David Lang

 On Tue, 31 Oct 2000, Jeff
V. Merkey wrote:

> Date: Tue, 31 Oct 2000 15:57:23 -0700
> From: Jeff V. Merkey <[EMAIL PROTECTED]>
> To: David Lang <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: 2.2.18Pre Lan Performance Rocks!
> 
> 
> 
> David Lang wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > 
> > Jeff, one other thing. Linux is not x86 hand-crafted assembler, it's
> > capable of running on many platforms. are you planning on giving up this
> > capability or hand crafting the kernel for each chip?
> > 
> > Linux on x86 is nice (and I do use it a lot) but one of the things that
> > makes it so useful is that when you do outgrow what youcan do on a x86
> > platform you cna move to a more powerful platform without having to change
> > to a different OS.
> 
> How about a NetWare like NOS with all the application support of Linux? 
> I think a lot of people will love it.  Novell's largest customers have
> told me they want to see it, and would deploy it.  I do believe there's
> a market for such a beast.  A very lucrative one...
> 
> Jeff
> 
> > 
> >  David Lang
> > 
> > On Tue, 31 Oct 2000,
> > Jeff V. Merkey wrote:
> > 
> > > Date: Tue, 31 Oct 2000 15:45:45 -0700
> > > From: Jeff V. Merkey <[EMAIL PROTECTED]>
> > > To: Andi Kleen <[EMAIL PROTECTED]>, [EMAIL PROTECTED], Pavel Machek <[EMAIL PROTECTED]>,
> > >  [EMAIL PROTECTED]
> > > Subject: Re: 2.2.18Pre Lan Performance Rocks!
> > >
> > >
> > >
> > > One more optimization it has.  NetWare never "calls" functions in the
> > > kernel.  There's a template of register assignments in between kernel
> > > modules that's very strict (esi contains a WTD head, edi has the target
> > > thread, etc.) and all function calls are jumps in a linear space.
> > > layout of all functions are 16 bytes aligned for speed, and all
> > > arguments in kernel are passed via registers.  It's a level of
> > > optimization no C compiler does -- all of it was done by hand, and most
> > > function s in fast paths are layed out in 512 byte chunks to increases
> > > speed.  Stack memory activity in the NetWare kernel is almost
> > > non-existent in almost all of the "fast paths"
> > >
> > > Jeff
> > >
> > > "Jeff V. Merkey" wrote:
> > > >
> > > > A "context" is usually assued to be a "stack".  The simplest of all
> > > > context switches
> > > > is:
> > > >
> > > >movx, esp
> > > >movesp, y
> > > >
> > > > A context switch can be as short as two instructions, or as big as a TSS
> > > > with CR3 hardware switching,
> > > >
> > > > i.e.
> > > >
> > > >ltrax
> > > >jmptask_gate
> > > >
> > > > (500 clocks later)
> > > >
> > > >ts->eip gets exec'd
> > > >
> > > > you can also have a context switch that does an int X where X is a gate
> > > > or TSS.
> > > >
> > > > you can also have a context switch (like linux) that does
> > > >
> > > > movx, esp
> > > > movesp, y
> > > > movz, CR3
> > > > movCR3, w
> > > >
> > > > etc.
> > > >
> > > > In NetWare, a context switch is an in-line assembly language macro that
> > > > is 2 instructions long for a stack switch and 4 instructions for a CR3
> > > > reload -- this is a lot shorter than Linux.
> > > > Only EBX, EBP, ESI, and EDI are saved and this is never done in the
> > > > kernel, but is a natural
> > > > affect of the Watcom C compiler.  There's also strict rules about
> > > > register assignments that re enforced between assembler modules in
> > > > NetWare to reduce the overhead of a context switch.  The code path is
> > > > very complex in NetWare, and priorities and all this stuff exists, but
> > > > these code paths are segragated so these types of checks only happen
> > > > once in a while and check a pre-calc'd "scoreboard" that is read only
> > > > across processors and updated and recal'd by a timer every 18 ticks.
> > > >
> > > > Jeff
> > > >
> > > >
> > > >
> > > > Andi Kleen wrote:
> > > > >
> > > > > On Tue, Oct 31, 2000 at 02:52:11PM -0700, Jeff V. Merkey wrote:
> > > > > > The numbers don't lie.  You know where the code is.  You notice that
> > > > > > there is a version of
> > > > > > the kernel hand coded in assembly language.  You'l also noticed that
> > > > > > it's SMP and takes ZERO LOCKS during context switching, in fact, most of
> > > > > > the design is completely lockless.
> > > > >
> > > > > I suspect most of the confusion in this thread comes because you seem to
> > > > > use a different definition of context switch than Ingo and others. Could
> > > > > you explain what you exactly mean with a context switch ?
> > > > >
> > > > > -Andi
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to [EMAIL PROTECTED]
> > > Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Alan Cox]

> One more optimization it has.  NetWare never "calls" functions in the
> kernel.  There's a template of register assignments in between kernel
> modules that's very strict (esi contains a WTD head, edi has the target
> thread, etc.) and all function calls are jumps in a linear space. 

What if I jump to an invalid address - does it crash ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Ingo Molnar wrote:
> 
> On Tue, 31 Oct 2000, Jeff V. Merkey wrote:
> 
> > One more optimization it has.  NetWare never "calls" functions in the
> > kernel.  There's a template of register assignments in between kernel
> > modules that's very strict (esi contains a WTD head, edi has the target
> > thread, etc.) and all function calls are jumps in a linear space.
> 
> this might be a win on a i486, but is a loss with any branch predicting,
> large-pipeline CPUs (think Pentium IV), which are optimized for CALLs, not
> for JMP *EAX instructions. This is the problem with assembly optimizations
> that try to compete with the compiler's work: hand-made assembly can only
> get worse over time (stay constant in the best case), while compilers are
> known to improve slowly but steadily. Plus hand-made assembly is a huge
> stone tied to your legs if you try to swim to other architectures. Eg. we
> quite often make use of GCC's register-based function parameter passing
> optimization. We do use hand-made assembly in a number of cases in Linux
> as well, and double-check GCC's assembly output in critical code paths,
> but we try to not make it an essential facility.

It's hand optimized for all these cases to one of the highest degrees
that exist anywhere in the world.   Intel and Novell have been in bed
together for a very long time...

Jeff

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

Re: 2.2.18Pre Lan Performance Rocks!

[Ingo Molnar]

On Tue, 31 Oct 2000, Jeff V. Merkey wrote:

> It kicks Linux's but in LAN I/O scaling. [...]

brain cacheflush? Restart the same thread? Sorry i've got better things to
do.

Ingo

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

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Larry,

What's your mailing address and I'll send you out a legally licensed
copy of NetWare 3.12 and transfer the license to you then you can do the
comparison and see for yourself.

:-)

Jeff

Larry McVoy wrote:
> 
> On Tue, Oct 31, 2000 at 03:47:56PM -0700, Jeff V. Merkey wrote:
> > It kicks Linux's but in LAN I/O scaling.
> 
> Really?  So, since in a few messages back you claimed that it has a fully
> supported userland which implements all of P1003.1 as well as sockets,
> obviously, since it is a networking operating system, it should be the
> work of a few minutes to download LMbench, compile it, and come back with
> the lat_tcp performance numbers which "kicks Linux's but".  Please do so.
> --
> ---
> Larry McVoy  lm at bitmover.com   http://www.bitmover.com/lm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Michael H. Warfield]

On Tue, Oct 31, 2000 at 02:52:11PM -0700, Jeff V. Merkey wrote:

> Ingo Molnar wrote:
> > 
> > On Tue, 31 Oct 2000, Pavel Machek wrote:
> > 
> > > > Excuse me, 857,000,000 instructions executed and 460,000,000
> > > > context switches a second -- on a PII system at 350 Mhz. [...]
> > 
> > > That's more than one context switch per clock. I do not think so.
> > > Really go and check those numbers.
> > 
> > yep, you cannot have 460 million context switches on that system,
> > unless you have some Clintonesque definition for 'context switch' ;-)

> The numbers don't lie.  You know where the code is.  You notice that
> there is a version of
> the kernel hand coded in assembly language.  You'l also noticed that
> it's SMP and takes ZERO LOCKS during context switching, in fact, most of
> the design is completely lockless.

Ah ha ha ha  Sure they do!  You're just quoting statistics
measured under whatever conditions you imposed.

Numbers lying?  I think the famous line has been variously
attributed to either Mark Twain or Disraeli (don't know which really
coined the phrase) but it's been said that there are three kinds of
lies "Lies, Damn Lies, and Statistics".  Yes numbers do lie.  Sometimes
it's the GIGO law and sometimes its just the fact that if you abuse
statistics long enough they will tell you ANYTHING.  Sometimes it merely
the person manipulating^H^H^H^H^H^H^H^H^H^H^H^Hproviding the numbers.

BTW...  I was going to stay OUT of this rat trap, but since I'm
in for a dime, I might as well be in for a dolar...



Comparisons have been made between the performance of Linux with
early (3.x, 4.x) versions of Novell.  ANYONE who wants to compare Linux
with that bug ridden, unreliable swamp of headaches and security holes
(somewhere in my archives I have the virus launcher that BYPASSES the
3.x login program) should be beaten about the head with a good textbook
on reliable coding techniques.  Novell made its hayday by beating the
bejesus out of TCP/IP and others primarily by disabling checksumming,
memory protection, and other reliability techniques.  Yes, they got
better performance on low performace processors, but at what cost?  Now
we cover their performance with reliability and superior hardware.  I
remember one misguided soul wanting to run IPX over SLIP pleading for help
on the Novell mailing list years ago.  Let's see...  SLIP eliminates the
MAC layer checksumming and IPX eliminates the error checking on the next
layer up...  Yup...  There was a receipe for random acts of terrorism.
Now we have PPP (this was in the days BEFORE PPP) and you could do it.
IPX depended on the lower layers for data integrity and and SLIP depended
on the layer above it.  Oooo

Then we had the Novel 5.x NFS server that allow you to create
scripts that were SUID to root just by making them read only to the
Novell workstations (ok - that's not performace related - I just think
that security should be given a LITTLE thought).  I worked at an outfit
(Syntrex) that saw themselves as becoming the "K-Mart of Novell" and I
was told that Novell was the be all and end all of networking and there
was really no future in this antiquated TCP/IP stuff.  I was laid off and
given all sorts of nice neat little toys like an AT source license
because they saw no future in Unix or TCP/IP.  (Bitter - no...  I have
had my revenge in spades...  They had no clue what they gave away and
let slip through their fingers!  :-) )

Now, Novell has been dragged kicking and screaming into the TCP/IP
world, and Novell has been forced to add memory protection (at a performace
cost) to their servers, and the outfit that thought TCP/IP was history
is now history (Syntrex went Chapter 13 about 10 years ago), and I've had
the pleasure of slamming one particularly simple minded Novell rep (another
ex Syntrex inDUHvidual) with more than one security hole (the perl module
on the Novell web server was an absolute classic).

My point here is that packets per second don't mean jack shit if
you can't do it reliably and you can't do it securely.  Novell failed on
both of those counts and those are a contributing factor in their current
troubles.  They built their reputation on performance that was achieved at
the expense of reliability and security.  Now they have to play with the
big boys and all the nasty kiddies out there who don't play nice.

Performance is important.  Performance is desirable.  Efforts to
improve performance are worthwhile.  But performance should NEVER come at
the cost of security or reliability or integrity.  Comparisions with high
performance systems which lacked security, reliability, and data integrity
are suspect AT BEST.  We should NEVER give up the quest for better
performance but comparisons to an inferior operating system which can pump
out packets faster than us is not the threat some people would like it to be.



My regards and respects 

Re: 2.2.18Pre Lan Performance Rocks!

[Ingo Molnar]

On Tue, 31 Oct 2000, Jeff V. Merkey wrote:

> One more optimization it has.  NetWare never "calls" functions in the
> kernel.  There's a template of register assignments in between kernel
> modules that's very strict (esi contains a WTD head, edi has the target
> thread, etc.) and all function calls are jumps in a linear space. 

this might be a win on a i486, but is a loss with any branch predicting,
large-pipeline CPUs (think Pentium IV), which are optimized for CALLs, not
for JMP *EAX instructions. This is the problem with assembly optimizations
that try to compete with the compiler's work: hand-made assembly can only
get worse over time (stay constant in the best case), while compilers are
known to improve slowly but steadily. Plus hand-made assembly is a huge
stone tied to your legs if you try to swim to other architectures. Eg. we
quite often make use of GCC's register-based function parameter passing
optimization. We do use hand-made assembly in a number of cases in Linux
as well, and double-check GCC's assembly output in critical code paths,
but we try to not make it an essential facility.

Ingo

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

Re: 2.2.18Pre Lan Performance Rocks!

[David Lang]

-BEGIN PGP SIGNED MESSAGE-

Jeff, one other thing. Linux is not x86 hand-crafted assembler, it's
capable of running on many platforms. are you planning on giving up this 
capability or hand crafting the kernel for each chip?

Linux on x86 is nice (and I do use it a lot) but one of the things that
makes it so useful is that when you do outgrow what youcan do on a x86
platform you cna move to a more powerful platform without having to change
to a different OS.

 David Lang

On Tue, 31 Oct 2000,
Jeff V. Merkey wrote:

> Date: Tue, 31 Oct 2000 15:45:45 -0700
> From: Jeff V. Merkey <[EMAIL PROTECTED]>
> To: Andi Kleen <[EMAIL PROTECTED]>, [EMAIL PROTECTED], Pavel Machek <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> Subject: Re: 2.2.18Pre Lan Performance Rocks!
> 
> 
> 
> One more optimization it has.  NetWare never "calls" functions in the
> kernel.  There's a template of register assignments in between kernel
> modules that's very strict (esi contains a WTD head, edi has the target
> thread, etc.) and all function calls are jumps in a linear space. 
> layout of all functions are 16 bytes aligned for speed, and all
> arguments in kernel are passed via registers.  It's a level of
> optimization no C compiler does -- all of it was done by hand, and most
> function s in fast paths are layed out in 512 byte chunks to increases
> speed.  Stack memory activity in the NetWare kernel is almost
> non-existent in almost all of the "fast paths"
> 
> Jeff
> 
> "Jeff V. Merkey" wrote:
> > 
> > A "context" is usually assued to be a "stack".  The simplest of all
> > context switches
> > is:
> > 
> >movx, esp
> >movesp, y
> > 
> > A context switch can be as short as two instructions, or as big as a TSS
> > with CR3 hardware switching,
> > 
> > i.e.
> > 
> >ltrax
> >jmptask_gate
> > 
> > (500 clocks later)
> > 
> >ts->eip gets exec'd
> > 
> > you can also have a context switch that does an int X where X is a gate
> > or TSS.
> > 
> > you can also have a context switch (like linux) that does
> > 
> > movx, esp
> > movesp, y
> > movz, CR3
> > movCR3, w
> > 
> > etc.
> > 
> > In NetWare, a context switch is an in-line assembly language macro that
> > is 2 instructions long for a stack switch and 4 instructions for a CR3
> > reload -- this is a lot shorter than Linux.
> > Only EBX, EBP, ESI, and EDI are saved and this is never done in the
> > kernel, but is a natural
> > affect of the Watcom C compiler.  There's also strict rules about
> > register assignments that re enforced between assembler modules in
> > NetWare to reduce the overhead of a context switch.  The code path is
> > very complex in NetWare, and priorities and all this stuff exists, but
> > these code paths are segragated so these types of checks only happen
> > once in a while and check a pre-calc'd "scoreboard" that is read only
> > across processors and updated and recal'd by a timer every 18 ticks.
> > 
> > Jeff
> > 
> > 
> > 
> > Andi Kleen wrote:
> > >
> > > On Tue, Oct 31, 2000 at 02:52:11PM -0700, Jeff V. Merkey wrote:
> > > > The numbers don't lie.  You know where the code is.  You notice that
> > > > there is a version of
> > > > the kernel hand coded in assembly language.  You'l also noticed that
> > > > it's SMP and takes ZERO LOCKS during context switching, in fact, most of
> > > > the design is completely lockless.
> > >
> > > I suspect most of the confusion in this thread comes because you seem to
> > > use a different definition of context switch than Ingo and others. Could
> > > you explain what you exactly mean with a context switch ?
> > >
> > > -Andi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.2

iQEVAwUBOf9LYj7msCGEppcbAQFdZQgAocWtMwnNmmLnfSS+cGHZd8V0IFfmoVb7
fDRoNWMmOzU5g5W8aAudQFqGpGqizBR8/AA9ziqHRfKxwoo5/nuHtEMDpfw0nV5e
ghsd7qtzv1kTk0l5zp6bN2qPlGgs7Ke72od10X6pTGDyuUDQK71YNQ9UUcCv8GEO
2PpPOnCHw3atuQ0hetMNcFfIdvvslTB2+pcVzYxWWGhCYIeWreF8w1qf8XDYQil9
Ih22vmu69LP03RwXkFioikVSK8F8m+31DUBA67exN+R4qXy8+U5ZtyPQ+onIeguh
SnADBNjGjWK2mPyLNSVyAwH6EsIaGzk1QJ5hYULzVFi4zVl3pyRi8w==
=91LL
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Larry McVoy wrote:
> 
> On Tue, Oct 31, 2000 at 03:38:00PM -0700, Jeff V. Merkey wrote:
> > Larry McVoy wrote:
> > > On Tue, Oct 31, 2000 at 03:15:37PM -0700, Jeff V. Merkey wrote:
> > > > The quality of the networking code in Linux is quite excellent.  There's
> > > > some scaling problems relative to NetWare.  We are firmly committed to
> > > > getting something out with a Linux code base and NetWare metrics.  Love
> > > > to have your help.
> > >
> > > Jeff, I'm a little concerned with some of your statements.  Netware may
> > > be the greatest thing since sliced bread, but it isn't a full operating
> > > system, so comparing it to Linux is sort of meaningless.
> >
> > It's makes more money in a week than Linux has ever made.
> 
> And the relevance of that to this conversation is exactly what?
> 
> > A context switch in anoperating system context in it's simplest for is
> >
> > movx, esp
> > movesp, y
> >
> > > and you can support all that and get user to user context switches in a
>  ^
> > Apology accepted.
> 
> No apology was extended.  

hipocrite.

You're spouting nonsense.  User to user means
> process A in VM 1 switching to process B in VM 2.  I'm sorry, Mr Merkey,
> but a
> 
> movx, esp
> movesp, y
> 
> doesn't begin to approach a user to user context switch.  Please go learn
> what a user to user context switch is.  Then come back when you can do
> one of those in a few cycles.

You have angry fingers (one of my problems).   You don't need a user
context switch for kernel paths in a NOS kernel.  In NetWare, user
context switches are done in gates in the GDT with TSS descriptors, not
in kernel fast paths with LAN I/O, which isn't what I was talking about. 

Jeff

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

Re: 2.2.18Pre Lan Performance Rocks!

[Larry McVoy]

On Tue, Oct 31, 2000 at 03:47:56PM -0700, Jeff V. Merkey wrote:
> It kicks Linux's but in LAN I/O scaling.  

Really?  So, since in a few messages back you claimed that it has a fully
supported userland which implements all of P1003.1 as well as sockets,
obviously, since it is a networking operating system, it should be the 
work of a few minutes to download LMbench, compile it, and come back with
the lat_tcp performance numbers which "kicks Linux's but".  Please do so.
-- 
---
Larry McVoy  lm at bitmover.com   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Rik van Riel wrote:
> 
> On Tue, 31 Oct 2000, Jeff V. Merkey wrote:
> > Larry McVoy wrote:
> 
> > > Consider your
> > > recent context switch claims.  Yes, I believe that you can do the moral
> > > equiv of a longjmp() in the kernel in a few cycles, but that isn't a
> > > context switch, at least, it isn't the same a context switch in the
> > > operating system sense.
> 
> > A context switch in anoperating system context in it's simplest for is
> >
> > movx, esp
> > movesp, y
> 
> > > processes with virtual memory?
> > Yes.
> 
> Maybe you could tell us how long the context switch
> between processes with virtual memory takes, that
> would be a more meaningful comparison...
> 

Rik,

I'll bring down a NetWare 5 server, and snapshot the context switch code
from the NetWare debugger and email to you.

Jeff

> regards,
> 
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>-- Miguel de Icaza, UKUUG 2000
> 
> http://www.conectiva.com/   http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Rik van Riel]

On Tue, 31 Oct 2000, Jeff V. Merkey wrote:
> Larry McVoy wrote:

> > Consider your
> > recent context switch claims.  Yes, I believe that you can do the moral
> > equiv of a longjmp() in the kernel in a few cycles, but that isn't a
> > context switch, at least, it isn't the same a context switch in the
> > operating system sense.  

> A context switch in anoperating system context in it's simplest for is
> 
> movx, esp
> movesp, y

> > processes with virtual memory?
> Yes.

Maybe you could tell us how long the context switch
between processes with virtual memory takes, that
would be a more meaningful comparison...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

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

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

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Ingo Molnar wrote:
> 
> On Tue, 31 Oct 2000, Jeff V. Merkey wrote:
> 
> > A "context" is usually assued to be a "stack". [...]
> 
> a very clintonesque definition indeed ;-)
> 
> what is relevant is the latency to switch from one process to another one.
> And this is what we call a context switch. It includes scheduling
> decisions and all sorts of other stuff. You are comparing stack &
> caller-saved register switching performance (which is just a small part of
> context switching and has no standing alone) against full Linux context
> switch performance (this is what i quoted), and thus you have won my
> 'Mindcraft benchmark of the day' award :-)

Ingo,

It kicks Linux's but in LAN I/O scaling.  It would be nice for Linux to
have an incarnation that's competitive.  The only reason people are
still buying NetWare is because nothing out there has come along to
replace it.  That is going to change...

Jeff 


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

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

One more optimization it has.  NetWare never "calls" functions in the
kernel.  There's a template of register assignments in between kernel
modules that's very strict (esi contains a WTD head, edi has the target
thread, etc.) and all function calls are jumps in a linear space. 
layout of all functions are 16 bytes aligned for speed, and all
arguments in kernel are passed via registers.  It's a level of
optimization no C compiler does -- all of it was done by hand, and most
function s in fast paths are layed out in 512 byte chunks to increases
speed.  Stack memory activity in the NetWare kernel is almost
non-existent in almost all of the "fast paths"

Jeff

"Jeff V. Merkey" wrote:
> 
> A "context" is usually assued to be a "stack".  The simplest of all
> context switches
> is:
> 
>movx, esp
>movesp, y
> 
> A context switch can be as short as two instructions, or as big as a TSS
> with CR3 hardware switching,
> 
> i.e.
> 
>ltrax
>jmptask_gate
> 
> (500 clocks later)
> 
>ts->eip gets exec'd
> 
> you can also have a context switch that does an int X where X is a gate
> or TSS.
> 
> you can also have a context switch (like linux) that does
> 
> movx, esp
> movesp, y
> movz, CR3
> movCR3, w
> 
> etc.
> 
> In NetWare, a context switch is an in-line assembly language macro that
> is 2 instructions long for a stack switch and 4 instructions for a CR3
> reload -- this is a lot shorter than Linux.
> Only EBX, EBP, ESI, and EDI are saved and this is never done in the
> kernel, but is a natural
> affect of the Watcom C compiler.  There's also strict rules about
> register assignments that re enforced between assembler modules in
> NetWare to reduce the overhead of a context switch.  The code path is
> very complex in NetWare, and priorities and all this stuff exists, but
> these code paths are segragated so these types of checks only happen
> once in a while and check a pre-calc'd "scoreboard" that is read only
> across processors and updated and recal'd by a timer every 18 ticks.
> 
> Jeff
> 
> 
> 
> Andi Kleen wrote:
> >
> > On Tue, Oct 31, 2000 at 02:52:11PM -0700, Jeff V. Merkey wrote:
> > > The numbers don't lie.  You know where the code is.  You notice that
> > > there is a version of
> > > the kernel hand coded in assembly language.  You'l also noticed that
> > > it's SMP and takes ZERO LOCKS during context switching, in fact, most of
> > > the design is completely lockless.
> >
> > I suspect most of the confusion in this thread comes because you seem to
> > use a different definition of context switch than Ingo and others. Could
> > you explain what you exactly mean with a context switch ?
> >
> > -Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Larry McVoy]

On Tue, Oct 31, 2000 at 03:38:00PM -0700, Jeff V. Merkey wrote:
> Larry McVoy wrote:
> > On Tue, Oct 31, 2000 at 03:15:37PM -0700, Jeff V. Merkey wrote:
> > > The quality of the networking code in Linux is quite excellent.  There's
> > > some scaling problems relative to NetWare.  We are firmly committed to
> > > getting something out with a Linux code base and NetWare metrics.  Love
> > > to have your help.
> > 
> > Jeff, I'm a little concerned with some of your statements.  Netware may
> > be the greatest thing since sliced bread, but it isn't a full operating
> > system, so comparing it to Linux is sort of meaningless.
> 
> It's makes more money in a week than Linux has ever made.  

And the relevance of that to this conversation is exactly what?

> A context switch in anoperating system context in it's simplest for is
> 
> movx, esp
> movesp, y
> 
> > and you can support all that and get user to user context switches in a
 ^
> Apology accepted.

No apology was extended.  You're spouting nonsense.  User to user means
process A in VM 1 switching to process B in VM 2.  I'm sorry, Mr Merkey,
but a 

movx, esp
movesp, y

doesn't begin to approach a user to user context switch.  Please go learn
what a user to user context switch is.  Then come back when you can do
one of those in a few cycles.
-- 
---
Larry McVoy  lm at bitmover.com   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Ingo Molnar]

On Tue, 31 Oct 2000, Jeff V. Merkey wrote:

> A "context" is usually assued to be a "stack". [...]

a very clintonesque definition indeed ;-)

what is relevant is the latency to switch from one process to another one.
And this is what we call a context switch. It includes scheduling
decisions and all sorts of other stuff. You are comparing stack &
caller-saved register switching performance (which is just a small part of
context switching and has no standing alone) against full Linux context
switch performance (this is what i quoted), and thus you have won my
'Mindcraft benchmark of the day' award :-)

Ingo

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

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Larry McVoy wrote:
> 
> On Tue, Oct 31, 2000 at 03:15:37PM -0700, Jeff V. Merkey wrote:
> > The quality of the networking code in Linux is quite excellent.  There's
> > some scaling problems relative to NetWare.  We are firmly committed to
> > getting something out with a Linux code base and NetWare metrics.  Love
> > to have your help.
> 
> Jeff, I'm a little concerned with some of your statements.  Netware may
> be the greatest thing since sliced bread, but it isn't a full operating
> system, so comparing it to Linux is sort of meaningless.

It's makes more money in a week than Linux has ever made.  

  Consider your
> recent context switch claims.  Yes, I believe that you can do the moral
> equiv of a longjmp() in the kernel in a few cycles, but that isn't a
> context switch, at least, it isn't the same a context switch in the
> operating system sense.  
A context switch in anoperating system context in it's simplest for is

movx, esp
movesp, y

It's different - last I checked, Netware was
> essentially a kernel and nothing else.  


Is there a file system?
Several.

  Are there
> processes with virtual memory?
Yes.

  Are they preemptive?
Yes.

  Does it support
> all of P1003.1?  
Yes.

Etc.  If the answers to all of the above are "yes"
> and you can support all that and get user to user context switches in a
> clock cycle, well, jeez, you really do walk on water and I'll publicly
> apologize for ever doubting your statements.  

Apology accepted.

Jeff


> --
> ---
> Larry McVoy  lm at bitmover.com   http://www.bitmover.com/lm
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> 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]
Please read the FAQ at http://www.tux.org/lkml/

Oops in test10 during module loading of 3c509

[Jarek Luberek]

Just a short Oops report for test10. 

Extra Patches: reiserfs: linux-2.4.0-test9-reiserfs-3.6.18
no patch collisions with this patch and test10

test10-pre7 worked fine.

Oops during loading of 3c509-module. 
System: Dual PIII/450 256M 

Greetings,
jarek

-

Oct 31 23:18:52 marvin kernel: Unable to handle kernel NULL pointer dereference at 
virtual address 0070 
Oct 31 23:18:52 marvin kernel: d08b85ab 
Oct 31 23:18:52 marvin kernel: *pde =  
Oct 31 23:18:52 marvin kernel: Oops: 0002 
Oct 31 23:18:52 marvin kernel: CPU:1 
Oct 31 23:18:52 marvin kernel: EIP:0010:[3c509:el3_probe+1355/5024] 
Oct 31 23:18:53 marvin kernel: EFLAGS: 00010202 
Oct 31 23:18:53 marvin kernel: eax:    ebx: 0070   ecx:    edx: 
385a1000 
Oct 31 23:18:53 marvin kernel: esi: 0003   edi: cf6ddf2e   ebp: 0220   esp: 
cf6ddee4 
Oct 31 23:18:53 marvin kernel: ds: 0018   es: 0018   ss: 0018 
Oct 31 23:18:53 marvin kernel: Process modprobe (pid: 220, stackpage=cf6dd000) 
Oct 31 23:18:53 marvin kernel: Stack:    ffea c02c3e18 
 ffea c02c3c40  
Oct 31 23:18:53 marvin kernel:e68c e68d  000b 00ff 
 ffea c1044010  
Oct 31 23:18:53 marvin kernel:c02c3c40 385a1000 f8e8 d08b935b  
d08b8000  c011a6cf  
Oct 31 23:18:53 marvin kernel: Call Trace: [3c509:el3_probe+4859/5024] 
[3c509:__insmod_3c509_O/lib/modules/2.4.0-test10/kernel/drivers/ne+0/96] 
[sys_init_module+1143/1324] 
[3c509:__insmod_3c509_O/lib/modules/2.4.0-test10/kernel/drivers/ne+72/96] 
[3c509:__insmod_3c509_O/lib/modules/2.4.0-test10/kernel/drivers/ne+72/96] 
[system_call+51/56]  
Oct 31 23:18:53 marvin kernel: Code: 89 50 70 8b 54 24 48 66 89 53 04 89 68 20 8b 54 
24 2c 89 50  
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   89 50 70  mov%edx,0x70(%eax)
Code;  0003 Before first symbol
   3:   8b 54 24 48   mov0x48(%esp,1),%edx
Code;  0007 Before first symbol
   7:   66 89 53 04   mov%dx,0x4(%ebx)
Code;  000b Before first symbol
   b:   89 68 20  mov%ebp,0x20(%eax)
Code;  000e Before first symbol
   e:   8b 54 24 2c   mov0x2c(%esp,1),%edx
Code;  0012 Before first symbol
  12:   89 50 00  mov%edx,0x0(%eax)

--

Module  Size  Used by
es1371 29968   0  (unused)
ac97_codec  7888   0  [es1371]
3c509   7472   1  (initializing)

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Ingo Molnar wrote:
> 
> On Tue, 31 Oct 2000, Jeff V. Merkey wrote:
> 
> > > > > Excuse me, 857,000,000 instructions executed and 460,000,000
> > > > > context switches a second -- on a PII system at 350 Mhz. [...]
> > >
> > > > That's more than one context switch per clock. I do not think so.
> > > > Really go and check those numbers.
> > >
> > > yep, you cannot have 460 million context switches on that system,
> > > unless you have some Clintonesque definition for 'context switch' ;-)
> >
> > The numbers don't lie. [...]
> 
> sure ;) I can do infinite context switches! You dont believe? See:
> 
> #define schedule() do { } while (0)

Actually, I think the compiler would optimize this statement completely
out of the code.

Jeff

> 
> [there is a small restriction, should only be used in single-task
> systems.]
> 
> Ingo
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

A "context" is usually assued to be a "stack".  The simplest of all
context switches 
is:

   movx, esp
   movesp, y

A context switch can be as short as two instructions, or as big as a TSS
with CR3 hardware switching,

i.e.  

   ltrax
   jmptask_gate

(500 clocks later)

   ts->eip gets exec'd

you can also have a context switch that does an int X where X is a gate
or TSS.

you can also have a context switch (like linux) that does

movx, esp
movesp, y
movz, CR3
movCR3, w

etc.

In NetWare, a context switch is an in-line assembly language macro that
is 2 instructions long for a stack switch and 4 instructions for a CR3
reload -- this is a lot shorter than Linux.
Only EBX, EBP, ESI, and EDI are saved and this is never done in the
kernel, but is a natural
affect of the Watcom C compiler.  There's also strict rules about
register assignments that re enforced between assembler modules in
NetWare to reduce the overhead of a context switch.  The code path is
very complex in NetWare, and priorities and all this stuff exists, but
these code paths are segragated so these types of checks only happen
once in a while and check a pre-calc'd "scoreboard" that is read only
across processors and updated and recal'd by a timer every 18 ticks.

Jeff

   



Andi Kleen wrote:
> 
> On Tue, Oct 31, 2000 at 02:52:11PM -0700, Jeff V. Merkey wrote:
> > The numbers don't lie.  You know where the code is.  You notice that
> > there is a version of
> > the kernel hand coded in assembly language.  You'l also noticed that
> > it's SMP and takes ZERO LOCKS during context switching, in fact, most of
> > the design is completely lockless.
> 
> I suspect most of the confusion in this thread comes because you seem to
> use a different definition of context switch than Ingo and others. Could
> you explain what you exactly mean with a context switch ?
> 
> -Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Larry McVoy]

On Tue, Oct 31, 2000 at 03:15:37PM -0700, Jeff V. Merkey wrote:
> The quality of the networking code in Linux is quite excellent.  There's
> some scaling problems relative to NetWare.  We are firmly committed to
> getting something out with a Linux code base and NetWare metrics.  Love
> to have your help.

Jeff, I'm a little concerned with some of your statements.  Netware may
be the greatest thing since sliced bread, but it isn't a full operating
system, so comparing it to Linux is sort of meaningless.  Consider your
recent context switch claims.  Yes, I believe that you can do the moral
equiv of a longjmp() in the kernel in a few cycles, but that isn't a
context switch, at least, it isn't the same a context switch in the
operating system sense.  It's different - last I checked, Netware was
essentially a kernel and nothing else.  Is there a file system?  Are there
processes with virtual memory?  Are they preemptive?  Does it support
all of P1003.1?  Etc.  If the answers to all of the above are "yes"
and you can support all that and get user to user context switches in a
clock cycle, well, jeez, you really do walk on water and I'll publicly
apologize for ever doubting your statements.  On the other hand, if the
answers to that are not all "yes", then how about you do a little truth
in advertising with your postings?  Without it, they are misleading to
the point of being purposefully deceptive.
-- 
---
Larry McVoy  lm at bitmover.com   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: scsi-cdrom lockup and ide-scsi problem (both EFS related)

[Jens Axboe]

On Tue, Oct 31 2000, Paul Jakma wrote:
> I have 2 problems related to reading IRIX EFS cd's.
> 
> ---problem 1:
> 
> mounting an EFS cd from my Yamaha CDR-4416S SCSI CDRW consistently
> causes a lockup when i try to read directory/file data from the CD. I
> observed this initially with EFS CDR's, and assumed something had
> gone wrong when burning that CD. But the exact same thing happens
> with original SGI IRIX media. I have no problems with any of my EFS
> CDs when accesed from an ATAPI CDROM.

Known problem, blocksizes != 2kb does not currently work
correctly with SCSI CD-ROM (it's even on Ted's list).

> My IDE CDROM under ide-scsi emulation does not like trying to mount
> EFS CDs, here are the logs of multiple mount attempts:

Same deal, SCSI CD-ROM driver. As you noted, pure ATAPI drive will
work just fine.

> ide-scsi emulation - if i want to mount the CD for any reason i have
> to reboot again to get the IDE CDROM back to pure ATAPI mode, then
> reboot again for ide-scsi to burn a cd... slightly frustrating. :)

rmmod ide-scsi ; insmod ide-cd
mount, etc
rmmod ide-cd ; insmod ide-scsi
burn

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

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Larry,

The quality of the networking code in Linux is quite excellent.  There's
some scaling problems relative to NetWare.  We are firmly committed to
getting something out with a Linux code base and NetWare metrics.  Love
to have your help.

Jeff

Larry McVoy wrote:
> 
> {lots of perf stuff deleted}
> 
> I'm posting this to point out that Linux networking is getting better at
> a substantial pace.
> 
> I've already sent this to Davem and Linus a while back, but I have a
> pretty nice lab here at BitMover, 4 100Mbit switched networks, servers
> with 4 cards, and enough clients to generate load.   I actually have
> two servers both of which have a NIC on each network; one server has
> .2.15pre9 on it and the other has 2.4.0-test5 on it.
> 
> I don't have a lot of spare time, but if you are one of the kernel
> developers and you have tests you want run, contact me privately.
> 
> I ran some tests to see how things have changed.  What follows are the
> details, the short summary is that 2.4 looks to me to be about 2x better
> in both latency and bandwidth, no mean feat.  I'm very impressed with
> this, and I'm especially tickled to see the hand that Dave has had in
> this, he's really come into his own as a senior kernel hacker.  I'm sure
> he doesn't need me to stroke his ego, but I'm doing it anyways because
> I'm proud of him (with no disrespect to the many other people who have
> worked on this intended).
> 
> So here's what I did.  I fired up the lat_tcp and bw_tcp servers from
> lmbench on the server and then generated load from all the clients.
> I noodled around until I found the right mix which gave the best numbers
> and that's roughly what is reported below.  I don't have the 2.2 numbers
> handy but I can get them if you care, it was very close to 2x worse,
> like about 1.9x or so.
> 
> The server is running Linux 2.4 test9, I believe.  It has 3 Intel EEpro's
> and one 3c905B.   It's a Ghz K7.
> 
>   Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 8).
>   Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (#2) (rev 8).
>   Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (#3) (rev 8).
>   Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 48).
> 
> All are going into Netgear Fs308 8 port switches.  There are 13 clients,
> mostly Intel Linux boxes, but various others as well, let me know if
> you care.  A couple of the clients were behind two levels of switches
> (I have 6 here).
> 
> Run a single copy of lat_tcp on each client against the server, we see:
> load free cach swap pgin  pgou dk0 dk1 dk2 dk3 ipkt opkt  int  ctx  usr sys idl
> 4.68 443M  21M   00 00   0   0   0   42K  39K  55K  46K   4  96   0
> 4.68 443M  21M   00   2.0K   0   0   0   0   40K  38K  55K  44K   2  98   0
> 4.68 443M  21M   00 00   0   0   0   40K  38K  55K  44K   3  97   0
> 4.55 443M  21M   00 00   0   0   0   42K  40K  54K  48K   4  96   0
> 4.55 443M  21M   00 00   0   0   0   41K  39K  54K  45K   3  97   0
> 4.50 443M  21M   00 00   0   0   0   40K  38K  54K  44K   2  98   0
> 4.50 443M  21M   00 00   0   0   0   41K  38K  55K  44K   3  97   0
> 4.50 443M  21M   00 00   0   0   0   41K  41K  54K  45K   7  93   0
> 4.86 443M  21M   00 00   0   0   0   38K  38K  54K  44K   3  97   0
> 
> OK, now bandwidth.  Each client is capable of getting at least 11MB/sec from
> the server when run one at a time.  I ran just 4 clients, one per network.
> 
> load free cach swap pgin  pgou dk0 dk1 dk2 dk3 ipkt opkt  int  ctx  usr sys idl
> 0.28 444M  22M   00 00   0   0   0   14K  27K  15K 2.9K   2  55  43
> 0.28 444M  22M   00 00   0   0   0   14K  29K  16K 3.1K   2  66  32
> 0.26 444M  22M   00 00   0   0   0   14K  29K  16K 3.0K   1  67  32
> 0.26 444M  22M   00 00   0   0   0   15K  29K  16K 3.0K   1  65  34
> 0.24 444M  22M   00 00   0   0   0   15K  29K  16K 3.0K   0  70  30
> 0.24 444M  22M   00 00   0   0   0   15K  29K  16K 3.0K   0  63  37
> 0.24 444M  22M   00 00   0   0   0   14K  28K  16K 3.0K   1  62  37
> 0.22 444M  22M   0  2.0K00   0   0   0   14K  28K  16K 2.9K   1  65  34
> 
> It works out to an average of 10.4MB/sec per client or 41.6MB/sec on the
> server on a PCI/32 @ 33Mhz bus.  Same Ghz server.  Note the idle cycles,
> bandwidth is a lot easier than latency.
> 
> Hope this is useful to someone.
> --
> ---
> Larry McVoy  lm at bitmover.com   http://www.bitmover.com/lm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Andi Kleen]

On Tue, Oct 31, 2000 at 02:52:11PM -0700, Jeff V. Merkey wrote:
> The numbers don't lie.  You know where the code is.  You notice that
> there is a version of
> the kernel hand coded in assembly language.  You'l also noticed that
> it's SMP and takes ZERO LOCKS during context switching, in fact, most of
> the design is completely lockless.

I suspect most of the confusion in this thread comes because you seem to 
use a different definition of context switch than Ingo and others. Could
you explain what you exactly mean with a context switch ? 

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

Re: 2.2.18Pre Lan Performance Rocks!

[Larry McVoy]

{lots of perf stuff deleted}

I'm posting this to point out that Linux networking is getting better at
a substantial pace.

I've already sent this to Davem and Linus a while back, but I have a
pretty nice lab here at BitMover, 4 100Mbit switched networks, servers
with 4 cards, and enough clients to generate load.   I actually have
two servers both of which have a NIC on each network; one server has
.2.15pre9 on it and the other has 2.4.0-test5 on it.

I don't have a lot of spare time, but if you are one of the kernel
developers and you have tests you want run, contact me privately.

I ran some tests to see how things have changed.  What follows are the
details, the short summary is that 2.4 looks to me to be about 2x better
in both latency and bandwidth, no mean feat.  I'm very impressed with
this, and I'm especially tickled to see the hand that Dave has had in
this, he's really come into his own as a senior kernel hacker.  I'm sure
he doesn't need me to stroke his ego, but I'm doing it anyways because
I'm proud of him (with no disrespect to the many other people who have
worked on this intended).

So here's what I did.  I fired up the lat_tcp and bw_tcp servers from
lmbench on the server and then generated load from all the clients.
I noodled around until I found the right mix which gave the best numbers
and that's roughly what is reported below.  I don't have the 2.2 numbers
handy but I can get them if you care, it was very close to 2x worse, 
like about 1.9x or so.

The server is running Linux 2.4 test9, I believe.  It has 3 Intel EEpro's
and one 3c905B.   It's a Ghz K7.

  Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 8).
  Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (#2) (rev 8).
  Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (#3) (rev 8).
  Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 48).

All are going into Netgear Fs308 8 port switches.  There are 13 clients,
mostly Intel Linux boxes, but various others as well, let me know if
you care.  A couple of the clients were behind two levels of switches
(I have 6 here).

Run a single copy of lat_tcp on each client against the server, we see:
load free cach swap pgin  pgou dk0 dk1 dk2 dk3 ipkt opkt  int  ctx  usr sys idl
4.68 443M  21M   00 00   0   0   0   42K  39K  55K  46K   4  96   0
4.68 443M  21M   00   2.0K   0   0   0   0   40K  38K  55K  44K   2  98   0
4.68 443M  21M   00 00   0   0   0   40K  38K  55K  44K   3  97   0
4.55 443M  21M   00 00   0   0   0   42K  40K  54K  48K   4  96   0
4.55 443M  21M   00 00   0   0   0   41K  39K  54K  45K   3  97   0
4.50 443M  21M   00 00   0   0   0   40K  38K  54K  44K   2  98   0
4.50 443M  21M   00 00   0   0   0   41K  38K  55K  44K   3  97   0
4.50 443M  21M   00 00   0   0   0   41K  41K  54K  45K   7  93   0
4.86 443M  21M   00 00   0   0   0   38K  38K  54K  44K   3  97   0


OK, now bandwidth.  Each client is capable of getting at least 11MB/sec from
the server when run one at a time.  I ran just 4 clients, one per network.

load free cach swap pgin  pgou dk0 dk1 dk2 dk3 ipkt opkt  int  ctx  usr sys idl
0.28 444M  22M   00 00   0   0   0   14K  27K  15K 2.9K   2  55  43
0.28 444M  22M   00 00   0   0   0   14K  29K  16K 3.1K   2  66  32
0.26 444M  22M   00 00   0   0   0   14K  29K  16K 3.0K   1  67  32
0.26 444M  22M   00 00   0   0   0   15K  29K  16K 3.0K   1  65  34
0.24 444M  22M   00 00   0   0   0   15K  29K  16K 3.0K   0  70  30
0.24 444M  22M   00 00   0   0   0   15K  29K  16K 3.0K   0  63  37
0.24 444M  22M   00 00   0   0   0   14K  28K  16K 3.0K   1  62  37
0.22 444M  22M   0  2.0K00   0   0   0   14K  28K  16K 2.9K   1  65  34

It works out to an average of 10.4MB/sec per client or 41.6MB/sec on the
server on a PCI/32 @ 33Mhz bus.  Same Ghz server.  Note the idle cycles,
bandwidth is a lot easier than latency.

Hope this is useful to someone.
-- 
---
Larry McVoy  lm at bitmover.com   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Ingo Molnar]

On Tue, 31 Oct 2000, Jeff V. Merkey wrote:

> > > > Excuse me, 857,000,000 instructions executed and 460,000,000
> > > > context switches a second -- on a PII system at 350 Mhz. [...]
> > 
> > > That's more than one context switch per clock. I do not think so.
> > > Really go and check those numbers.
> > 
> > yep, you cannot have 460 million context switches on that system,
> > unless you have some Clintonesque definition for 'context switch' ;-)
> 
> The numbers don't lie. [...]

sure ;) I can do infinite context switches! You dont believe? See:

#define schedule() do { } while (0)

[there is a small restriction, should only be used in single-task
systems.]

Ingo

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

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Ingo Molnar wrote:
> 
> On Tue, 31 Oct 2000, Jeff V. Merkey wrote:
> 
> > It relies on an anomoly in the design of Intel's cache controllers,
> > and with memory based applications, I can get 120% scaling per
> > procesoor by jugling the working set of executable code cached accros
> > each processor.  There's sample code with this kernel you can use to
> > verify
> 
> FYI, this is a very old concept and a scalability FAQ item. It's called
> "sublinear scaling", and SGI folks have already published articles about
> it 10 years ago.

Ingo,

You don't even know what it is enough to comment intelligently.  You can
write the patent office and obtain a copy.  The patent is currently in
dispute between Novell and several other companies over S ownership,
and there's a court hearing scheduled to resolve it (lukily I don't have
to deal with this one).  Nice thing about being an inventor, though, is
I have rights to it, no matter who ends up with the S assignment.
(dogs fights over a bone ...).

Jeff

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

Re: 2.2.18Pre Lan Performance Rocks!

[Rik van Riel]

On Tue, 31 Oct 2000, Reto Baettig wrote:

> Is there any documentation about the Tux zero-copy
> implementation so that I don't have to read half of the 2.4
> kernel sources before having a clue?

Reading the 2.4 sources won't do you much good since
the Tux layer isn't integrated ;)

> Are the kernel changes going to be in the mainstream kernel?

Dunno, ask Ingo and/or Linus...

> Sorry for the newbie questions, but it's really hard to find
> information about Tux (other than the holy source code, of
> course ;-)

Maybe there's some documentation included with the Tux
source code or maybe there's something on the Tux web
page?  Have you tried looking there?

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

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

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

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Rik van Riel wrote:
> 
> On Tue, 31 Oct 2000, Jeff V. Merkey wrote:
> > Rik van Riel wrote:
> > > On Tue, 31 Oct 2000, Reto Baettig wrote:
> > >
> > > > When I'm following this thread, you guys seem to forget the
> > > > _basics_: The Linux networking stack sucks!
> > >
> > > Ummm, last I looked Linux held the Specweb99 record;
> > > by a wide margin...
> >
> > It doesn't hold the file and print scaling record.  NetWare
> > does..
> 
> Indeed, we haven't made a file serving plugin for
> the TUX zero-copy stuff yet...
> 
> Oh, and I haven't found a bunch of printers yet that are
> fast enough to beat the printserving record ;))

You got me on this one.  I would also agree that NPDS is the worst piece
of crap ever written.  

:-)

Jeff


>   *runs like hell*
> 
> cheers,
> 
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>-- Miguel de Icaza, UKUUG 2000
> 
> http://www.conectiva.com/   http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Reto Baettig]

Rik

Is there any documentation about the Tux zero-copy implementation so
that I don't have to read half of the 2.4 kernel sources before having a
clue? 

Are the kernel changes going to be in the mainstream kernel?

Does Tux implement a new interface so that a userspace app can do
zero-copy stuff with the network?

Sorry for the newbie questions, but it's really hard to find information
about Tux (other than the holy source code, of course ;-)

TIA

Reto

Rik van Riel wrote:
> 
> On Tue, 31 Oct 2000, Jeff V. Merkey wrote:
> > Rik van Riel wrote:
> > > On Tue, 31 Oct 2000, Reto Baettig wrote:
> > >
> > > > When I'm following this thread, you guys seem to forget the
> > > > _basics_: The Linux networking stack sucks!
> > >
> > > Ummm, last I looked Linux held the Specweb99 record;
> > > by a wide margin...
> >
> > It doesn't hold the file and print scaling record.  NetWare
> > does..
> 
> Indeed, we haven't made a file serving plugin for
> the TUX zero-copy stuff yet...
> 
> Oh, and I haven't found a bunch of printers yet that are
> fast enough to beat the printserving record ;))
>   *runs like hell*
> 
> cheers,
> 
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>-- Miguel de Icaza, UKUUG 2000
> 
> http://www.conectiva.com/   http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Ingo Molnar wrote:
> 
> On Tue, 31 Oct 2000, Pavel Machek wrote:
> 
> > > Excuse me, 857,000,000 instructions executed and 460,000,000
> > > context switches a second -- on a PII system at 350 Mhz. [...]
> 
> > That's more than one context switch per clock. I do not think so.
> > Really go and check those numbers.
> 
> yep, you cannot have 460 million context switches on that system,
> unless you have some Clintonesque definition for 'context switch' ;-)

The numbers don't lie.  You know where the code is.  You notice that
there is a version of
the kernel hand coded in assembly language.  You'l also noticed that
it's SMP and takes ZERO LOCKS during context switching, in fact, most of
the design is completely lockless.

Jeff

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

scsi-cdrom lockup and ide-scsi problem (both EFS related)

[Paul Jakma]

hi,

I have 2 problems related to reading IRIX EFS cd's.

---problem 1:

mounting an EFS cd from my Yamaha CDR-4416S SCSI CDRW consistently
causes a lockup when i try to read directory/file data from the CD. I
observed this initially with EFS CDR's, and assumed something had
gone wrong when burning that CD. But the exact same thing happens
with original SGI IRIX media. I have no problems with any of my EFS
CDs when accesed from an ATAPI CDROM.

i havn't been able to capture an oops, but the following made it to
the remote syslog host:

Oct 30 18:48:29 fogarty kernel: EFS: 1.0a -
http://aeschi.ch.eu.org/efs/ 
Oct 30 18:48:44 fogarty kernel: scsi0 channel 0 : resetting for
second half of retries. 
Oct 30 18:48:44 fogarty kernel: SCSI bus is being reset for host 0
channel 0. 
Oct 30 18:48:44 fogarty kernel: scsi0: Sending Bus Device Reset CCB
#10912 to Target 4 
Oct 30 18:48:44 fogarty kernel: scsi0: Bus Device Reset CCB #10912 to
Target 4 Completed 
Oct 30 18:48:44 fogarty kernel: Device 0b:00 not ready. 
Oct 30 18:48:44 fogarty kernel:  I/O error: dev 0b:00, sector 1233661 
Oct 30 18:48:44 fogarty kernel: EFS: readdir(): failed to read dir
block 0 
Oct 30 18:48:44 fogarty kernel: Device 0b:00 not ready. 
Oct 30 18:48:44 fogarty kernel:  I/O error: dev 0b:00, sector 1215956 
Oct 30 18:48:44 fogarty kernel: EFS: readdir(): failed to read dir
block 0 
Oct 30 18:48:44 fogarty kernel: Device 0b:00 not ready. 
Oct 30 18:48:44 fogarty kernel:  I/O error: dev 0b:00, sector 1236972 
Oct 30 18:48:44 fogarty kernel: EFS: readdir(): failed to read dir
block 0 
Oct 30 18:48:44 fogarty kernel: Device 0b:00 not ready. 
Oct 30 18:48:44 fogarty kernel:  I/O error: dev 0b:00, sector 1243717 
Oct 30 18:48:44 fogarty kernel: EFS: readdir(): failed to read dir
block 0 
Oct 30 18:48:44 fogarty kernel: Device 0b:00 not ready. 
Oct 30 18:48:44 fogarty kernel:  I/O error: dev 0b:00, sector 48130 
Oct 30 18:48:44 fogarty kernel: EFS: readdir(): failed to read dir
block 0



--problem 2:

My IDE CDROM under ide-scsi emulation does not like trying to mount
EFS CDs, here are the logs of multiple mount attempts:

Oct 31 00:06:50 fogarty kernel: EFS: 1.0a -
http://aeschi.ch.eu.org/efs/ 
Oct 31 00:06:50 fogarty kernel: sr.c:Bad 2K block number requested (0
1) I/O error: dev 0b:01, sector 0 
Oct 31 00:06:50 fogarty kernel: EFS: cannot read volume header
Oct 31 00:06:53 fogarty kernel: Device not ready.  Make sure there is
a disc in the drive. 
Oct 31 00:06:56 fogarty kernel: Device not ready.  Make sure there is
a disc in the drive. 
Oct 31 00:06:59 fogarty kernel: Device not ready.  Make sure there is
a disc in the drive. 
Oct 31 00:07:20 fogarty kernel: sr.c:Bad 2K block number requested (0
1) I/O error: dev 0b:01, sector 0 
Oct 31 00:07:20 fogarty kernel: EFS: cannot read volume header 
Oct 31 00:07:32 fogarty kernel: ide-scsi: hdd: unsupported command in
request queue (0) 
Oct 31 00:07:32 fogarty kernel: end_request: I/O error, dev 16:40
(hdd), sector 0 
Oct 31 00:07:32 fogarty kernel: EFS: cannot read volume header 
Oct 31 00:07:49 fogarty kernel: sr.c:Bad 2K block number requested (0
1) I/O error: dev 0b:01, sector 0 
Oct 31 00:07:49 fogarty kernel: EFS: cannot read volume header 
Oct 31 00:07:56 fogarty kernel: sr.c:Bad 2K block number requested (0
1) I/O error: dev 0b:01, sector 0 
Oct 31 00:07:56 fogarty kernel: EFS: cannot read volume header

after this the CDROM behaves strange (gtoaster can't read data track,
which it could before), until i put another disk (eg audio) into it
first.

---

result:

to mount an EFS cd i have to use my IDE CDROM in ATAPI mode, as the
SCSI CDRW locks the machine.

then to burn an EFS cd i have to reboot and set my ATAPI CDROM to use
ide-scsi emulation - if i want to mount the CD for any reason i have
to reboot again to get the IDE CDROM back to pure ATAPI mode, then
reboot again for ide-scsi to burn a cd... slightly frustrating. :)

the devices are:
[root@fogarty xinetd.d]# cat /proc/scsi/scsi 
Attached devices: 
Host: scsi0 Channel: 00 Id: 04 Lun: 00
  Vendor: YAMAHA   Model: CRW4416S Rev: 1.0g
  Type:   CD-ROM   ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: CREATIVE Model: CD2422E  MC102   Rev: 1.02
  Type:   CD-ROM   ANSI SCSI revision: 02

please contact me if you need further debugging info. 

regards,
-- 
Paul Jakma  [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
%DCL-MEM-BAD, bad memory
VMS-F-PDGERS, pudding between the ears

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

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

"Jeff V. Merkey" wrote:
> 
> Alan Cox wrote:
> >
> > > Why not solve the problem at the source and completely redesign the
> > > network stack? Get rid of the old sk_buff & co! Rip the whole network
> > > layer out! Redesign it and give the user a possibility of Zero-Copy
> > > networking!
> >
> > For one because you don't need to do that to get zero copy networking for
> > most real world cases. Tux already implements the neccessary infrastructure
> > for these.
> 
> The code in the networking layer is fine, in fact, it's absolutely
> great.  This is not
> the problem.   The problem are all the clocks wasted reloading TLBs and
> the background
> memory activitiy caused by Linux's heavy dependence in Intel's
> protection hardware model.
> 
> Step 1 is to load the entire OS at ring 0 with protection completely
> disabled system wide,
> put in the kernel optimizations for AGI and context switch locking, and
> stub the top half of Linus's scheduler.  The global memory structures in
> his kernel may or may not hurt performance, depending on how they are
> accessed by multiple processors.  I will need to start profiling with a
> ring 0 port first and determine frequency of access that's hardware
> measured.
> 
> The next step would be to start peeling off different subsystems and
> re-parallelizing them
> on the merged kernel.  There's an awful lot of areas in Linus' that are
> going to be a
> problem, but I'll work through them one at a time.  When I first
> parallelized NetWare, I wrote
> an independent SMP kernel then loaded the entire NetWare 4.1 image as a
> single process.  The next step was to start peeling off layers from
> NetWare and plugging them in one by one and parallelizing them.  I am
> using the same approach here.  When I was finished, I had peeled NetWare
> like a banana and completely reintegrated it on a new kernel.  This
> approach works because it allows you to stage each layer.
> 
> The next step will be to modify the loader to allow the existing
> protection scheme to exist in true user space.  WRD's will hold off CR3
> switching so long as I/O is coming in or out of the box.  I anticipate
> this will take until March of next year to get right.
> 
> Jeff
> 


One other point.  You guys can try as hard as you can to hack around
this problem, but it will never scale like NetWare unless a
fundamentally different approach is adopted.  I've built this before,
and what we are doing is building in all the Linux functionality with
the identical code -- basically a Linux NetWare -- into a NetWare
framework.  All the protection can still be there, it just needs to be
restructured with some LAN based design assumptions.  I think the
industry will be pleased with the result.  I do not believe any of the
proposed hacks will get there unless this different approach is
investigated.   

Jeff




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

Re: 2.2.18Pre Lan Performance Rocks!

[Rik van Riel]

On Tue, 31 Oct 2000, Jeff V. Merkey wrote:
> Rik van Riel wrote:
> > On Tue, 31 Oct 2000, Reto Baettig wrote:
> > 
> > > When I'm following this thread, you guys seem to forget the
> > > _basics_: The Linux networking stack sucks!
> > 
> > Ummm, last I looked Linux held the Specweb99 record;
> > by a wide margin...
> 
> It doesn't hold the file and print scaling record.  NetWare
> does..

Indeed, we haven't made a file serving plugin for
the TUX zero-copy stuff yet...

Oh, and I haven't found a bunch of printers yet that are
fast enough to beat the printserving record ;))
  *runs like hell*

cheers,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

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

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

Re: 2.2.18Pre Lan Performance Rocks!

[Jeff V. Merkey]

Paul Menage wrote:
> 
> On Tue, 31 Oct 2000, Rik van Riel wrote:
> >
> >Ummm, last I looked Linux held the Specweb99 record;
> >by a wide margin...
> >
> 
> ... but since then IBM/Zeus appear to have taken the lead:
> 
> http://www.zeus.com/news/articles/001004-001/
> http://www.spec.org/osg/web99/results/res2000q3/
> 
> But they were using a somewhat beefier machine - has anyone got Tux
> SpecWeb99 figures for a 12 CPU, 64 GB, 12 NIC system?

NetWare holds the file and print scaling record, which is what this
thread is about,
not web servers copying read only data from cache...

Jeff

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