Re: 2.4.4 sluggish under fork load

2001-05-01 Thread J . A . Magallon


On 05.01 Andrea Arcangeli wrote:
 
 And if you fork off a child with its p-policy SCHED_YIELD set it will
 never get scheduled in.
 
 Only just running tasks can have SCHED_YIELD set.
 
 So the below lines are the *right* and most robust approch as far I can
 tell. (plus counter needs to be volatile, as every variable that can
 change under the C code, even while it's probably not required by the
 code involved with current-counter)
 
  +   {
  +   int counter = current-counter  1;
  +   current-counter = p-counter = counter;
  +   p-policy = ~SCHED_YIELD;
  +   current-policy |= SCHED_YIELD;
  +   current-need_resched = 1;
  +   }
 
 Alan, the patch you merged in 2.4.4ac2 can fail like mine, but it may fail in
 a much more subtle way, while I notice if ksoftirqd never get scheduled
 because I synchronize on it and I deadlock, your kupdate/bdflush/kswapd
 may be forked off correctly but they can all have SCHED_YIELD set and
 they will *never* get scheduled. You know what can happen if kupdate
 never gets scheduled... I recommend to be careful with 2.4.4ac2.
 

It looks like this is related to my problem (see thread [Re: Linux-2.4.4-ac2]).
Funtions __start_kernel called kernel_thread(init,...), and seems to hang
on cpu_idle().

-- 
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.4-ac1 #1 SMP Tue May 1 11:35:17 CEST 2001 i686

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



Re: isa_read/write not available on ppc - solution suggestions ??

2001-05-01 Thread Geert Uytterhoeven

On Tue, 1 May 2001 [EMAIL PROTECTED] wrote:
 To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the 
 isa_read/write's have to be changed to regular read/write due to the lack 
 of the isa_read/write functions for ppc.
 
 So, the question is should I simply:
 
 a) change everything to read/write and friends (the way the driver used to 
 be before the isa_read/write function were introduced)
 b) Put ugly macros in the driver to use the different functions depending 
 upon architecture.
 c) Implement the isa_read/write functions for ppc ? 
 or d) something completely different I haven't thought of. 

Please go for option c.

Also note that ISA memory space is not available on all PPC platforms.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds

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



Re: 2.4.3-ac9/4 - NFS corruption

2001-05-01 Thread Trond Myklebust

   == Raphael Manfredi [EMAIL PROTECTED] writes:

  My NFS client runs 2.4.3-ac4 (SMP).  My NFS server uses
  user-land NFS and runs 2.4.3-ac9 (UP).

  I've seens the following in my ~/mail/inbox, NFS mounted:

   ^@^@^@^@^@^@[EMAIL PROTECTED] Tue May 1 14:47:02
   2001

  On the server, the same line reads:

   From [EMAIL PROTECTED] Tue May 1 14:47:02 2001

  The above ^@ are NULL bytes, as displayed by vi.  The data
  around those NULL bytes were perfect, i.e. there was text
  before in the mailbox that was correct.

  An ls -l on the file yields:

   -rw--- 1 ram users 1642491 May 1 00:00 inbox

  (on the server, and via NFS), which is *abnormal*, since it's
  15:18 and I've just updated the file.  Therfore, the timestamp
  is corrupted as well in the inode.

In that case you have some other task that has done a 'touch' or
something to the file. An NFS client does not explicitly set the
timestamp when doing ordinary reading/writing to a file - it leaves it
to the server to do so.

  If I create a file, via  ~/mail/test on NFS, it reads:

   -rw-r--r-- 1 ram users 0 May 1 15:19 test

  with a proper timestamp.

  The NFS access is done via a symlink to an NFS-mounted dir,
  i.e. ~/mail is actually a symlink to /nfs/lyon/home/ram/mail.

  Any hint as to what is happening?  Is that a known problem?

Would you happen to be delivering mail to the same file on the server
or something like that?
If so it's completely normal behaviour: the userland NFS doesn't
support file locking, so there's no way that the client can guarantee
that some task on the server won't write to the file behind its
back...

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



Alpha reboot

2001-05-01 Thread Magnus Naeslund\(f\)

I saw the USB/Reboot thread.
I was wondering if you on alpha could specify any such parameter that makes
the kernel not go back to milo, but do a hard reboot instead.

I have a mylex raid card that can't handle to many soft reboots, it hangs.

cheers

Magnus

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Programmer/Networker [|] Magnus Naeslund
 PGP Key: http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


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



Re: iso9660 endianness cleanup patch

2001-05-01 Thread H. Peter Anvin

Linus Torvalds wrote:
 
 On Mon, 30 Apr 2001, H. Peter Anvin wrote:
 
  The attached patch fixes both.  It is against 2.4.4, but from the looks
  of it it should patch against -ac as well.
 
 Btw, please use static inline instead of extern inline, as gcc may
 decide not to inline the latter at all, leading to confusing link-time
 errors. (Gcc may also decide not to inline static inline, but then gcc
 will output the actual body of the function out-of-line if it gets used,
 so you don't get the link-time failure).
 
 Right now only certain broken versions of gcc will actually show this
 behaviour, I think, but it's at least in theory going to be an issue.
 

I guess I personally prefer an error over completely broken behaviour,
but feel free to change it.

-hpa

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



Re: iso9660 endianness cleanup patch

2001-05-01 Thread Albert D. Cahalan

Linus Torvalds writes:

 Btw, please use static inline instead of extern inline, as gcc may
 decide not to inline the latter at all, leading to confusing link-time
 errors. (Gcc may also decide not to inline static inline, but then gcc
 will output the actual body of the function out-of-line if it gets used,
 so you don't get the link-time failure).
 
 Right now only certain broken versions of gcc will actually show this
 behaviour, I think, but it's at least in theory going to be an issue.

Since the best choice depends on compiler version:

#if(GCC_VERSION_FOO)
#define __inline extern inline
#else
#define __inline static inline
#endif

(that, or _INLINE if you prefer)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



meept (was:Re: CML2 1.3.3 is available)

2001-05-01 Thread jdnfk kjhds

Yes, way too much!

The logo has changed to a microsoft certified tux now.

--- 
  If only VA Linux had a gonkulator! :-O
 
 Someone is watching WAY too much Hogan's Heroes
 
  They've issued their third earnings warning. I
 found
  the link on http://www.theGloriousMEEPT.com .  
 
 That sure looks like an Atari logo to me.
 

--- jdnfk kjhds [EMAIL PROTECTED] wrote:
 If only VA Linux had a gonkulator! :-O
 They've issued their third earnings warning. I found
 the link on http://www.theGloriousMEEPT.com .  
 
 
 --- Eric S. Raymond [EMAIL PROTECTED] wrote:
  The latest version is always available at
  http://www.tuxedo.org/~esr/cml2/
  
  Release 1.3.3: Sun Apr 29 23:00:33 EDT 2001
  * Resync with 2.4.4.
  * Help texts merged into symbols file; the
  `helpfile' declaration
is gone.  (Text is merged in from
  Documentation/Configure.help
at CML2 installation time.)
  * Tweaked the appearance of inactive help buttons
  by popular demand.
  
  My clever plan worked.  Less than three hours
 after
  I pronounced 1.3.1
  stable, somebody turned in the first crash bug
 in
  three weeks.  Fortunately
  it was pretty trivial to fix, a loose end from one
  of my speedups.  Fixed in
  yesterday's 1.3.2.
  
  The big news in this version is that all the help
  texts have been merged into
  the CML2 rules files.  A typical symbol
 declaration
  now looks like this:
  
  GONK_5523   'Support for B5523 adaptive gonkulator'
  text
  Say Y here to compile in support for the Bollix
 5523
  adaptive gonkulator.
  .
  
  Help texts are merged into the CML2 symbols file
 at
  CML2 installation time.
  The `helpfile' declaration is gone.  Among other
  things, this means you no
  longer need to run CML2 inside a kernel source
 tree;
  you can test the scripts 
  anywhere.
  -- 
  a href=http://www.tuxedo.org/~esr/;Eric S.
  Raymond/a
  
  See, when the GOVERNMENT spends money, it creates
  jobs; whereas when the money
  is left in the hands of TAXPAYERS, God only knows
  what they do with it.  Bake
  it into pies, probably.  Anything to avoid
 creating
  jobs.
  -- Dave Barry
  -
  To unsubscribe from this list: send the line
  unsubscribe linux-kernel in
  the body of a message to [EMAIL PROTECTED]
  More majordomo info at 
  http://vger.kernel.org/majordomo-info.html
  Please read the FAQ at  http://www.tux.org/lkml/
 
 
 __
 Do You Yahoo!?
 Yahoo! Auctions - buy the things you want at great
 prices
 http://auctions.yahoo.com/
 -
 To unsubscribe from this list: send the line
 unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at 
 http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/


__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: linux and high volume web sites

2001-05-01 Thread Sean Hunter

Also make sure you aren't suffering database lock contention from Mysql.  This
causes very fast context switching on the database server, and is typically
unable to do useful work even though its load avg is not high.  vmstat is
useful here.

Sean

On Sat, Apr 28, 2001 at 01:55:01PM -0700, Tim Moore wrote:
 David Lang wrote:
  
  watch the resonate heartbeat and see if it is getting lost in the network
  traffic (the resonate logs will show missing heartbeat packets). think
  seriously of setting the resonate stuff to run at a higher priority so
  that it doesn't get behind.
  
  depending on how high your network traffic is seriously look at putting in
  a second nic and switch to move the NFS traffic off the network that has
  the internet traffic and hearbeat.
  
  I had the same problem with central dispatch a couple years ago when first
  implementing it. the exact details of the problem that I ran into should
  have been fixed by now (mostly having to do with large number of virtual
  IP addresses) but the symptoms were the same.
 
 In addition to the above make sure there's enough bandwidth to the filer
 (eg- good switches, multiple ethernets).
 
 Consider moving to 2.2.19.  Significant VM changes after 2.2.19pre3 which
 could account for the freezes.
 
 rgds,
 tim.
 
   I have a high volume web site under linux :
   kernel is 2.2.17
   hardware is 5 bi-PIII 700Mhz / 512Mb, eepro100
   all server are diskless (nfs on an netapp filer) except for tmp and swap
  
   dispatch is done by the Resonate product
  
   web server is apache+php (something like 400 processes), database
   backend is a mysql on the same hardware
  
   in high volume from time to time machines are freezing then after a
   few seconds they reappear and response timne is
  
  
   how can I investigate all these problems ?
 
 --
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: 2.2.19 locks up on SMP

2001-05-01 Thread Alan Cox

 I think it started in 2.2.19pre10. I can reproduce the hang on pre10, 
 quite easily, but I couldn't reproduce it on pre5, pre7 and pre9. I'll try 
 a few other pre versions, just to make sure.

Ok the main candidates there would be:

The sunrpc/nfs changes
EEpro100/starfire
aic7xxx

which of those drivers are you using ?

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



Re: X15 alpha release: as fast as TUX but in user space

2001-05-01 Thread Ingo Molnar


On Sun, 29 Apr 2001, Fabio Riccardi wrote:

 I can disable header caching and see what happens, I'll add an option
 for this in the next X15 release.

what SPECweb99 performance do you get if you disable header caching? It
might not make all that much of a difference. (but it will make the
results more comparable with TUX.)

Ingo

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



Re: DPT I2O RAID and Linux I2O

2001-05-01 Thread Denis Perchine

On Tuesday 01 May 2001 08:22, Alan Cox wrote:
 A few people have asked about the dpt_i2o driver recently. If you have a
 DPT I2O card please try a late 2.4.3-ac kernel. It should now work when you
 do 'modprobe i2o_scsi'

Which cards are you talking about? Is SmartRAID V is in the list?

 After a lot of reviewing of the dpt driver I figured out what command was
 upsetting the beast and added a workaround for it. I also fixed a pile of
 bugs in the drivers that caused failed table queries to corrupt memory
 in some cases (the DPT tended to trigger these and so made the box reboot
 if you used i2oproc or i2oconfig.

 I'd also like to say thanks to DPT (now Adaptec) for supplying me with a
 card which meant that in combination with their driver I was eventually
 able to figure out the cure.

 More feedback from DPT i2o raid card users would be useful

 Alan

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

-- 
Sincerely Yours,
Denis Perchine

--
E-Mail: [EMAIL PROTECTED]
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: just-in-time debugging?

2001-05-01 Thread Sean Hunter

My approach is something like the others.  I developed a small wrapper to catch
unaligned traps on alpha.  What it does is run a program in gdb with some
specified arguments (it also sets up so that the process gets a SIGBUS when it
does an unaligned access, but that's probably not relevant here).

Any case, its available by anonymous ftp at ftp://uncarved.com/unaligned.c 
in case you're interested...

Sean

On Sat, Apr 28, 2001 at 09:17:10PM +0100, Tony Hoyle wrote:
 Is there a way (kernel or userspace... doesn't matter) that gdb/ddd
 could be invoked when a program is about
 to dump core, or perhaps on a certain signal (that the app could deliver
 to itself when required).  The latter case
 is what I need right now, as I have to debug an app that breaks
 seemingly randomly  I need to halt when
 certain assertions fail.  Core dumps aren't much use as you can't resume
 them, otherwise I'd just force a segfault
 or something.
 
 I had a look at the do_coredump stuff and it looks like it could be
 altered to call gdb in the same way that
 modprobe gets called by kmod... however I don't sufficiently know the
 code to work out whether it'd work properly
 or not.  
 
 A patch to glibc would perhaps be better, but I know that code even
 less!
 
 Something like responding to SIGTRAP would probably be ideal.
 
 Tony
 
 -- 
 
 Two weeks before due date, the programmers work 22 hour days cobbling an
  application from... (apparently) one programmer bashing his face into the
  keyboard. -- Dilbert
 
 [EMAIL PROTECTED]http://www.nothing-on.tv 
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Linux Kernel Debuggers, KDB or KGDB?

2001-05-01 Thread Aaron Passey

On Tue, 01 May 2001 11:16:50 +1000, Keith Owens [EMAIL PROTECTED] wrote:
kgdb relies on gdb so you loose the knowledge of kernel internals (no,
I am *not* going to teach gdb about kernel stacks, out of line lock
code etc.).  kgdb has more of a dependency on a working kernel.  It
provides source level debugging, although stack backtrace tends not to
work unless you compile the kernel with frame pointers.

UML is great for debugging generic kernel code such as filesystems, but
cannot be used for most arch code or hardware drivers.

My ideal debugger is one that combines the internal knowledge of kdb
with the source level debugging of gdb.  I know how to do this over a
serial line, finding time to write the code is the problem.

I've been thinking about this a little bit and I suspect the right thing
may be to combine a kgdb style debuging stub with the Mission Critical
Linux crash code (http://oss.missioncriticallinux.com/projects/crash/).
Crash is based around gdb and adds the ability to easily examine the
process table, memory maps, kernel logs, wait queues, timers, etc.  Crash
already is able to examine a live system by reading /dev/mem.  The only
thing you'd need to add is the ability to attach to a live system over a
serial port (probably not too hard since gdb already knows how to do that).

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



Re: 2.2.19 locks up on SMP

2001-05-01 Thread Ion Badulescu

On Tue, 1 May 2001, Alan Cox wrote:

 Ok the main candidates there would be:
 
   The sunrpc/nfs changes

I'm currently testing this one -- just preparing to reboot pre9 + these 
changes.

   EEpro100/starfire

eepro100 is in use. But that patch is harmless.

   aic7xxx

Loaded but not used, no devices attached to it.

Right now I'm pretty sure it's the NFS/SunRPC changes, but I'll know for 
sure in about 30 minutes.

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

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



Re: X15 alpha release: as fast as TUX but in user space

2001-05-01 Thread Ingo Molnar


On Mon, 30 Apr 2001, Fabio Riccardi wrote:

 Ok I fixed it, the header date timestamp is updated with every
 request.

 Performance doesn't seem to have suffered significantly (less than
 1%).

yep, expected that - doing a sendmsg()+sendfile() generates the same
packet structure, the only difference being that ~100-200 bytes are copied
between kernel-space and user-space.

Ingo

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



Re: 2.2.19 locks up on SMP

2001-05-01 Thread Ion Badulescu

On Tue, 1 May 2001, Ion Badulescu wrote:

  aic7xxx
 
 Loaded but not used, no devices attached to it.

Scratch that, I was confusing it with another box. There is no trace of 
aic7xxx on this system.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

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



Re: 2.2.19 locks up on SMP

2001-05-01 Thread Ion Badulescu

On Tue, 1 May 2001, Ion Badulescu wrote:

 Right now I'm pretty sure it's the NFS/SunRPC changes, but I'll know for 
 sure in about 30 minutes.

As I suspected, 2.2.19pre9 + the NFS/SunRPC changes locked up under load 
with the now familiar:

wait_on_bh, CPU 2:
irq:  1 [0 0]
bh:   1 [0 1]
[8010af71] 

This time it happened precisely when I ran a ls -lR on a large tree over 
NFS, so I'm pretty sure this is it.

I'll do another test, 2.2.18 + the NFS/SunRPC changes, and see how it 
goes. Hopefully they'll apply easily...

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

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



Re: traceroute breaks with 2.4.4

2001-05-01 Thread Anuradha Ratnaweera


Isn't it kernel-user netlink socket?

Anuradha

On Sun, 29 Apr 2001, David Konerding wrote:

 David Konerding wrote:
 
  As far as I can tell, somewhere between 2.4.2 and 2.4.4, traceroute
  stopped working.
  I see the problem on RH7.x.  Regular kernel compile with near-defaults
  for networking,
  no firewalling is enabled.  Rebootiing to a similar config under 2.4.2
  works OK.
 
 OK, I'm unable to fix this by reverting to 2.4.2 using the same config as
 2.4.2.
 However, an older compiled 2.4.2 worked, so I think I must have changed
 some configuration which affects it.  Can't for the life of me figure out what
 it is,
 tho'.
 
 Dave
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 

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



Re: [kbuild-devel] [PATCH] automatic multi-part link rules (fwd)

2001-05-01 Thread Kai Germaschewski

On Tue, 1 May 2001, J . A . Magallon wrote:

 On 05.01 Keith Owens wrote:
 
  The patch appears to work but is it worth applying now?  The existing
  2.4 rules work fine and the entire kbuild system will be rewritten for
  2.5, including the case you identified here.  It struck me as a decent
  change but for no benefit and, given that the 2.4 kbuild system is so
  fragile, why not live with something we know works until 2.5 is
  available?

Well, yes, that's an argument. However, I don't think it's hard to verify
that my patch works as well, it's about ten lines added to Rules.make.
It's particularly easy to verify that it doesn't change behavior for
objects listed in $(list-multi) at all.

 We will have to live with 2.4 until 2.6, 'cause 2.5 will not be stable.
 2.4 will be the stable and non brain damaged kernel in distros.
 So every thing that can make 2.4 more clean, better. Think in 2.4.57,
 and we still are in 4. And feature backports, and new drivers...
 The 2.5 rewrite is not excuse. The knowledge on the actual state, yes.

Yes, 2.4 will be around for a long time from now. Of course, no
experimental changes should be done now, but cleanup patches are applied
all the time now. Or are you arguing that we shouldn't include patches
which fix the compiler warnings either, just because it's proven that the
current behavior works?

Anyway, I also have the additional argument that the patches fixes at
least theoretical bugs, because it adds flags handling for the link rules.
I don't know if it ever happens, but one can imagine a case where foo-objs
= foo1.o foo2.o, or foo-objs = foo1.o foo2.o foo3.o, respectively,
depending on some config option. So if you go from the latter config to
the former and rebuild, foo.o won't get relinked, you end up with the old
version.

Also, the patch allows you to rewrite e.g. fs/ext2/Makefile from
---
obj-y:= acl.o balloc.o bitmap.o dir.o file.o fsync.o ialloc.o inode.o \
ioctl.o namei.o super.o symlink.o
obj-m:= $(O_TARGET)
---
to
---
obj-$(CONFIG_EXT2_FS)   += ext2.o

ext2-objs   := acl.o balloc.o bitmap.o dir.o file.o fsync.o \
   ialloc.o inode.o ioctl.o namei.o super.o symlink.o
---

which fixes another fragile aspect of the current Makefiles, which you
complained about yourself: make SUBDIRS=fs/ext2 is currently broken w.r.t
to compilation flags.

--Kai




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



Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]

2001-05-01 Thread Giacomo A. Catenazzi

Eric S. Raymond wrote:
 
 Peter Samuelson [EMAIL PROTECTED]:
  [esr]
   Besides, right now the configurator has a simple invariant.  It will
   only accept consistent configurations
 
  So you are saying that the old 'vi .config; make oldconfig' trick is
  officially unsupported?  That's too bad, it was quite handy.
 
 Depends on how you define `unsupported'.  Make oldconfig will tell you
 exactly and unambiguously what was wrong with the configuration.  I think
 if you're hard-core enough to vi your config, you're hard-core enough to
 interpret and act on
 
 This configuration violates the following constraints:
 (X86 and SMP==y) implies RTC!=n
 
 without needing some wussy GUI holding your hand :-).

I think that a fundamental requirment is that 'make oldconfig' should
validate any configurations (also the wrong conf).
(If you correct your rules, our old .config can be invalid on a new
kernel, and we don't want regualary edit our .config).

My proposal is instaed of complain about configuration violatation,
you just wrote the possible correct configuration and prompt user to
select the correct configuration.
In the case you cite, e.g. oldconfig shoud prompt:
  1) SMP=n
  2) RTC=m
  3) RTC=y
(assuming the ARCH is invariant).

To simplify your life you can require only tty (or ev. also menu mode)
for
there question. User normally use oldconfig in tty mode for simplicity
(there
are normally only few questions, thus is simple to have the question
already
in order, without to perse nearly empy menus).

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



Re: [PATCH] adding PCI bus information to SCSI layer

2001-05-01 Thread Ingo Oeser

On Mon, Apr 30, 2001 at 07:27:13PM -0600, Richard Gooch wrote:
 Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0

What about /dev/bus/pci/0 or /dev/bus/pci/pci0 instead?

That way we could hook roots of busses (which are . nodes, like
if they where mounted independently) better into /dev/bus.

And even implement the thing as a mount point later, if we go the way
Al Viro suggested and have independent device filesystems
for the subsystems themselves.

Just an idea...

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
  been there and had much fun   
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: X15 alpha release: as fast as TUX but in user space

2001-05-01 Thread Ingo Molnar


hm, another X15 caching artifact i noticed: i've changed the index.html
file, and while X15 was still serving the old copy, TUX served the new
file immediately.

its cache is apparently not coherent with actual VFS contents. (ie. it's a
read-once cache apparently?) TUX has some (occasionally significant)
overhead due to non-cached VFS-lookups.

Ingo

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



Re: CANBus driver.

2001-05-01 Thread Anders Peter Fugmann

Hi Mark.

Thanks for your reply - its nice to hear the there is some interrest in 
out project.

Clayton, Mark wrote:

 I am always interested in CAN stuff on Linux.  Where can I find
 more info in the card you plan to use?  

See: http://www.kvaser.se

We will contact Kvaser to get the technical Specification. I cannot 
guarantee that we will be allowed to publish it, but if we are and you 
are interrested, i can send you a link when and if we get it.


I don't have many ISA
 slots left, so if decide to find a different card, make it PCI.
 I have a Infineon based reference board at home around which I 
 plan to develop a few software projects.

We have no influence on the card itself, I'm afaid. But we will stridt 
to make it very easy to change the hardware driver.

The driver we want to implement, is actually several drivers.
Since the CANBus is a bus, it is natual (for us) to implement it as 
such, so that it will be possible to load drivers on top of the hardware 
driver, which can communicate with specific hardware on the bus.


 
 BTW, there are CAN drivers for several chip.  I have urls at home.
 I can send them to you in a few days.  Assuming I still have them.

I'm still very interrested.


 
 Mark
 --
 Mark Clayton   [EMAIL PROTECTED]
 NetPlane Systems Inc   http://www.netplane.com
 888 Washington Street  Tel: (781) 329-3200 x5355
 Dedham MA 02026Fax: (781) 329-4148
 --
 [root@hjinc mclayton] /sbin/insmod stddisclaimer.o
 



Regards
Anders Fugmann

 

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



Re: 2.2.19 locks up on SMP

2001-05-01 Thread Ion Badulescu

On Tue, 1 May 2001, Ion Badulescu wrote:

 I'll do another test, 2.2.18 + the NFS/SunRPC changes, and see how it 
 goes. Hopefully they'll apply easily...

As I suspected, 2.2.18 + all the NFS/NFSd/SunRPC changes present in 
2.2.19pre10 locks up with wait_on_bh as soon as I run ls -lR on a large 
NFS directory tree, while at the same time pummeling the network and the 
local disks.

NFS is not enough to trigger the bug, the extra disk/network stress *is*
necessary. The network stress actually seems to be enough, I just 
triggered the bug again...

2.2.18 vanilla is fine.

So I guess the next round is in Trond's court. :-)

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.



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



Re: Linux Kernel Debuggers, KDB or KGDB?

2001-05-01 Thread Ingo Oeser

On Mon, Apr 30, 2001 at 07:11:35PM -0500, Jeff Dike wrote:
 [EMAIL PROTECTED] said:
  Where can I find an analysis of the relative strengths and weaknesses
  of KDB and KGDB for kernel debug? Has the linux community come to any
  consensus regarding the utility one or the other? 
 
 You ought to add UML to the list, since it is useful for
 debugging any part of the kernel that's not arch code or a
 hardware device driver (except that there's now USB support for
 UML).

Basically you could add support for ALL generic subsystems, that
support dummy hardware, like SCSI and ISDN for example.

Is that planned or do I suggest sth. stupid here? ;-)

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
  been there and had much fun   
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: iso9660 endianness cleanup patch

2001-05-01 Thread Tim Riker

hpa,

I'd remove the __BIG_ENDIAN test cases if I were you. Having written
many a iso9660 decoder I will tell you that the required bi-endian
implementation is sometimes broken as many vendors only test CDs with a
certain single endian OS. I've seen these set to 0s, or -1 or just a
copy of the le data byte for byte. I opened many a bug report with the
different CD formatting software vendors, some fixed them, many didn't
care. The extra savings does not justify the hassles IMHO.

The other changes look great!

Tim

H. Peter Anvin wrote:
 
 Hi guys,
 
 I was looking over the iso9660 code, and noticed that it was doing
 endianness conversion via ad hoc *functions*, not even inlines; nor did
 it take any advantage of the fact that iso9660 is bi-endian (has all
 data in both bigendian and littleendian format.)
 
 The attached patch fixes both.  It is against 2.4.4, but from the looks
 of it it should patch against -ac as well.
 
 -hpa
-- 
Tim Riker - http://rikers.org/ - short SIGs! g
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Linux 2.4.4-ac2

2001-05-01 Thread Alan Cox


ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/

Intermediate diffs are available from

http://www.bzimage.org

This release is mostly meant for further eyes to check for merge errors. It
boots but thats about all I'd guarantee. I plan to do just the fixups for
2.4.4 bugs and then back out some of the existing changes that don't help
much - notably some of the VM tuning isnt gaining us anything but multiple
bad implementations.

2.4.4-ac2
o   Remove some spurious whitespace differences (me)
between trees
o   Make the VIA timer reload check test avoid  (me)
tripping on a timer as it rolls back to zero
o   Drop dasdfmt man page changes (dos ^M noise)(me)
o   Drop experimental iee1284 pnp module loading(me)
o   Revert pcnet32 chance causing compile errors(me)
o   Remove wrong __init in sunhme   (Dave Miller)
o   Fix overlarge udely in aironet4500  (Arjan van de Ven)
o   Remove non existant parameter from aironet4500  (Keith Owens)
o   Kill duplicate aic7xxx include  (Andrzej Krzysztofowicz)
o   Fix pci2220i scsi compile bug   (Matt Domsch)
o   Fix module exception race on Alpha  (Andrea Arcangeli)
o   Disable broken large vmalloc support on Alpha   (Andrea Arcangeli)
o   Remove dead ia64 config entries (Steven Cole)
o   Add kbuild list info to MAINTAINERS (Steven Cole)
o   linux appletalk list has moved  (Arnaldo Carvalho de Melo)
o   Revert wrong mount changes in 2.4.4 (Andries Brouwer)
o   Revert drivers/scsi/scsi.c change in 2.4.4  (me)
that subtly broke about 15 drivers
o   Fix typo in slab.h  (Pavel Machek)
o   More correct child favouring fork behaviour (Peter Österlund)
o   Only apply pci fixups if there is a VIA 686B(Charl Botha)
o   Fix GDT padding error introduced by PnPBIOS (Brian Gerst)
support
o   Fix UML build without CONFIG_PT_PROXY   (Jeff Dike)
o   dmfe wasnt calling dev_alloc_skb(Tobias Ringstrom)
o   Further Configure.help fixups   (Steven Cole)
o   Move pci_enable_device earlier in trident   (Marcus Meissner)

2.4.4-ac1
o   Merge with Linus 2.4.4
| This wasnt entirely trivial so this is the only
| stuff in this patch
| The following stuff has been switched to the Linus branch
| in the merge: uhci, dcache atomicity, raw I/O

2.4.3-ac14
o   Merge read-only vxfs reading support(Christoph Hellwig)
o   Fix missing return in broken_apm_power  (Alex Riesen)
o   Remove bogus rwsem hacks from usbdevice_fs.h(Alex Riesen)
o   Fix umount/sync_inodes race (Al Viro)
o   Make new xircom driver report when promisc used (Arjan van de Ven)
o   Fix acenic PCI flag set up  (Phil Copeland)
o   Make nfs smart about passing max file sizes (Trond Myklebust)
o   Add initrd support to User Mode Linux   (Jeff Dike)
o   Fix timer irq race in User Mode Linux   (Jeff Dike)
o   Fix UML for semaphore changes   (Jeff Dike)
o   Update thw W9966 parallel port camera driver(Jakob Kemi)
o   Further dmfe SMP fixups (Tobias Ringstrom)
o   Kernel manual pages in man9 (Tim Waugh)
o   Work around BIOSes that implement E801 sizing
but don't implement the CX/DX values part   (Michael Miller)
o   Fix atp driver build(Arjan van de Ven)
o   Fix irda poll handling  (Dag Brattli)
o   Remove unused buggy pdc202xx code   (Arjan van de Ven)
o   Clean up iphase ATM (Arnaldo Carvalho
de Melo)
o   Setup slave PDC20265 controller on fasttrak (Arjan van de Ven)
as normal IDE
o   Add __init/__initdata to most net driver   (Andrzej Krzysztofowicz)
version info
o   SDDR09 config entry was missing (Phil Stracchino)
o   Configure.help NFS updates (Andrzej Krzysztofowicz)
o   Netfilter updates   (Rusty Russell and co)
o   Update 2.4 ipconfig to support dhcp (Eric Biederman)
o   es1371 setup updates/error check/pci bits   (Marcus Meissner)
o   Fix buzzing ymfpci  (Nick Brown)
o   Update nm256 audio driver   (Marcus Meissner)
o   Blacklist updates   (Arjan van de Ven)

2.4.3-ac13
o   Switch to NOVERS symbols for rwsem  (me)
| Called from asm blocks so they can't be versioned
o   Fix gcc 2.95 building 

DISCOVERED! Cause of Athlon/VIA KX133 Instability

2001-05-01 Thread Seth Goldberg

Ok, so the subject is an attention-getter :).

Peep this, homies:

Hi,

  I've been doing some research, trying to figure out why the VIA/Athlon
is exhibiting weird behavior under K7 optimizations.  The jist of my 
research is that compiling a kernel for ANY CPU with the Athlon MMX
optimization
*AND* 3DNOW results in massive amounts of oops'es and total system
instability.  The following is what I've tried:

  [1] Selected Athlon as CPU in .config, then commenting out (#if 0) 
  the mmx code optimized for the athlon (as was stated is the only
  main k7 opt).  The resulting kernel is stable.  enabling/disabling
  other options have no effect on stability.

  [2] Experimented with choosing K6-(III) optimized kernel, but
modifying
  the arch/i386/config.in to sequentially add to the K6 section all
the
  options in the K7 section (i.e. GOOD_APIC, USE_3DNOW,
L1_CACHE_SHIFT
  difference, and PGE).  So far, the only anomolay I've found is
that
  when I add USE_3DNOW to the K6 section and reboot, KDE hangs when
  I click on any button in my launch bar (vanilla KDE 2.0).  It
  does NOT hang the system, though.  Restarting Xwindows does not
help,
  but changing the WM to TWM allows me to run netscape (which was
one
  of the buttons that hund X in KDE in the launch bar). Weird,
right?
  Enabling paging extensions (CONFIG_X86_PGE) appears to have
  no effect on stability.

  [3] When I add 3DNOW to any option in [2] w/ the Athlon MMX opt,
  the instability is evident after root is mounted and startup
  scripts begin executing.  Sometimes the system can make it through
  other times it cannot.

Athlon 900 (990) Thunderbird
IWILL KK-266 M/B
256MB PC100 RAM
Promise Ultra66 IDE
SB Live
GeForce 256 (AGP)

My info (dmesg):

Linux version 2.4.4 (root@c1162825-a) (gcc version 2.95.3 20010315
(release)) #6 SMP Sun Apr 29 04:31:06 PDT 2001
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 0fff (usable)
 BIOS-e820: 0fff - 0fff3000 (ACPI NVS)
 BIOS-e820: 0fff3000 - 1000 (ACPI data)
 BIOS-e820:  - 0001 (reserved)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
Scan SMP from c009fc00 for 4096 bytes.
On node 0 totalpages: 65520
zone(0): 4096 pages.
zone(1): 61424 pages.
zone(2): 0 pages.
mapped APIC to e000 (01444000)
Kernel command line: BOOT_IMAGE=LInux ro root=302
Initializing CPU#0
Detected 993.350 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1979.18 BogoMIPS
Memory: 255644k/262080k available (846k kernel code, 6048k reserved,
334k data, 188k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff  
CPU: After generic, caps: 0183f9ff c1c7f9ff  
CPU: Common caps: 0183f9ff c1c7f9ff  
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED])
mtrr: detected mtrr type: Intel
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff  
CPU: After generic, caps: 0183f9ff c1c7f9ff  
CPU: Common caps: 0183f9ff c1c7f9ff  
CPU0: AMD Athlon(tm) Processor stepping 02
per-CPU timeslice cutoff: 731.63 usecs.
SMP motherboard not detected. Using dummy APIC emulation.
Setting commenced=1, go go go
PCI: PCI BIOS revision 2.10 entry at 0xfb240, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
Applying VIA PCI latency patch.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 169848kB/56616kB, 512 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed 

Re: Linux Kernel Debuggers, KDB or KGDB?

2001-05-01 Thread Amit S. Kale

Hi,

I mostly agree with Keith.

kdb and kgdb have similar capabilities. kgdb can be used
to do kdb like assembly level debugging too, though it
needs some knowledge of gdb and kgdb internals.

You can analyze any problems with either of the debuggers.
You'll need to decide which debugger to go for depending
on your requirements.

I've got many queries asking kgdb capabilities.
I guess it's time for a webpage comparing the two
debuggers. People who are new to linux kernel and
have not used any of the debuggers can hardly arrive
at a decision as to which debugger is better suited for
their work.

I always suggest for kgdb over kdb because, IMO source
level debugging makes a programmers life much easier.

UML too is a good kernel debugging tool. It offers
the advantage of source level debugging on a single
machine. IMHO it's more useful for beginners.

Keith Owens wrote:
 
 On Mon, 30 Apr 2001 16:17:22 -0500,
 Paul J Albrecht [EMAIL PROTECTED] wrote:
 Where can I find an analysis of the relative strengths and weaknesses of KDB
 and KGDB for kernel debug? Has the linux community come to any consensus
 regarding the utility one or the other?
 
 kdb is a really low level debugger which understands the kernel
 structures.  It does its utmost to stop all kernel activity while it is
 running and to use as few kernel services as possible so it can run
 even when the kernel is dead.  It (currently) has no source level
 debugging.
 
 kgdb relies on gdb so you loose the knowledge of kernel internals (no,
 I am *not* going to teach gdb about kernel stacks, out of line lock
 code etc.).  kgdb has more of a dependency on a working kernel.  It
 provides source level debugging, although stack backtrace tends not to
 work unless you compile the kernel with frame pointers.
 
 UML is great for debugging generic kernel code such as filesystems, but
 cannot be used for most arch code or hardware drivers.
 
 My ideal debugger is one that combines the internal knowledge of kdb
 with the source level debugging of gdb.  I know how to do this over a
 serial line, finding time to write the code is the problem.
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

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



Test. Please ignore.

2001-05-01 Thread Seth Goldberg

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



Re: 2.4.4: Kernel crash, possibly tcp related

2001-05-01 Thread Andrea Arcangeli

On Mon, Apr 30, 2001 at 09:00:09PM +0400, [EMAIL PROTECTED] wrote:
 Hello!
 
  My current theory is that tcpblast does something erratic when the
  error occurs.
 
 It has buffer size of 32K, so that it faults at enough large chunk sizes.
 
 Erratic errno is because this applet prints errno on partial write.
 
 Oops is apparently because I did something wrong in do_fault yet.
 Seems, you were right telling that this place looks dubious. 8)

this is the strict fix:

diff -urN z/net/ipv4/tcp.c z1/net/ipv4/tcp.c
--- z/net/ipv4/tcp.cTue May  1 12:14:14 2001
+++ z1/net/ipv4/tcp.c   Tue May  1 12:12:35 2001
@@ -1184,7 +1184,7 @@
 do_fault:
if (skb-len==0) {
if (tp-send_head == skb) {
-   tp-send_head = skb-prev;
+   tp-send_head = skb-next;
if (tp-send_head == (struct sk_buff*)sk-write_queue)
tp-send_head = NULL;
}


really the logic can be implemented more efficiently this way:

--- 2.4.4aa3/net/ipv4/tcp.c.~1~ Tue May  1 10:44:57 2001
+++ 2.4.4aa3/net/ipv4/tcp.c Tue May  1 12:00:25 2001
@@ -1183,11 +1183,8 @@
 
 do_fault:
if (skb-len==0) {
-   if (tp-send_head == skb) {
-   tp-send_head = skb-next;
-   if (tp-send_head == (struct sk_buff*)sk-write_queue)
-   tp-send_head = NULL;
-   }
+   if (tp-send_head == skb)
+   tp-send_head = NULL;
__skb_unlink(skb, skb-list);
tcp_free_skb(sk, skb);
}

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



Re: X15 alpha release: as fast as TUX but in user space (fwd)

2001-05-01 Thread Pavel Machek

Hi!

   In x86-64 there are special vsyscalls btw to solve this problem that export
   a lockless kernel gettimeofday()
  
  Whatever happened to that hack that was discussed a year or two ago?
  The one where (also on IA32) a magic page was set up by the kernel
  containing code for fast system calls, and the kernel would write
  calibation information to that magic page. The code written there
  would use the TSC in conjunction with that calibration data.
  
  There was much discussion about this idea, even Linus was keen on
  it. But IIRC, nothing ever happened.
  
 
 We discussed this at the Summit, not a year or two ago.  x86-64 has
 it, and it wouldn't be too bad to do in i386... just noone did.

Just wait what kind of problems it is able to bring on i386.

Pavel
PS: Hmm, how do you do timewarp for just one userland appliation with
this installed?

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



Followup to previous post: Atlon/VIA Instabilities

2001-05-01 Thread Seth Goldberg

Hi,

  So it seems that CONFIG_X86_USE_3DNOW is simply used to
enable access to the routines in mmx.c (the athlon-optimized
routines on CONFIG_K7 kernels), so then it appears that somehow
this is corrupting memory / not behaving as it should (very
technical, right?) :)...

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



Re: Aironet doesn't work

2001-05-01 Thread Elmer Joandi

On Mon, 30 Apr 2001, Jeff Garzik wrote:
 Not correct -- you do not need I82365 if you have CardBus.  However, if
 you are running 2.4.4 you should be ok.


So it is nice I dont have to prove it.

Never seen cardbus laptop with linux yet.

( But Mandrake can send me one :) )

Elmer.


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



linux-2.4.4aa1 and 2.4.4aa2

2001-05-01 Thread G. Hugh Song

To all in the mailing list,

I have been testing Andrea Arcangeli's kernel patches for 
Linux/Alpha on a UP2000 SMP with 2GB memory running
SuSE-7.0 with all the latest updates from the official 
SuSE site, but with xfree86-3.6.6.

Xfree-4.0.1 does not work for the 3DLabs card I have.

Under 2.4.4aa1, the X does not start as if some important 
pieces of X are not readable.   Under 2.4.4aa2, the machine 
doe not boot showing the following message in the end:

Linux NET4.0 for Linux 2.4
Based upon Swansea University .. NET3.039
Initializing RT netlink socket

I guess that something is wrong with the socket handling 
in both versions.  Or, the trouble may originally exist in the 
linux-2.4.4 rather than in the aa-patches.  I really don't know.
BTW, I attached below my .config files.  However, due to recent 
flurries of messages regarding a bug in fork.c, I did not 
try the original 2.4.4.

Those two config files are really similar 
to the one that Andrea is actually using for his patch development.

I now backed down to linux-2.4.3-ac14, (alan's patch to 2.4.3).

BTW, the -pre versions are officially maintained by Linus, 
while the -ac versions are maintained by Alan.  What is special
in the -ac versions?I see them trying to converge.  But 
I'd like to know exactly what is actually being tried in the 
-ac versions.


Best regards,

-- 
G. Hugh Song
 xconfig-2.4.4aa1
 xconfig-2.4.4aa2


Re: 2.2.19 locks up on SMP

2001-05-01 Thread Trond Myklebust

   == Ion Badulescu [EMAIL PROTECTED] writes:

  On Tue, 1 May 2001, Ion Badulescu wrote:
 I'll do another test, 2.2.18 + the NFS/SunRPC changes, and see
 how it goes. Hopefully they'll apply easily...

  As I suspected, 2.2.18 + all the NFS/NFSd/SunRPC changes
  present in 2.2.19pre10 locks up with wait_on_bh as soon as I
  run ls -lR on a large NFS directory tree, while at the same
  time pummeling the network and the local disks.

  NFS is not enough to trigger the bug, the extra disk/network
  stress *is* necessary. The network stress actually seems to be
  enough, I just triggered the bug again...

  2.2.18 vanilla is fine.

  So I guess the next round is in Trond's court. :-)

Did you apply the following patch which I put out on the lists a
couple of weeks ago?

Cheers,
  Trond

--- net/sunrpc/xprt.c.orig  Sun Mar 25 18:37:42 2001
+++ net/sunrpc/xprt.c   Wed Apr 18 11:10:21 2001
@@ -1145,9 +1145,11 @@
unsigned long   oldflags;
spin_lock_irqsave(xprt_sock_lock, oldflags);
xprt-snd_task = NULL;
-   if (!rpc_wake_up_next(xprt-sending)  xprt-stream)
+   if (!rpc_wake_up_next(xprt-sending)  xprt-stream) {
+   spin_unlock_irqrestore(xprt_sock_lock, oldflags);
xprt_add_tcp_timer(xprt, RPCXPRT_TIMEOUT);
-   spin_unlock_irqrestore(xprt_sock_lock, oldflags);
+   } else
+   spin_unlock_irqrestore(xprt_sock_lock, oldflags);
}
 }
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: 2.2.19 locks up on SMP

2001-05-01 Thread Ion Badulescu

On Tue, 1 May 2001, Trond Myklebust wrote:

 Did you apply the following patch which I put out on the lists a
 couple of weeks ago?

No, I was testing with 2.2.19 and then I started going back into the 
2.2.19pre series until I found the culprit.

I'll give your patch a spin tomorrow, after I catch some zzz's. :-)

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.

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



New rtl8139 driver prevents ssh from exiting.

2001-05-01 Thread Rob Landley

The kernel thread the new rtl8139 driver spawns
apparently wants to write to stdout, because it counts
as an unfinished process that prevents an ssh session
from exiting.

I have a script that remotely reconfigures subnets in
a vpn, which gets run via an ssh in through eth0 and
does, among other things:

ifconfig eth1 down
ifconfig eth1 up

Hence kicking off the thread.  I have to run killall
eth1 at the end of the script to make ssh exit. 
(This doesn't seem to have any negative impact on
eth1's functioning.)

Anybody feel like shedding light on this?

Rob

__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

2001-05-01 Thread Alan Cox

   when I add USE_3DNOW to the K6 section and reboot, KDE hangs when
   I click on any button in my launch bar (vanilla KDE 2.0).  It
   does NOT hang the system, though.  Restarting Xwindows does not
 help,

The K6 USE_3DNOW has two problems

1.  It doesnt work on a CPU with fxsave (my bug and its fixed in -ac)
2.  Its not a performance win. 

#2 doesn't matter for testing

   [3] When I add 3DNOW to any option in [2] w/ the Athlon MMX opt,
   the instability is evident after root is mounted and startup
   scripts begin executing.  Sometimes the system can make it through
   other times it cannot.

And I still have no problem reporters with non VIA chipsets

Alan

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



Re: linux-2.4.4aa1 and 2.4.4aa2

2001-05-01 Thread Alan Cox

 BTW, the -pre versions are officially maintained by Linus, 
 while the -ac versions are maintained by Alan.  What is special
 in the -ac versions?I see them trying to converge.  But 
 I'd like to know exactly what is actually being tried in the 
 -ac versions.

Your best guide is the change lists I post and the diff itself. In terms
of the problem you report I can't see any networking changes that could
be relevant between vanilla and -ac.

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



Re: Followup to previous post: Atlon/VIA Instabilities

2001-05-01 Thread Alan Cox

   So it seems that CONFIG_X86_USE_3DNOW is simply used to
 enable access to the routines in mmx.c (the athlon-optimized
 routines on CONFIG_K7 kernels), so then it appears that somehow
 this is corrupting memory / not behaving as it should (very
 technical, right?) :)...

Feel free to go over those routines in detail by hand. I've been over them and
I can't see any problems. The obvious candidates would be races in the
kernel_fpu_begin/end code but that also seems watertight to me.

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



2.4.3-ac9/4 - NFS corruption

2001-05-01 Thread Raphael Manfredi

My NFS client runs 2.4.3-ac4 (SMP).
My NFS server uses user-land NFS and runs 2.4.3-ac9 (UP).

I've seens the following in my ~/mail/inbox, NFS mounted:

^@^@^@^@^@^@[EMAIL PROTECTED]  Tue May  1 14:47:02 2001

On the server, the same line reads:

From [EMAIL PROTECTED]  Tue May  1 14:47:02 2001

The above ^@ are NULL bytes, as displayed by vi.
The data around those NULL bytes were perfect, i.e. there was text before
in the mailbox that was correct.

An ls -l on the file yields:

-rw---1 ram  users 1642491 May  1 00:00 inbox

(on the server, and via NFS), which is *abnormal*, since it's 15:18 and
I've just updated the file.  Therfore, the timestamp is corrupted as well
in the inode.

If I create a file, via  ~/mail/test on NFS, it reads:

-rw-r--r--1 ram  users   0 May  1 15:19 test

with a proper timestamp.

The NFS access is done via a symlink to an NFS-mounted dir, i.e. ~/mail
is actually a symlink to /nfs/lyon/home/ram/mail.

Any hint as to what is happening?  Is that a known problem?

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



Re: New rtl8139 driver prevents ssh from exiting.

2001-05-01 Thread Andrew Morton

Rob Landley wrote:
 
 The kernel thread the new rtl8139 driver spawns
 apparently wants to write to stdout, because it counts
 as an unfinished process that prevents an ssh session
 from exiting.

Does this help?


--- linux-2.4.4-pre3/kernel/sched.c Sun Apr 15 15:34:25 2001
+++ linux-akpm/kernel/sched.c   Mon Apr 16 20:40:47 2001
@@ -32,6 +32,7 @@
 extern void timer_bh(void);
 extern void tqueue_bh(void);
 extern void immediate_bh(void);
+extern struct task_struct *child_reaper;
 
 /*
  * scheduler variables
@@ -1260,32 +1261,53 @@
 /*
  * Put all the gunge required to become a kernel thread without
  * attached user resources in one place where it belongs.
+ *
+ * Kernel 2.4.4-pre3, andrewm#uow.edu.au: reparent the caller
+ * to init and set the exit signal to SIGCHLD so the thread
+ * will be properly reaped if it exist.
  */
 
 void daemonize(void)
 {
struct fs_struct *fs;
-
+   struct task_struct *this_task = current;
 
/*
 * If we were started as result of loading a module, close all of the
 * user space pages.  We don't need them, and if we didn't close them
 * they would be locked into memory.
 */
-   exit_mm(current);
+   exit_mm(this_task);
 
-   current-session = 1;
-   current-pgrp = 1;
+   this_task-session = 1;
+   this_task-pgrp = 1;
 
/* Become as one with the init task */
 
-   exit_fs(current);   /* current-fs-count--; */
+   exit_fs(this_task); /* this_task-fs-count--; */
fs = init_task.fs;
-   current-fs = fs;
+   this_task-fs = fs;
atomic_inc(fs-count);
-   exit_files(current);
-   current-files = init_task.files;
-   atomic_inc(current-files-count);
+   exit_files(this_task);  /* this_task-files-count-- */
+   this_task-files = init_task.files;
+   atomic_inc(this_task-files-count);
+
+   write_lock_irq(tasklist_lock);
+
+   /* Reparent to init */
+   REMOVE_LINKS(this_task);
+   this_task-p_pptr = child_reaper;
+   this_task-p_opptr = child_reaper;
+   SET_LINKS(this_task);
+
+   /* Set the exit signal to SIGCHLD so we signal init on exit */
+   if (this_task-exit_signal != 0) {
+   printk(KERN_ERR task `%s' exit_signal %d in daemonize()\n,
+   this_task-comm, this_task-exit_signal);
+   }
+   this_task-exit_signal = SIGCHLD;
+
+   write_unlock_irq(tasklist_lock);
 }
 
 void __init init_idle(void)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



[patch] 2.4.4-ac2 freexvfs

2001-05-01 Thread Keith Owens

fs/Makefile requires that any filesystem which can be compiled as a
module must have O_TARGET set to the directory name.  Against 2.4.4-ac2.

Index: 4.8/fs/freevxfs/Makefile
--- 4.8/fs/freevxfs/Makefile Tue, 01 May 2001 23:35:00 +1000 kaos 
(linux-2.4/d/e/32_Makefile 1.1 644)
+++ 4.8(w)/fs/freevxfs/Makefile Tue, 01 May 2001 23:38:19 +1000 kaos 
+(linux-2.4/d/e/32_Makefile 1.1 644)
@@ -2,7 +2,7 @@
 # VxFS Makefile
 #
 
-O_TARGET :=vxfs.o
+O_TARGET :=freevxfs.o
 
 obj-y :=   vxfs_bmap.o vxfs_fshead.o vxfs_immed.o vxfs_inode.o \
vxfs_lookup.o vxfs_olt.o vxfs_subr.o vxfs_super.o

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



PROBLEM: 2.4.4, 2.4.4-ac1, 2.4.4-ac2, neighbour discovery bug (ipv6)

2001-05-01 Thread Cliff Albert


When i traceroute6 my 2.4.4 box on my local lan, the 2.4.4 box panic's after about 10 
seconds. The traceroute6 completes on the other box.

2.4.3-ac14 doesn't experience these problems. Only 2.4.4 (with or without ac{1,2}) 
panics

 traceroute6 output 
traceroute to neve.oisec.net (3ffe:8114:2000:0:250:bfff:fe21:629a) from 
3ffe:8114:2000:0:210:4bff:feb3:1fb4, 30 hops max, 16 byte packets
 1  neve.oisec.net (3ffe:8114:2000:0:250:bfff:fe21:629a)  0.583 ms  0.278 ms  0.233 ms


wait 10 seconds and the following appears (unfortunately no stack dumps :()

 panic info 2.4.4-ac2 
CPU 0
EIP 0010:[c0217314]
EFLAGS  00010206
eax: c13c2060
ebx: fffd
ecx: 
edx: ca65b1dc
esi: 
edi: 0018
ebp: cbf72000
esp: c029feb0
ds:  0018
es:  0018
ss:  0018
Process swapper (pid: 0, stackpage=c029f000)

Call Trace:

 c021e828 [ndisc_send_ns]
 c01e912c [deliver_to_old_ones]
 c021ecfd [ndisc_error_report]
 c01efd2b [ip_route_input_slow]
 c01eb7ab [neigh_timer_handler]
 c01eb664 [neigh_timer_handler]
 c0119f12 [timer_bh]
 c010b2db [timer_interrupt]
 c0116e5f [bh_action]
 c0116d98 [tasklet_hi_action]
 c0116c9f [do_softirq]
 c0107e41 [do_IRQ]
 c0105120 [default_idle]
 c0105120 [default_idle]
 c0106b14 [ret_from_intr]
 c0105120 [default_idle]
 c0105120 [default_idle]
 c0100018 [startup_32]
 c0105143 [default_idle]
 c01051a9 [cpu_idle]
 c0105000 [init]
 c0100197 [L6]

 panic info 2.4.4-ac1 
CPU 0
EIP 0010:[c0217354]
EFLAGS  00010206
eax: c13c2060
ebx: fffd
ecx: 
edx: cb73e35c
esi: 
edi: 0018
ebp: cbf72000
esp: c029feb0
ds:  0018
es:  0018
ss:  0018
Process swapper (pid: 0, stackpage=c029f000)

Call Trace:

 c021e868 [ndisc_send_ns]
 c01e916c [deliver_to_old_ones]
 c021ed3d [ndisc_error_report]
 c01e5d6b [ip_route_input_slow]
 c01eb7eb [neigh_timer_handler]
 c01eb6a4 [neigh_timer_handler]
 c0119f02 [timer_bh]
 c010b2db [timer_interrupt]
 c0116e4f [bh_action]
 c0116d88 [tasklet_hi_action]
 c0116c8f [do_softirq]
 c0107e41 [do_IRQ]
 c0105120 [default_idle]
 c0105120 [default_idle]
 c0106b14 [ret_from_intr]
 c0105120 [default_idle]
 c0105120 [default_idle]
 c0100018 [startup_32]
 c0105143 [default_idle]
 c01051a9 [cpu_idle]
 c0105000 [init]
 c0100197 [L6]

 panic info 2.4.4 

CPU 0
EIP 0010:[c021aa64]
EFLAGS  00010206
eax: c13e3060
ebx: fffd
ecx: 
edx: c80ef3dc
esi: 
edi: 0018
ebp: cbf7ac00
esp: c02b9eb0
ds:  0018
es:  0018
ss:  0018
Process swapper (pid: 0, stackpage=c02b9000)

Call Trace:

 c0221fe8 [ndisc_send_ns]
 c01ec2bc [deliver_to_old_ones]
 c02224ed [ndisc_error_report]
 c01e8d0b [ip_route_input_slow]
 c01ee93b [neigh_timer_handler]
 c01ee7f4 [neigh_timer_handler]
 c0119402 [timer_bh]
 c010aa3c [timer_interrupt]
 c011634f [bh_action]
 c0116288 [tasklet_hi_action]
 c011618f [do_softirq]
 c0107ec1 [do_IRQ]
 c0105120 [default_idle]
 c0105120 [default_idle]
 c0106b24 [ret_from_intr]
 c0105120 [default_idle]
 c0105120 [default_idle]
 c0100018 [startup_32]
 c0105143 [default_idle]
 c01051a9 [cpu_idle]
 c0105000 [init]
 c0100197 [L6]


-- 
Cliff Albert| IRCNet:#linux.nl, #ne2000, #linux, #freebsd.nl
[EMAIL PROTECTED] |#openbsd, #ipv6, #cu2.nl
-[ICQ: 18461740]| 6BONE: CA2-6BONE   RIPE: CA3348-RIPE
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: 2.2.19 locks up on SMP

2001-05-01 Thread Trond Myklebust

   == Ion Badulescu [EMAIL PROTECTED] writes:

  On Tue, 1 May 2001, Trond Myklebust wrote:
 Did you apply the following patch which I put out on the lists
 a couple of weeks ago?

  No, I was testing with 2.2.19 and then I started going back
  into the 2.2.19pre series until I found the culprit.

  I'll give your patch a spin tomorrow, after I catch some
  zzz's. :-)

Right you are.

FYI I've now put up those patches of which I am aware against 2.2.19
on

  http://www.fys.uio.no/~trondmy/src/2.2.19

I'll try to keep that area updated with a brief explanation for each
patch...

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



Re: 2.4 and 2GB swap partition limit

2001-05-01 Thread Christoph Rohland

Hi Alan,

On Mon, 30 Apr 2001, Alan Cox wrote:
 paging in just released 2.4.4, but in previuos kernel, a page that
 was paged-out, reserves its place in swap even if it is paged-in
 again, so once you have paged-out all your ram at least once, you
 can't get any more memory, even if swap is 'empty'.
 
 This is a bug in the 2.4 VM, nothing more or less. It and the
 horrible bounce buffer bugs are forcing large machines to remain on
 2.2. So it has to get fixed

Yes, it is a bug. and thanks for stating this so clearly.

But a lot of the big servers can go to 2.4. because SYSV shm/shm
fs/tmpfs will reclaim the swap entries on swapin. So big databases and
applications servers which rely on shm are not affected.

Greetings
Christoph


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



Re: New rtl8139 driver prevents ssh from exiting.

2001-05-01 Thread Rob Landley


--- Andrew Morton [EMAIL PROTECTED] wrote:
 Rob Landley wrote:
  
  The kernel thread the new rtl8139 driver spawns
  apparently wants to write to stdout, because it
 counts
  as an unfinished process that prevents an ssh
 session
  from exiting.
 
 Does this help?

--- Andrew Morton [EMAIL PROTECTED] wrote:
 Rob Landley wrote:
  
  The kernel thread the new rtl8139 driver spawns
  apparently wants to write to stdout, because it
 counts
  as an unfinished process that prevents an ssh
 session
  from exiting.
 
 Does this help?

Assuming this applies cleanly against 2.2.19
(production box; 2.4.3 wasn't ready and 2.4.4 wasn't
available when the first prototypes had to go to
test), I'll let you know in about an hour.

Thanks,

Rob

__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



[Patch] deadlock on write in tmpfs

2001-05-01 Thread Christoph Rohland

Hi Linus and Stephen,

tmpfs deadlocks when writing into a file from a mapping of the same
file. 

The problem is the following:

- shmem_file_write may call shmem_no_page and calls
  shmem_getpage_locked later,
- shmem_no_page calls shmem_getpage_locked
- shmem_getpage_locked may call shmem_writepage on page allocation

- shmem_file_write holds the inode semaphore
- shmem_getpage_locked prevent races against shmem_writepage with the
  shmem spinlock
- shmem_getpage_locked needs serialization against itself and
  shmem_truncate

The last was done with the inode semaphore, which deadlocks with
shmem_write

So I see two choices: 

1) Do not serialise the whole of shmem_getpage_locked but protect
   critical pathes with the spinlock and do retries after sleeps
2) Add another semaphore to serialize shmem_getpage_locked and
   shmem_truncate

I tried some time to get 1) done but the retry logic became way too
complicated. So the attached patch implements 2)

I still think it's ugly to add another semaphore, but it works.

Greetings
Christoph

diff -uNr 2.4.4/include/linux/shmem_fs.h c/include/linux/shmem_fs.h
--- 2.4.4/include/linux/shmem_fs.h  Sun Apr 29 20:33:00 2001
+++ c/include/linux/shmem_fs.h  Sun Apr 29 22:43:56 2001
@@ -19,6 +19,7 @@
 
 struct shmem_inode_info {
spinlock_t  lock;
+   struct semaphore sem;
unsigned long   max_index;
swp_entry_t i_direct[SHMEM_NR_DIRECT]; /* for the first blocks */
swp_entry_t   **i_indirect; /* doubly indirect blocks */
diff -uNr 2.4.4/mm/shmem.c c/mm/shmem.c
--- 2.4.4/mm/shmem.cMon Apr 30 09:45:39 2001
+++ c/mm/shmem.cTue May  1 15:15:38 2001
@@ -161,6 +161,7 @@
swp_entry_t **base, **ptr, **last;
struct shmem_inode_info * info = inode-u.shmem_i;
 
+   down(info-sem);
inode-i_ctime = inode-i_mtime = CURRENT_TIME;
spin_lock (info-lock);
index = (inode-i_size + PAGE_CACHE_SIZE - 1)  PAGE_CACHE_SHIFT;
@@ -197,6 +198,7 @@
info-swapped -= freed;
shmem_recalc_inode(inode);
spin_unlock (info-lock);
+   up(info-sem);
 }
 
 static void shmem_delete_inode(struct inode * inode)
@@ -281,15 +283,12 @@
  * still need to guard against racing with shm_writepage(), which might
  * be trying to move the page to the swap cache as we run.
  */
-static struct page * shmem_getpage_locked(struct inode * inode, unsigned long idx)
+static struct page * shmem_getpage_locked(struct shmem_inode_info *info, struct inode 
+* inode, unsigned long idx)
 {
struct address_space * mapping = inode-i_mapping;
-   struct shmem_inode_info *info;
struct page * page;
swp_entry_t *entry;
 
-   info = inode-u.shmem_i;
-
 repeat:
page = find_lock_page(mapping, idx);
if (page)
@@ -393,6 +392,7 @@
 
 static int shmem_getpage(struct inode * inode, unsigned long idx, struct page **ptr)
 {
+   struct shmem_inode_info *info;
struct address_space * mapping = inode-i_mapping;
int error;
 
@@ -407,27 +407,28 @@
page_cache_release(*ptr);
}
 
-   down (inode-i_sem);
-   /* retest we may have slept */
+   info = inode-u.shmem_i;
+   down (info-sem);
+   /* retest we may have slept */  
+
+   *ptr = ERR_PTR(-EFAULT);
if (inode-i_size  (loff_t) idx * PAGE_CACHE_SIZE)
-   goto sigbus;
-   *ptr = shmem_getpage_locked(inode, idx);
+   goto failed;
+
+   *ptr = shmem_getpage_locked(inode-u.shmem_i, inode, idx);
if (IS_ERR (*ptr))
goto failed;
+
UnlockPage(*ptr);
-   up (inode-i_sem);
+   up (info-sem);
return 0;
 failed:
-   up (inode-i_sem);
+   up (info-sem);
error = PTR_ERR(*ptr);
-   *ptr = NOPAGE_OOM;
-   if (error != -EFBIG)
-   *ptr = NOPAGE_SIGBUS;
-   return error;
-sigbus:
-   up (inode-i_sem);
*ptr = NOPAGE_SIGBUS;
-   return -EFAULT;
+   if (error == -ENOMEM)
+   *ptr = NOPAGE_OOM;
+   return error;
 }
 
 struct page * shmem_nopage(struct vm_area_struct * vma, unsigned long address, int 
no_share)
@@ -500,6 +501,7 @@
 struct inode *shmem_get_inode(struct super_block *sb, int mode, int dev)
 {
struct inode * inode;
+   struct shmem_inode_info *info;
 
spin_lock (sb-u.shmem_sb.stat_lock);
if (!sb-u.shmem_sb.free_inodes) {
@@ -519,7 +521,9 @@
inode-i_rdev = to_kdev_t(dev);
inode-i_mapping-a_ops = shmem_aops;
inode-i_atime = inode-i_mtime = inode-i_ctime = CURRENT_TIME;
-   spin_lock_init (inode-u.shmem_i.lock);
+   info = inode-u.shmem_i;
+   spin_lock_init (info-lock);
+   sema_init (info-sem, 1);
switch (mode  S_IFMT) {
default:
init_special_inode(inode, mode, dev);
@@ -549,6 +553,7 @@
 shmem_file_write(struct 

isa_read/write not available on ppc - solution suggestions ??

2001-05-01 Thread mike_phillips

To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the 
isa_read/write's have to be changed to regular read/write due to the lack 
of the isa_read/write functions for ppc.

So, the question is should I simply:

a) change everything to read/write and friends (the way the driver used to 
be before the isa_read/write function were introduced)
b) Put ugly macros in the driver to use the different functions depending 
upon architecture.
c) Implement the isa_read/write functions for ppc ? 
or d) something completely different I haven't thought of. 

Remember, this driver must support isa, pcmcia, mca, ix86 and now ppc. 

Personally I'd rather not have arch dependent macros in the driver, but I 
know there is a good reason why the isa_read/write functions were 
introduced in the first place. 

Suggestions ?

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



Re: Linux Kernel Debuggers, KDB or KGDB?

2001-05-01 Thread Jeff Dike

[EMAIL PROTECTED] said:
 Basically you could add support for ALL generic subsystems, that
 support dummy hardware, like SCSI and ISDN for example.

 Is that planned or do I suggest sth. stupid here? ;-) 

Neither.  I know squat about hardware, so I had no idea that SCSI and ISDN 
would be easy to do from UML.

If the SCSI and ISDN people want to produce appropriate UML drivers, I take 
patches :-)

Jeff


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



RE: Linux Cluster using shared scsi

2001-05-01 Thread Roets, Chris

So, will Linux ever support the scsi reservation mechanism as standard ?
Isn't there a standard that says if you scsi reserve a disk, no one
else should be able to access this disk, or is this a steeleye/Compaq
standard.

Chris

-Original Message-
From: James Bottomley [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 27, 2001 5:12 PM
To: Roets, Chris
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Linux Cluster using shared scsi


I've copied linux SCSI and quoted the entire message below so they can
follow.

Your assertion that this works in 2.2.16 is incorrect, the patch to fix the 
linux reservation conflict handler has never been added to the official
tree.  
I suspect you actually don't have vanilla 2.2.16 but instead have a redhat
or 
other distribution patched version.  Most distributions include the Steeleye

SCSI clustering patches which correct reservation handling.

I've attached the complete patch, which fixes both the old and the new error

handlers in the 2.2 kernel it applies against 2.2.18.

James Bottomley


 Problem :
 install two Linux-system with a shared scsi-bus and storage on that shared
 bus.
 suppose :
 system one : SCSI ID 7
 system two : SCSI ID 6
 shared disk : SCSI ID 4
 
 By default, you can mount the disk on both system.  This is normal
 behavior, but
 may impose data corruption.
 To prevent this, you can SCSI-reserve a disk on one system.  If the other
 system
 would try to access this device, the system should return an i/o error due
 to the reservation.
 This is a common technique used in
 - Traditional Tru64 Unix ase clustering
 - Tr64 Unix V5 Clustering to accomplish i/o barriers
 - Windows-NT Clusters
 - Steel-eye clustering
 The reservation can be done using a standard tool like scu
 
 scu -f /dev/sdb
 scu  reserve device
 
 On Linux, this works fine under Kernel version 2.2.16.
 Below is the code that accomplish this
 /usr/src/linux/drivers/scsi/scsi_obsolete.c in routine scsi_old_done
 case RESERVATION_CONFLICT:
 printk(scsi%d (%d,%d,%d) : RESERVATION CONFLICT\n,
SCpnt-host-host_no, SCpnt-channel,
SCpnt-device-id, SCpnt-device-lun);
 status = CMD_FINISHED; /* returns I/O error */
 break;
 default:
 As of kernel version 2.2.18, this code has changed, If a scsi reserve
 error
 occurs, the device driver does a scsi reset.  This way the scsi
 reservation is
 gone, and the device can be accessed.
 /usr/src/linux/drivers/scsi/scsi_obsolete.c in routine scsi_old_done 
 case RESERVATION_CONFLICT:
 printk(scsi%d, channel %d : RESERVATION CONFLICT
 performing
 reset.\n, SCpnt-host-host_no, SCpnt-channel);
 scsi_reset(SCpnt, SCSI_RESET_SYNCHRONOUS);
 status = REDO;
 break;
 
 Fix : delete the scsi reset in the kernel code
 case RESERVATION_CONFLICT:
 /* Deleted Chris Roets
 printk(scsi%d, channel %d : RESERVATION CONFLICT
 performing
 reset.\n, SCpnt-host-host_no, SCpnt-channel);
 scsi_reset(SCpnt, SCSI_RESET_SYNCHRONOUS);
 status = REDO;
 next four lines added */
 printk(scsi%d (%d,%d,%d) : RESERVATION CONFLICT\n,
SCpnt-host-host_no, SCpnt-channel,
SCpnt-device-id, SCpnt-device-lun);
 status = CMD_FINISHED; /* returns I/O error */
 break;
 
 and rebuild the kernel.
 
 This should get the customer being able to continue
 
Questions  :
 - why  is this scsi reset done/added as of kernel version 2.2.18
 - as we are talking about an obsolete routine, how is this accomplished 
  in the new code and how is it activated.  

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



SMP races in proc with thread_struct

2001-05-01 Thread Todd Inglett

Perhaps this is old news...but...

I can easily create a race when reading /proc/pid/stat
(fs/proc/{base.c,array.c}) where a rapidly reading application, such as
top, starts reading stats for a thread which goes away during the
read.  This is easily reproduced with a program that rapidly forks and
exits while top is running.

On inspection, I don't see how the code can expect the thread_struct to
stay around since it is not holding any lock for the duration of its
use.  The code could hold the thread_struct's lock (after verifying it
still exists while holding tasklist_lock I would imagine), but for
performance I would think a better solution would be to copy the struct
since stale data is probably ok in this case.

Dereferencing a non-existent thread_struct is clearly not ok.

Would anyone familiar with this code care to comment?
-- 
-todd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: deregister?

2001-05-01 Thread mirabilos

 Not to mention in various comments and documentation.  Deregister,
 according to www.m-w.com (and many other dictionaries), is not a
word.
 Is there some sort of historical significance to this being used, in
 place of unregister?

 At 10:03 PM -0400 2001-04-29, Andres Salomon wrote:
 Americans can spell?  Since when?

 OED 2nd Ed:

 deregister. v. trans. To remove from a register. Hence
 deregistration. (first citation 1925)

 unregistered. ppl. a. Not entered in a register; unrecorded. (first
 citation 1604)

 The OED has no entry for unregister.

My DCE here has no opposite word, just register, but because
register comes from Latin registrare, and due to the DCE's
explanation of how to build opposite words, I'd rather
prefer deregister over disregister over unregister.


A message of love and openness: translate linux into Latin!

It has strict grammar, no such problems, and a single
person on top - the pope, actually. We could replace
his function by Linus ;-) or Alan... dunno

-mirabilos


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



Re: isa_read/write not available on ppc - solution suggestions ??

2001-05-01 Thread Alan Cox

 a) change everything to read/write and friends (the way the driver used to 
 be before the isa_read/write function were introduced)

readb/readw/readl have always worked for ISA bus. They simply avoid the need
for ioremap and are meant for lazy porting

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



Re: isa_read/write not available on ppc - solution suggestions ??

2001-05-01 Thread Brian Gerst

[EMAIL PROTECTED] wrote:
 
 To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the
 isa_read/write's have to be changed to regular read/write due to the lack
 of the isa_read/write functions for ppc.

Treat it like a PCI device and use ioremap().  Then change isa_readl()
to readl() etc.

--

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



Re: Alpha compile problem solved by Andrea (pte_alloc)

2001-05-01 Thread Hubert Mantel

Hi,

On Mon, Apr 30, Alan Cox wrote:

  OTOH x86 is racy and there's no workaround available at the moment.
 
 -ac fixes all known problems there 

Is there some place from where one can download all the patches in -ac 
kernels as separate patches, not just one monster patch (same way Andrea 
is doing)?

I assume you are maintaining them as separate patches anyway in order to 
be able to feed them to Linus.

 Alan
  -o)
Hubert Mantel  Goodbye, dots...   /\\
 _\_v
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: [PATCH] adding PCI bus information to SCSI layer

2001-05-01 Thread Jonathan Lundell

At 7:27 PM -0600 2001-04-30, Richard Gooch wrote:
Jonathan Lundell writes:
   ...
   Consider, instead of /dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3
  something like

  /dev/bus/pci0d1f0/scsi0t1l2p3
  or
  /dev/bus/pci0:d1:f0/scsi0:t1:l2:p3

Nope. Linus hates the idea of compressed names. He wants them to be
obvious at first glance. My original devfs patch (before it went into
the kernel) had compressed names, and he made me change them (there
were other changes as well). I know it's a bit much to type in, but
he's probably right. If people need it, I can add compressed names to
devfsd, just like I did to preserve the names in the original devfs
patch.

OK. Not a big deal, really.

/dev/bus/pci0/dev1/fcn0/bus0/tgt1/lun2/part3

becomes

/device/bus/peripheralcomponentinterconnect0/device1/function0/bus0/target1/logicalunitnumber2/partition3
 
:-)

   A related idea would be the ability to translate from a logical PCI
  slot number, as above, and a physically meaningful description that
  the user could use to identify an actual slot. Unfortunately the
  proper place for such a translation function is in the
  (hardware-specific) BIOS.

Nope. It's cleaner to do this in a vendor-specific fixup layer.

I agree, actually. If there *were* BIOS support for such geographic 
information (and while there should be there isn't), the 
vendor-specific fixup could take advantage of it. The point about 
BIOS is that it's connected to the specific hardware, and is the 
appropriate (ultimate) repository for that kind of information. In a 
related vein (for example) Sun's OBP (BIOS-equivalent) provides a 
lookup function that converts a physical memory address (generally 
after an ECC error) to a physical DIMM U-number, for human reporting 
purposes. But it's a moot point, so never mind

Alan
asked me a similar question privately, so I've included my reponse to
his email (quoting bits of his email for context) below. In his reply,
Alan said it makes sense. I take that as a good omen.
=
  How do you intend to handle pci busses that are below other busses - eg gsc
  /dev/bus/gsc/bus/pci0/ .. ?
   Im just thinking it gets very cumbersome.

It *does* address my concern about multiple PCI subsystems.

It could. And if you play with the upcoming SGI IA-64 boxes, where
they have a deep /dev/hw, it would appear even more so. However, I
came up with a scheme while I was visiting them after the workshop,
which I believe will handle an arbitrarily complex vendor tree. I'm
actually quite proud of this idea :-)

The basic idea is that /dev/bus contains a *logical* enumeration of
all busses in the system. This contains the generic Linux view of
busses. We already have this enumeration within struct pci_dev and
friends.

Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0
into symlinks to something like /dev/hw/PBrick/00AA3415/bus1/pci3 (or
similar, I forget just how deep SGI's tree went).

This scheme is really just an extension of the approach Linus took in
the Great Name Change he forced upon me a year and a half ago. Back
then, he wanted /dev/discs to answer the question what discs do I
have, and /dev/scsi to answer what SCSI devices do I have, and
what's the layout. So now, I'm adding /dev/bus for what logical
busses do I have and /dev/hw for what is the exact hardware
topology.

Where we have generic hardware (i.e. a vendor doesn't provide their
own PCI fixups), and there is a need to show the bus topology, we can
write generic fixups that parse the struct pci_dev and friends. For
example, most x86 machines would fall in this generic category.

Reasonable, especially if a fixup map could be created by a user in 
the absence of a vendor-supplied map. (When/where does /dev/hw/ get 
created?)

On a related note, how does the current pci_dev tree deal with 
multiple PCI subsystems? For example, in pci.c we have

struct pci_dev *
pci_find_slot(unsigned int bus, unsigned int devfn)
{
struct pci_dev *dev;

pci_for_each_dev(dev) {
if (dev-bus-number == bus  dev-devfn == devfn)
return dev;
}
return NULL;
}

...which appears on the face of it (assuming a single tree) to ignore 
the possibility of bus-number aliasing across PCI subsystems.
-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: iso9660 endianness cleanup patch

2001-05-01 Thread Andrzej Krzysztofowicz


Are you sure that the arguments of the following casting

 + return le16_to_cpu(*(u16 *)p);

 + return be16_to_cpu(*(u16 *)p);

 + return le32_to_cpu(*(u32 *)p);

 + return be32_to_cpu(*(u32 *)p);

are properly aligned ?
I did not revise the code to check it, but AFAIK improperly aligned
char* pointers cause problem with casting to pointers to 16/32-bit data
on some architectures (I heard of sucj a problem with alpha).

Maybe there was a reason that the original code did operate on bytes here...

Andrzej

-- 
===
  Andrzej M. Krzysztofowicz   [EMAIL PROTECTED]
  phone (48)(58) 347 14 61
Faculty of Applied Phys.  Math.,   Technical University of Gdansk
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



APIC asymmetry in SMP ?

2001-05-01 Thread J . A . Magallon

Hi, 

Looking over one other problem, I realized that my 2 cpus are recognized
slightly different in the setup_APIC_timer function:

cpu: 0, clocks: 1002324, slice: 334108
CPU0T0:1002320,T1:668208,D:4,S:334108,C:1002324
cpu: 1, clocks: 1002324, slice: 334108
CPU1T0:1002320,T1:334096,D:8,S:334108,C:1002324

Both are just the same, both pII@400, 512Kb:

CPU: Before vendor init, caps: 0183fbff  , vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0183fbff   
CPU: After generic, caps: 0183fbff   
CPU: Common caps: 0183fbff   
CPU0: Intel Pentium II (Deschutes) stepping 02
.
CPU: Before vendor init, caps: 0183fbff  , vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU: After vendor init, caps: 0183fbff   
CPU: After generic, caps: 0183fbff   
CPU: Common caps: 0183fbff   
CPU1: Intel Pentium II (Deschutes) stepping 02

???

-- 
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.4-ac1 #1 SMP Tue May 1 11:35:17 CEST 2001 i686

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



Re: New rtl8139 driver prevents ssh from exiting.

2001-05-01 Thread Rob Landley

--- Andrew Morton [EMAIL PROTECTED] wrote:
 ack.  You never said 2.2.19 :(
 
 It won't apply...

No, but this one did.  (Never underestimate the power
of somebody with source code, a text editor, and the
willingness to totally hose their system.)

And it fixed the problem.  Thank you.

Rob


__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
 patch-2.2.19


Re: isa_read/write not available on ppc - solution suggestions ??

2001-05-01 Thread Brian Gerst

Alan Cox wrote:
 
  a) change everything to read/write and friends (the way the driver used to
  be before the isa_read/write function were introduced)
 
 readb/readw/readl have always worked for ISA bus. They simply avoid the need
 for ioremap and are meant for lazy porting

You meant isa_read* were for lazy porting.  read* require ioremap be
done before hand, even for ISA.

--

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



Re: Linux 2.4.4-ac2 Compilation error...

2001-05-01 Thread FAVRE Gregoire

Thus spake Alan Cox ([EMAIL PROTECTED]):

 2.4.4-ac2

I got:

gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac2/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing
+-pipe -mpreferred-stack-boundary=2 -march=i686-c -o pci-pc.o
pci-pc.c
{standard input}: Assembler messages:
{standard input}:784: Warning: indirect lcall without `*'
{standard input}:869: Warning: indirect lcall without `*'
{standard input}:955: Warning: indirect lcall without `*'
{standard input}:993: Warning: indirect lcall without `*'
{standard input}:1025: Warning: indirect lcall without `*'
{standard input}:1057: Warning: indirect lcall without `*'
{standard input}:1088: Warning: indirect lcall without `*'
{standard input}:1117: Warning: indirect lcall without `*'
{standard input}:1146: Warning: indirect lcall without `*'
{standard input}:1433: Warning: indirect lcall without `*'
{standard input}:1529: Warning: indirect lcall without `*'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-ac2/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing
+-pipe -mpreferred-stack-boundary=2 -march=i686-c -o pci-irq.o
pci-irq.c
In file included from pci-irq.c:19:
/usr/src/linux-2.4.4-ac2/include/asm/io_apic.h:98: `MAX_IRQ_SOURCES'
undeclared here (not in a function)
make[1]: *** [pci-irq.o] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.4-ac2/arch/i386/kernel'
make: *** [_dir_arch/i386/kernel] Error 2
541.570u 48.620s 13:32.67 72.6% 0+0k 0+0io 609749pf+0w
Exit 2

gcc version 2.96 2731 (Linux-Mandrake 7.3)

Greg

http://ulima.unil.ch/greg ICQ:16624071 mailto:[EMAIL PROTECTED]

 PGP signature


Re: 2.4 and 2GB swap partition limit

2001-05-01 Thread Stephen C. Tweedie

Hi,

On Mon, Apr 30, 2001 at 07:12:12PM +0100, Alan Cox wrote:
  paging in just released 2.4.4, but in previuos kernel, a page that was
  paged-out, reserves its place in swap even if it is paged-in again, so
  once you have paged-out all your ram at least once, you can't get any
  more memory, even if swap is 'empty'.
 
 This is a bug in the 2.4 VM, nothing more or less. It and the horrible bounce
 buffer bugs are forcing large machines to remain on 2.2. So it has to get 
 fixed

Umm, 2.2 can behave in the same way.  The only difference in the 2.4
behaviour is that 2.4 can maintain the swap cache effect for dirty
pages as well as clean ones.  An application which creates a large
in-core data set and then does not modify it will show exactly the
same behaviour on 2.2.

To call it a bug is to imply that fixing it is the right thing to
do.  It might be in some cases, but discarding the swap entry has a
cost --- you fragment swap, and if the page in memory is clean, you
end up increasing the amount of swap IO.  

The right fix is to reclaim such pages only when we need to.  To
disable swap caching when we still have enough swap free would hurt
users who have the spare swap to cope with it.

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



Announce: XFS Release 1.0 for Linux

2001-05-01 Thread xfs-masters

Tuesday May 1 2001:
SGI is pleased to announce the 1.0 release of XFS, high-performance
journaled file system for Linux. 

http://oss.sgi.com/projects/xfs/

XFS is widely recognized as the industry-leading high-performance file system,
providing rapid recovery from system crashes and the ability to support
extremely large disk farms. XFS is the first journaled file system for Linux
available today that has a proven track record in production environments
since December 1994. 

XFS Linux 1.0 is released for the Linux 2.4 kernel and offers the following
advanced features:

* Fast recovery after a system crash or power failure, NO fsck!
* Journaling for guaranteed file system integrity 
* Direct I/O 
* Space preallocation 
* Transactionally recorded quotas 
* Access control lists and Extended attributes 
* Infrastructure for XDSM support (DMAPI) 
* Excellent overall performance 
* Excellent scalability (64 bit file system) 
* On-disk compatibility with IRIX XFS file systems

A complete toolset including: 

* dump/restore support including all XFS file system features such as ACLs and 
quotas 
* Repair utility, file system editor, and growing the file system 
* ACL editing utility 
* Extended attribute editing utility

Excellent integration with other Linux subsystems: 
* NFS version 2 and 3 server support 
* Root file system and lilo support 
* Software raid integration with md and lvm packages 
* Mount by label and mount by uuid 


The SGI XFS team is also providing a modified Red Hat Linux anaconda based installer.
The installer handles all the details of setting up a Red Hat Linux 7.1 system running
entirely on XFS, or a combination of XFS and ext2 file systems.


Sincerely 
The SGI XFS Team.










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



Re: Alpha compile problem solved by Andrea (pte_alloc)

2001-05-01 Thread Alan Cox

 I assume you are maintaining them as separate patches anyway in order to 
 be able to feed them to Linus.

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



Re: Linux 2.4.4-ac2

2001-05-01 Thread J . A . Magallon

Hi,

On 05.01 Alan Cox wrote:
 
   ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
 

Hangs after APIC init:

(bootlog from ac1)
Using local APIC timer interrupts.
calibrating APIC timer ...
 CPU clock speed is 400.9211 MHz.
 host bus clock speed is 100.2300 MHz.
cpu: 0, clocks: 1002300, slice: 334100
CPU0T0:1002288,T1:668176,D:12,S:334100,C:1002300
cpu: 1, clocks: 1002300, slice: 334100
CPU1T0:1002288,T1:334080,D:8,S:334100,C:1002300
checking TSC synchronization across CPUs: passed.

ac2 stops here

PCI: PCI BIOS revision 2.10 entry at 0xfdb81, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware

Now I am going to spread printk's over the source, and set APIC_DEBUG=1,
but if someone has a clue ?
Ask for more info if it can be useful...

--
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.4-ac1 #1 SMP Tue May 1 11:35:17 CEST 2001 i686

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



Re: isa_read/write not available on ppc - solution suggestions ??

2001-05-01 Thread Alan Cox

  for ioremap and are meant for lazy porting
 
 You meant isa_read* were for lazy porting.  read* require ioremap be
 done before hand, even for ISA.

Indeed I do

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



bandwidth

2001-05-01 Thread mirabilos

duh! You argue over bandwidth due to sigs 4*80, and
other ppl here are QUOTING SIGS which is much worse,
and even the kcsf-ing LMKL footer.
And yep I have a .sig which I don't use on LKML due
to bandwidth.

Another point: look at the headers. I'd like LKML to
strip all these X- thingies, the Received: etc.
so that the messages I get have a bare minimum header
consisting just of To: and Subject: (maybe MIME).

-mirabilos

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



Re: CANBus driver.

2001-05-01 Thread David Woodhouse


[EMAIL PROTECTED] said:
  Does there exist any work on a CANBus driver for linux already?

See the Linux Lab Project at http://www.llp.fu-berlin.de/

ISTR there were CAN drivers there at one point.

--
dwmw2


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



Re: isa_read/write not available on ppc - solution suggestions ??

2001-05-01 Thread mike_phillips

[EMAIL PROTECTED] wrote:
 
 To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the
 isa_read/write's have to be changed to regular read/write due to the 
lack
 of the isa_read/write functions for ppc.

 Treat it like a PCI device and use ioremap().  Then change isa_readl()
 to readl() etc.

Bleurgh, the latest version of the driver (not in the kernel yet) searches 
for turbo based cards by checking the isa address space from 0xc - 
0xe in 8k chunks. So we'd have to ioremap each 8k section, check it, 
find out the adapter isn't there and then iounmap it. 

Oh well, if that's what it takes =:0

Mike

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



Re: More!! Kernel NULL pointer, over my head... (DOH!)

2001-05-01 Thread Jamie Harris

Erin Jones wrote:
 
 are you sure this works:
 gzip -d ; tar xvf myFile.tar.gz?
 shouldn't it be
 gzip -cd myFile.tar.gz | tar xvf -

I think I have proven myself unworth of your help by producing the
above, obvious to everyone, else cockup.  As unworthy as I am, here I go
again...

As suggested by Phil on Bristol LUG I've fsck'd my filesystems.  Got
something interesting in the process though.  Booted using some
Slackware 7.1 (2.2.16) disks to fsck / and got similar errors to those
already described :(  Yet the system came up...  As there wasn't any
swap configured I can pretty much rule that out, and I had not attempted
to mount any file systems...  These are the same disks I used to carry
out the inital install and I did't get problems then...  I am starting
to think Hardware but have been told that a copy of ksymoops might shed
some more light...

Thanks again.


Jamie...

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 ***Slowly and surely the UNIX crept up on the Nintendo user...   
***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-BEGIN GEEK CODE BLOCK-Version: 3.1
GCS/ED d-(++) s:+ a- C+++$ U+++$ P L E+(---) W++ N o?
K? w() O- M V? PS PE? Y PGP- t+ 5 X- R- tv- b++ DI++ D+++ G e++ h*
r+ y+++
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: bandwidth

2001-05-01 Thread J . A . Magallon


On 05.01 mirabilos wrote:
 
 Another point: look at the headers. I'd like LKML to
 strip all these X- thingies, the Received: etc.
 so that the messages I get have a bare minimum header
 consisting just of To: and Subject: (maybe MIME).
 

What you have todo is to learn how to configure your mailer to display
headers you want. elm and balsa can do it. Do not know about Outlook...
(btw, it is curious, mailing to lkml with outlook...)

-- 
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.4-ac1 #1 SMP Tue May 1 11:35:17 CEST 2001 i686

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



Re: bandwidth

2001-05-01 Thread Gerhard Mack

On Tue, 1 May 2001, mirabilos wrote:

 Another point: look at the headers. I'd like LKML to
 strip all these X- thingies, the Received: etc.
 so that the messages I get have a bare minimum header
 consisting just of To: and Subject: (maybe MIME).
 

Er you wish to remove the abillity to trace abusive email?


--
Gerhard Mack

[EMAIL PROTECTED]

 As a computer I find your faith in technology amusing.

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



Re: Linux 2.4.4-ac2

2001-05-01 Thread Hugh Dickins

On Tue, 1 May 2001, J . A . Magallon wrote:
 On 05.01 Alan Cox wrote:
  ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
 Hangs after APIC init:
 
 (bootlog from ac1)
 cpu: 0, clocks: 1002300, slice: 334100
 CPU0T0:1002288,T1:668176,D:12,S:334100,C:1002300
 cpu: 1, clocks: 1002300, slice: 334100
 CPU1T0:1002288,T1:334080,D:8,S:334100,C:1002300
 checking TSC synchronization across CPUs: passed.
 
 ac2 stops here
 
 PCI: PCI BIOS revision 2.10 entry at 0xfdb81, last bus=1

Don't ask me why, but I think you may find it's Peter's patch to
the women-and-children-first in kernel/fork.c: I'm not yet running
-ac2, but I am trying that patch, fine on UP but hanging right there
(well, I get a go go go message too) on SMP.

Try reversing the:

-   p-counter = current-counter;
-   current-counter = 0;
+   p-counter = (current-counter + 1)  1;
+   current-counter = 1;
+   current-policy |= SCHED_YIELD;

and see if that works for you too.

Hugh

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



tulip driver broken in 2.4.4?

2001-05-01 Thread Ronny Haryanto

Just tried 2.4.4 yesterday and found that my eth1 was dead after 5 minutes.
The log says:

Apr 30 10:30:59 fluke kernel: NETDEV WATCHDOG: eth1: transmit timed out 
Apr 30 10:30:59 fluke kernel: eth1: Transmit timed out, status fc664010, CSR12 
, resetting... 
Apr 30 10:31:07 fluke kernel: NETDEV WATCHDOG: eth1: transmit timed out 
Apr 30 10:31:07 fluke kernel: eth1: Transmit timed out, status fc664010, CSR12 
, resetting...  
... and so on repeatedly ...

I had to ifdown-ifup cycle to re-enable it but it's dead again after 5
minutes with the same problem. The card is LinkSys LNE100TX v4.1. It is
currently working fine with 2.2.18. If there's any other info that is needed
please let me know.

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



Re: Patch(?): bash-2.05/jobs.c loses interrupts

2001-05-01 Thread Pavel Machek

Hi!

  Linux-2.4.4 has a change, for which I must accept blame,
  where fork() runs the child first, reducing unnecessary copy-on-write
  page duplications, because the child will usually promptly do an
  exec().  I understand this is pretty standard in most unixes.
  
  Peter Osterlund noticed an annoying side effect of this,
  which I think is a bash bug.  He wrote:
  
   Another thing is that the bash loop while true ; do /bin/true ; done is
   not possible to interrupt with ctrl-c.
  
  I have reproduced this problem on a single CPU system.
  I also modified my kernel to sometimes run the fork child first
  and sometimes not.  In that case, that loop would sometimes
  abort on a control-C and sometimes ignore it, but ignoring it
  would not make the loop less likely to abort on another control-C.
  I'm pretty sure the control-C was being delivered only to the child
  due to a race condition in bash, which may be mandated by posix.
 
 Did you reconfigure and rebuild bash on your machine running the 2.4
 kernel, or just use a bash binary built on a previous kernel
 version?

This is nasty race condition. I do not believe you can test for it in
configure. 

This might happen on 2.4.3 (occasionally) too. Kernel is permitted to
do any kind of scheduling!

Pavel

 Bash has an autoconf test that will, if it detects the need to do so,
 force the job control code to synchronize between parent and child
 when setting up the process group for a new pipeline.  It may be the
 case that you have to reconfigure and rebuild bash to enable that code.
 
 Look for PGRP_PIPE in config.h.


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



Re: Linux 2.4.4-ac2

2001-05-01 Thread J . A . Magallon


On 05.01 Hugh Dickins wrote:
 
 Don't ask me why, but I think you may find it's Peter's patch to
 the women-and-children-first in kernel/fork.c: I'm not yet running
 -ac2, but I am trying that patch, fine on UP but hanging right there
 (well, I get a go go go message too) on SMP.


After APIC_DEBUG = 1, I also get the gogo, i will try reverting the change.

 Try reversing the:
 
 - p-counter = current-counter;
 - current-counter = 0;
 + p-counter = (current-counter + 1)  1;
 + current-counter = 1;
 + current-policy |= SCHED_YIELD;
 

-- 
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.4-ac1 #1 SMP Tue May 1 11:35:17 CEST 2001 i686

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



Re: tulip driver broken in 2.4.4?

2001-05-01 Thread Jeff Garzik

Ronny Haryanto wrote:
 
 Just tried 2.4.4 yesterday and found that my eth1 was dead after 5 minutes.

Does 2.4.3 work for you?

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



Re: 2.4 and 2GB swap partition limit

2001-05-01 Thread Rogier Wolff

Stephen C. Tweedie wrote:
 Hi,
 
 On Mon, Apr 30, 2001 at 07:12:12PM +0100, Alan Cox wrote:
   paging in just released 2.4.4, but in previuos kernel, a page that was
   paged-out, reserves its place in swap even if it is paged-in again, so
   once you have paged-out all your ram at least once, you can't get any
   more memory, even if swap is 'empty'.
  
  This is a bug in the 2.4 VM, nothing more or less. It and the horrible bounce
  buffer bugs are forcing large machines to remain on 2.2. So it has to get 
  fixed
 
 Umm, 2.2 can behave in the same way.  The only difference in the 2.4
 behaviour is that 2.4 can maintain the swap cache effect for dirty
 pages as well as clean ones.  An application which creates a large
 in-core data set and then does not modify it will show exactly the
 same behaviour on 2.2.
 
 To call it a bug is to imply that fixing it is the right thing to
 do.  It might be in some cases, but discarding the swap entry has a
 cost --- you fragment swap, and if the page in memory is clean, you
 end up increasing the amount of swap IO.  

Shouldn't the algorithm be: 

- If (current_access == write )
free (swap_page);
  else
map (page, READONLY)

and 
  when a write access happens, we fault again, and map free the 
  swap-page as it is now dirty anyway. 

The extra fault when the first access is a read (e.g. in a
read-modify-write case) will seem like a lot of overhead, but if you
save an IO in 1% of the cases, it will be worth it...

Is swap allocated congruently? I didn't think so. That would mean
that if one page of a process has to be paged out, you allocate an
area on the swap that maps directly on the whole adressing space of
that process. That way prefetching stuff from swap can actually help a
lot.

Roger. 

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



[cliff@oisec.net: PROBLEM: 2.4.4, 2.4.4-ac1, 2.4.4-ac2, neighbour discovery bug (ipv6)]

2001-05-01 Thread Cliff Albert

It seems that only ICMPv6 packages panic the kernel, sshing to the box on IPv6 keeps 
it alive, but ping6 and traceroute6 to the box kill it in about 10 seconds.

-- 
Cliff Albert| IRCNet:#linux.nl, #ne2000, #linux, #freebsd.nl
[EMAIL PROTECTED] |#openbsd, #ipv6, #cu2.nl
-[ICQ: 18461740]| 6BONE: CA2-6BONE   RIPE: CA3348-RIPE




When i traceroute6 my 2.4.4 box on my local lan, the 2.4.4 box panic's after about 10 
seconds. The traceroute6 completes on the other box.

2.4.3-ac14 doesn't experience these problems. Only 2.4.4 (with or without ac{1,2}) 
panics

 traceroute6 output 
traceroute to neve.oisec.net (3ffe:8114:2000:0:250:bfff:fe21:629a) from 
3ffe:8114:2000:0:210:4bff:feb3:1fb4, 30 hops max, 16 byte packets
 1  neve.oisec.net (3ffe:8114:2000:0:250:bfff:fe21:629a)  0.583 ms  0.278 ms  0.233 ms


wait 10 seconds and the following appears (unfortunately no stack dumps :()

 panic info 2.4.4-ac2 
CPU 0
EIP 0010:[c0217314]
EFLAGS  00010206
eax: c13c2060
ebx: fffd
ecx: 
edx: ca65b1dc
esi: 
edi: 0018
ebp: cbf72000
esp: c029feb0
ds:  0018
es:  0018
ss:  0018
Process swapper (pid: 0, stackpage=c029f000)

Call Trace:

 c021e828 [ndisc_send_ns]
 c01e912c [deliver_to_old_ones]
 c021ecfd [ndisc_error_report]
 c01efd2b [ip_route_input_slow]
 c01eb7ab [neigh_timer_handler]
 c01eb664 [neigh_timer_handler]
 c0119f12 [timer_bh]
 c010b2db [timer_interrupt]
 c0116e5f [bh_action]
 c0116d98 [tasklet_hi_action]
 c0116c9f [do_softirq]
 c0107e41 [do_IRQ]
 c0105120 [default_idle]
 c0105120 [default_idle]
 c0106b14 [ret_from_intr]
 c0105120 [default_idle]
 c0105120 [default_idle]
 c0100018 [startup_32]
 c0105143 [default_idle]
 c01051a9 [cpu_idle]
 c0105000 [init]
 c0100197 [L6]

 panic info 2.4.4-ac1 
CPU 0
EIP 0010:[c0217354]
EFLAGS  00010206
eax: c13c2060
ebx: fffd
ecx: 
edx: cb73e35c
esi: 
edi: 0018
ebp: cbf72000
esp: c029feb0
ds:  0018
es:  0018
ss:  0018
Process swapper (pid: 0, stackpage=c029f000)

Call Trace:

 c021e868 [ndisc_send_ns]
 c01e916c [deliver_to_old_ones]
 c021ed3d [ndisc_error_report]
 c01e5d6b [ip_route_input_slow]
 c01eb7eb [neigh_timer_handler]
 c01eb6a4 [neigh_timer_handler]
 c0119f02 [timer_bh]
 c010b2db [timer_interrupt]
 c0116e4f [bh_action]
 c0116d88 [tasklet_hi_action]
 c0116c8f [do_softirq]
 c0107e41 [do_IRQ]
 c0105120 [default_idle]
 c0105120 [default_idle]
 c0106b14 [ret_from_intr]
 c0105120 [default_idle]
 c0105120 [default_idle]
 c0100018 [startup_32]
 c0105143 [default_idle]
 c01051a9 [cpu_idle]
 c0105000 [init]
 c0100197 [L6]

 panic info 2.4.4 

CPU 0
EIP 0010:[c021aa64]
EFLAGS  00010206
eax: c13e3060
ebx: fffd
ecx: 
edx: c80ef3dc
esi: 
edi: 0018
ebp: cbf7ac00
esp: c02b9eb0
ds:  0018
es:  0018
ss:  0018
Process swapper (pid: 0, stackpage=c02b9000)

Call Trace:

 c0221fe8 [ndisc_send_ns]
 c01ec2bc [deliver_to_old_ones]
 c02224ed [ndisc_error_report]
 c01e8d0b [ip_route_input_slow]
 c01ee93b [neigh_timer_handler]
 c01ee7f4 [neigh_timer_handler]
 c0119402 [timer_bh]
 c010aa3c [timer_interrupt]
 c011634f [bh_action]
 c0116288 [tasklet_hi_action]
 c011618f [do_softirq]
 c0107ec1 [do_IRQ]
 c0105120 [default_idle]
 c0105120 [default_idle]
 c0106b24 [ret_from_intr]
 c0105120 [default_idle]
 c0105120 [default_idle]
 c0100018 [startup_32]
 c0105143 [default_idle]
 c01051a9 [cpu_idle]
 c0105000 [init]
 c0100197 [L6]


-- 
Cliff Albert| IRCNet:#linux.nl, #ne2000, #linux, #freebsd.nl
[EMAIL PROTECTED] |#openbsd, #ipv6, #cu2.nl
-[ICQ: 18461740]| 6BONE: CA2-6BONE   RIPE: CA3348-RIPE
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




When did the PPC port start handling Real Time Signals

2001-05-01 Thread george anzinger

I know it did not at 2.2.14 and did at 2.4.0.

Was 2.4.0 the first PPC kernel to handle Real Time Signals?

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



Re: [PATCH] adding PCI bus information to SCSI layer

2001-05-01 Thread Richard Gooch

Ingo Oeser writes:
 On Mon, Apr 30, 2001 at 07:27:13PM -0600, Richard Gooch wrote:
  Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0
 
 What about /dev/bus/pci/0 or /dev/bus/pci/pci0 instead?
 
 That way we could hook roots of busses (which are . nodes, like
 if they where mounted independently) better into /dev/bus.

I'm wary of this, because Linus has stated that the current struct
pci_dev is really meant to be a generic thing, and it might change to
struct dev (now that we've renamed the old struct dev to struct
netdev).

So, if the bus management code is maintaining some kind of unified
tree, it might not make sense to have a /dev/bus/pci and
/dev/bus/sbus.

 And even implement the thing as a mount point later, if we go the way
 Al Viro suggested and have independent device filesystems
 for the subsystems themselves.

As I understand it, Al want to turn every driver into a filesystem,
instead of using an existing FS (devfs). I can't see the point. There
certainly haven't been any technical benefits put forward for this
idea.

I spoke to Linus about this, and he wants to leave the option open for
some drivers to implement their own FS rather than calling into devfs.
He cited iSCSI as a case where this might be useful (since you need to
do something different for readdir() and lookup()). I'll be
experimenting with iSCSI myself, and I'll try out a modification to
devfs which allows a driver to register lookup() and readdir() methods
when calling devfs_mk_dir(). If this can be done sanely, then it would
provide an easier interface than using the VFS to implement a new FS.
So this particular issue remains open.

However, it's my understanding that Linus isn't trying to push
existing drivers, which work well with devfs, into implementing their
own FS. He just wants the option left open for new drivers where a
driver-specific FS makes more sense.

Regards,

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



Re: SMP races in proc with thread_struct

2001-05-01 Thread Alexander Viro



On Tue, 1 May 2001, Todd Inglett wrote:

 Perhaps this is old news...but...
 
 I can easily create a race when reading /proc/pid/stat
 (fs/proc/{base.c,array.c}) where a rapidly reading application, such as
 top, starts reading stats for a thread which goes away during the
 read.  This is easily reproduced with a program that rapidly forks and
 exits while top is running.
 
 On inspection, I don't see how the code can expect the thread_struct to
 stay around since it is not holding any lock for the duration of its
 use.  The code could hold the thread_struct's lock (after verifying it
 still exists while holding tasklist_lock I would imagine), but for
 performance I would think a better solution would be to copy the struct
 since stale data is probably ok in this case.
 
 Dereferencing a non-existent thread_struct is clearly not ok.
 
 Would anyone familiar with this code care to comment?

Code bumps the reference count of couple of pages that hold task_struct
when it opens the file.

Thus when task exits they won't be freed and won't be reused. Checking
that exit had already happened is trivial (and done).  And for anything
long said lock is held only while we acquire the reference
to task_struct component.

When you finally release the dentry of /proc/pid (and thus are guaranteed
that none of its children are used) you drop the reference to these two pages.
If process had exited while you were holding them - well, that's when
they are freed.

I really wonder what you've managed to reproduce - normal behaviour is
that as soon as task exits you can't access /proc/pid and any
access to already opened files in it fails with -ENOENT. Had you been
able to get something else?

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



Re: X15 alpha release: as fast as TUX but in user space

2001-05-01 Thread Ingo Molnar


On Tue, 1 May 2001, Fabio Riccardi wrote:

 This is actually a bug in the current X15, I know how to fix it (with
 negligible overhead) but I've been lazy :)

yep, i think it's pretty straightforward: you have a cache of open file
descriptors (like Squid i think), and you can start a background 'cache
synchronization thread' that does a stat() on every open file's real VFS
path, every second or so. This should have small overhead (the number of
file descriptors cached should be limited anyway via some sort of LRU),
and guarantees 'practical coherency', without having the overhead of
immediate coherency. [total coherency is pointless anyway, not even the
kernel guarantees it to all parallel VFS users.]

Ingo

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



Re: Linux 2.4.4-ac2

2001-05-01 Thread boris

On Tue, May 01, 2001 at 04:50:52PM +0100, Hugh Dickins wrote:
 
 Don't ask me why, but I think you may find it's Peter's patch to
 the women-and-children-first in kernel/fork.c: I'm not yet running
 -ac2, but I am trying that patch, fine on UP but hanging right there
 (well, I get a go go go message too) on SMP.
 
 Try reversing the:
 
 - p-counter = current-counter;
 - current-counter = 0;
 + p-counter = (current-counter + 1)  1;
 + current-counter = 1;
 + current-policy |= SCHED_YIELD;
 
 and see if that works for you too.

OK works here ...


 boris
 

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



Re: isa_read/write not available on ppc - solution suggestions ??

2001-05-01 Thread Linus Torvalds

In article [EMAIL PROTECTED],
 [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
 
 To get the pcmcia ibmtr driver (ibmtr/ibmtr_cs) working on ppc, all the
 isa_read/write's have to be changed to regular read/write due to the 
lack
 of the isa_read/write functions for ppc.

 Treat it like a PCI device and use ioremap().  Then change isa_readl()
 to readl() etc.

Bleurgh, the latest version of the driver (not in the kernel yet) searches 
for turbo based cards by checking the isa address space from 0xc - 
0xe in 8k chunks. So we'd have to ioremap each 8k section, check it, 
find out the adapter isn't there and then iounmap it. 

Oh well, if that's what it takes =:0

I would suggest the opposite approach instead: make the PPC just support
isa_readx/isa_writex instead.

Much simpler, and doesn't need changes to (correct) driver sources.

I bet that the patch will be smaller too. It's a simple case of
 - do the ioremap() _once_ at bootup, save the result in a static
   variable somewhere.
 - implement the (one-liner) isa_readx/isa_writex functions.

On many architectures you don't even need to do the ioremap, as it's
always available (same as on x86).

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



Re: isa_read/write not available on ppc - solution suggestions ??

2001-05-01 Thread mike_phillips

 I would suggest the opposite approach instead: make the PPC just 
 support isa_readx/isa_writex instead.

 Much simpler, and doesn't need changes to (correct) driver sources.

 I bet that the patch will be smaller too. It's a simple case of
 - do the ioremap() _once_ at bootup, save the result in a static
   variable somewhere.
 - implement the (one-liner) isa_readx/isa_writex functions.

 On many architectures you don't even need to do the ioremap, as it's
 always available (same as on x86).

That would be my preferred solution as well. The one-liners are easy, the 
ioremap may be more fun. Time to investigate the ppc code and docs. 

Unless one of the kindly ppc maintainers who knows far more about the arch 
than me would like to do it :)

Mike

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



Re: tulip driver broken in 2.4.4?

2001-05-01 Thread Ronny Haryanto

On 01-May-2001, Jeff Garzik wrote:
 Ronny Haryanto wrote:
  
  Just tried 2.4.4 yesterday and found that my eth1 was dead after 5 minutes.
 
 Does 2.4.3 work for you?

Yes. I just tried 2.4.3, and it works fine. So it looks like there's a bug
introduced between 2.4.3 and 2.4.4. Too bad I can't use 2.4.3; I need 2.4.4
due to the VIA chipset bug. Is there any other info that I could provide
from here to help debugging?

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



[PATCH] Dead keys

2001-05-01 Thread Stian Sletner

Hello.

I've long been bothered by the fact that 3 of the 6 dead keys in the
kernel are actually mapped to the wrong characters.  Now, I realize that
there might be some deliberate reason for this, since it's such an
obvious annoyance and since they all fit in US ASCII the way it is now.
Also, I've noticed that it is the same way in X11, independent from
this.  I'd like to know the reasoning, if there is one.

Normally, you wouldn't notice this too much, since the compose rules
are set up in such a way that you can use the dead keys to compose what
you would expect, anyway.  However, if you were to press a dead key and
then space, or some un-composable key (to get the dead key character by
itself), you would get the wrong character.  Instead of '¨' (ISO 8859-1
decimal 168: DIAERESIS), you would get '' (ASCII decimal 34); instead
of '´' (ISO 8859-1 decimal 180: ACUTE ACCENT), you would get '\'' (ASCII
decimal 39); and instead of '¸' (ISO 8859-1 decimal 184: CEDILLA), you
would get ',' (ASCII decimal 44).

I took the liberty of creating a patch that changes this in keyboard.c,
and also adds compose rules to defkeymap.map so they can be used
properly.  If there is some reason why this shouldn't be applied, I'd
like to know what, since this makes my console life easier. :)

Thanks.

(Patched against 2.4.3, but it applies to 2.4.4 too.  Just tested it.)

diff -u linux/drivers/char/defkeymap.map linux-patched/drivers/char/defkeymap.map
--- linux/drivers/char/defkeymap.mapFri Feb 24 20:38:27 1995
+++ linux-patched/drivers/char/defkeymap.mapThu Apr 26 22:09:13 2001
@@ -291,12 +291,16 @@
 compose '`' 'a' to 'à'
 compose '\'' 'A' to 'Á'
 compose '\'' 'a' to 'á'
+compose '´' 'A' to 'Á'
+compose '´' 'a' to 'á'
 compose '^' 'A' to 'Â'
 compose '^' 'a' to 'â'
 compose '~' 'A' to 'Ã'
 compose '~' 'a' to 'ã'
 compose '' 'A' to 'Ä'
 compose '' 'a' to 'ä'
+compose '¨' 'A' to 'Ä'
+compose '¨' 'a' to 'ä'
 compose 'O' 'A' to 'Å'
 compose 'o' 'a' to 'å'
 compose '0' 'A' to 'Å'
@@ -307,22 +311,32 @@
 compose 'a' 'e' to 'æ'
 compose ',' 'C' to 'Ç'
 compose ',' 'c' to 'ç'
+compose '¸' 'C' to 'Ç'
+compose '¸' 'c' to 'ç'
 compose '`' 'E' to 'È'
 compose '`' 'e' to 'è'
 compose '\'' 'E' to 'É'
 compose '\'' 'e' to 'é'
+compose '´' 'E' to 'É'
+compose '´' 'e' to 'é'
 compose '^' 'E' to 'Ê'
 compose '^' 'e' to 'ê'
 compose '' 'E' to 'Ë'
 compose '' 'e' to 'ë'
+compose '¨' 'E' to 'Ë'
+compose '¨' 'e' to 'ë'
 compose '`' 'I' to 'Ì'
 compose '`' 'i' to 'ì'
 compose '\'' 'I' to 'Í'
 compose '\'' 'i' to 'í'
+compose '´' 'I' to 'Í'
+compose '´' 'i' to 'í'
 compose '^' 'I' to 'Î'
 compose '^' 'i' to 'î'
 compose '' 'I' to 'Ï'
 compose '' 'i' to 'ï'
+compose '¨' 'I' to 'Ï'
+compose '¨' 'i' to 'ï'
 compose '-' 'D' to 'Ð'
 compose '-' 'd' to 'ð'
 compose '~' 'N' to 'Ñ'
@@ -331,27 +345,38 @@
 compose '`' 'o' to 'ò'
 compose '\'' 'O' to 'Ó'
 compose '\'' 'o' to 'ó'
+compose '´' 'O' to 'Ó'
+compose '´' 'o' to 'ó'
 compose '^' 'O' to 'Ô'
 compose '^' 'o' to 'ô'
 compose '~' 'O' to 'Õ'
 compose '~' 'o' to 'õ'
 compose '' 'O' to 'Ö'
 compose '' 'o' to 'ö'
+compose '¨' 'O' to 'Ö'
+compose '¨' 'o' to 'ö'
 compose '/' 'O' to 'Ø'
 compose '/' 'o' to 'ø'
 compose '`' 'U' to 'Ù'
 compose '`' 'u' to 'ù'
 compose '\'' 'U' to 'Ú'
 compose '\'' 'u' to 'ú'
+compose '´' 'U' to 'Ú'
+compose '´' 'u' to 'ú'
 compose '^' 'U' to 'Û'
 compose '^' 'u' to 'û'
 compose '' 'U' to 'Ü'
 compose '' 'u' to 'ü'
+compose '¨' 'U' to 'Ü'
+compose '¨' 'u' to 'ü'
 compose '\'' 'Y' to 'Ý'
 compose '\'' 'y' to 'ý'
+compose '´' 'Y' to 'Ý'
+compose '´' 'y' to 'ý'
 compose 'T' 'H' to 'Þ'
 compose 't' 'h' to 'þ'
 compose 's' 's' to 'ß'
 compose '' 'y' to 'ÿ'
+compose '¨' 'y' to 'ÿ'
 compose 's' 'z' to 'ß'
 compose 'i' 'j' to 'ÿ'
diff -u linux/drivers/char/keyboard.c linux-patched/drivers/char/keyboard.c
--- linux/drivers/char/keyboard.c   Mon Oct 16 21:58:51 2000
+++ linux-patched/drivers/char/keyboard.c   Mon Apr 23 12:02:36 2001
@@ -557,11 +557,11 @@
 }
 
 #define A_GRAVE  '`'
-#define A_ACUTE  '\''
+#define A_ACUTE  '\264'
 #define A_CFLEX  '^'
 #define A_TILDE  '~'
-#define A_DIAER  ''
-#define A_CEDIL  ','
+#define A_DIAER  '\250'
+#define A_CEDIL  '\270'
 static unsigned char ret_diacr[NR_DEAD] =
{A_GRAVE, A_ACUTE, A_CFLEX, A_TILDE, A_DIAER, A_CEDIL };

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



Compiling modules for kernel 2.4

2001-05-01 Thread shreenivasa H V

Hi,
I am having trouble compiling the modules for kernel 2.4. The compilation
doesn't go through, it just goes into each directory and says nothing to do
and comes out. The object files are not created. Has anyone else faced the
same problem? Do I have to do any other setup before doing

make mrproper config dep clean bzImage modules modules_install

I tried the same stuff with with kernel 2.2.16 and the modules compile fine.

thanks,
shreeni.


Get free email and a permanent address at http://www.netaddress.com/?N=1
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: tulip driver broken in 2.4.4?

2001-05-01 Thread Jacob Luna Lundberg


Well, I guess I should chip in here with the rather amusing fact that
2.4.4 is the first kernel *not* to do this to me...  ;-)

I am, of course, glad to help out testing stuff if needed.  My card is
also a LinkSys LNE100TX v4.1, which the tulip driver identifies as an
ADMtek Comet rev 17 (although somebody told me it's really a Centaur).

-Jacob

On Tue, 1 May 2001, Ronny Haryanto wrote:
 On 01-May-2001, Jeff Garzik wrote:
  Ronny Haryanto wrote:
   
   Just tried 2.4.4 yesterday and found that my eth1 was dead after 5 minutes.
  
  Does 2.4.3 work for you?
 
 Yes. I just tried 2.4.3, and it works fine. So it looks like there's a bug
 introduced between 2.4.3 and 2.4.4. Too bad I can't use 2.4.3; I need 2.4.4
 due to the VIA chipset bug. Is there any other info that I could provide
 from here to help debugging?


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



Re: iso9660 endianness cleanup patch

2001-05-01 Thread H. Peter Anvin

Andrzej Krzysztofowicz wrote:
 
 Are you sure that the arguments of the following casting
 
  + return le16_to_cpu(*(u16 *)p);
 
  + return be16_to_cpu(*(u16 *)p);
 
  + return le32_to_cpu(*(u32 *)p);
 
  + return be32_to_cpu(*(u32 *)p);
 
 are properly aligned ?
 I did not revise the code to check it, but AFAIK improperly aligned
 char* pointers cause problem with casting to pointers to 16/32-bit data
 on some architectures (I heard of sucj a problem with alpha).
 
 Maybe there was a reason that the original code did operate on bytes here...
 

Oh bother, you're right of course.  We need some kind of standardized
macro for indirecting through a potentially unaligned pointer.  It can
just do the dereference (e.g. x86), use left/right accesses (e.g. MIPS),
or do it by byte (others).

Ports people, what do you think?

-hpa

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



RE: DPT I2O RAID and Linux I2O

2001-05-01 Thread Patrick Allaire

Hi,

Is this I2O implementation supporting PCI devices ?

Yesterday I post something about that, I have a CompactPCI computer with 2
computers in it. One master and one slave. The slave one, is has a non
transparent pci-to-pci bridge : DEC (INTEL) 21554, wich support I2O
messaging, I want both computer to communicate by this mean, but I cant seam
to be able to make the I2O working, I was trying on 2.2.19 ... but I will
try on 2.4.4. But is there allready a device who is doing this kind of
communication, I would like to look a some code to see how htis I2O is
working. I have looked a some docs, but I didnt find any ... I guess I will
be stuck with reading all the I2O specs from the SIG.

Thank you for your time.





 -Message d'origine-
 De : [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]De la part de Alan Cox
 Envoye : April 30, 2001 9:22 PM
 A : [EMAIL PROTECTED]
 Objet : DPT I2O RAID and Linux I2O


 A few people have asked about the dpt_i2o driver recently. If you
 have a DPT
 I2O card please try a late 2.4.3-ac kernel. It should now work when you do
 'modprobe i2o_scsi'

 After a lot of reviewing of the dpt driver I figured out what command was
 upsetting the beast and added a workaround for it. I also fixed a pile of
 bugs in the drivers that caused failed table queries to corrupt memory
 in some cases (the DPT tended to trigger these and so made the box reboot
 if you used i2oproc or i2oconfig.

 I'd also like to say thanks to DPT (now Adaptec) for supplying me
 with a card
 which meant that in combination with their driver I was eventually able to
 figure out the cure.

 More feedback from DPT i2o raid card users would be useful

 Alan

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

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



Re: iso9660 endianness cleanup patch

2001-05-01 Thread H. Peter Anvin

[EMAIL PROTECTED] wrote:
 
 Oh bother, you're right of course.  We need some kind of standardized
 macro for indirecting through a potentially unaligned pointer.  It can
 just do the dereference (e.g. x86), use left/right accesses (e.g. MIPS),
 or do it by byte (others).
 
 Ports people, what do you think?
 

My, my, my... I'm really 100% alert this morning.  Before anyone clues me
in, I did find asm/unaligned.h when I actually bothered looking.  New
patch in the making.

-hpa

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



Re: FIXED iso9660 endianness cleanup patch

2001-05-01 Thread H. Peter Anvin

Okay, this one should actually work as advertised.  Pardon the mental
meltdown earlier.

This also changes extern inline to static inline (per Linus' request)
and always ignores the bigendian part of a bi-endian datum (per Tim
Riker's observation that lots of [Windoze?] programs get that wrong.)

It's still a bit of a loss to have to do unaligned load and endianness
conversion as two operations; on some machines it's doubtlessly faster to
do both at the same time.  However, *those* macros I didn't find...

-hpa

diff -ur stock3/linux-2.4.4/fs/isofs/util.c linux-2.4.4/fs/isofs/util.c
--- stock3/linux-2.4.4/fs/isofs/util.c  Wed Nov 29 10:11:38 2000
+++ linux-2.4.4/fs/isofs/util.c Mon Apr 30 20:49:33 2001
@@ -1,90 +1,9 @@
 /*
  *  linux/fs/isofs/util.c
- *
- *  The special functions in the file are numbered according to the section
- *  of the iso 9660 standard in which they are described.  isonum_733 will
- *  convert numbers according to section 7.3.3, etc.
- *
- *  isofs special functions.  This file was lifted in its entirety from
- *  the 386BSD iso9660 filesystem, by Pace Willisson [EMAIL PROTECTED].
  */
 
 #include linux/time.h
-
-int
-isonum_711 (char * p)
-{
-   return (*p  0xff);
-}
-
-int
-isonum_712 (char * p)
-{
-   int val;
-   
-   val = *p;
-   if (val  0x80)
-   val |= 0xff00;
-   return (val);
-}
-
-int
-isonum_721 (char * p)
-{
-   return ((p[0]  0xff) | ((p[1]  0xff)  8));
-}
-
-int
-isonum_722 (char * p)
-{
-   return (((p[0]  0xff)  8) | (p[1]  0xff));
-}
-
-int
-isonum_723 (char * p)
-{
-#if 0
-   if (p[0] != p[3] || p[1] != p[2]) {
-   fprintf (stderr, invalid format 7.2.3 number\n);
-   exit (1);
-   }
-#endif
-   return (isonum_721 (p));
-}
-
-int
-isonum_731 (char * p)
-{
-   return ((p[0]  0xff)
-   | ((p[1]  0xff)  8)
-   | ((p[2]  0xff)  16)
-   | ((p[3]  0xff)  24));
-}
-
-int
-isonum_732 (char * p)
-{
-   return (((p[0]  0xff)  24)
-   | ((p[1]  0xff)  16)
-   | ((p[2]  0xff)  8)
-   | (p[3]  0xff));
-}
-
-int
-isonum_733 (char * p)
-{
-#if 0
-   int i;
-
-   for (i = 0; i  4; i++) {
-   if (p[i] != p[7-i]) {
-   fprintf (stderr, bad format 7.3.3 number\n);
-   exit (1);
-   }
-   }
-#endif
-   return (isonum_731 (p));
-}
+#include linux/iso_fs.h
 
 /* 
  * We have to convert from a MM/DD/YY format to the Unix ctime format.
diff -ur stock3/linux-2.4.4/include/linux/iso_fs.h linux-2.4.4/include/linux/iso_fs.h
--- stock3/linux-2.4.4/include/linux/iso_fs.h   Fri Apr 27 15:48:20 2001
+++ linux-2.4.4/include/linux/iso_fs.h  Tue May  1 11:45:21 2001
@@ -165,14 +165,46 @@
 #define ISOFS_SUPER_MAGIC 0x9660
 
 #ifdef __KERNEL__
-extern int isonum_711(char *);
-extern int isonum_712(char *);
-extern int isonum_721(char *);
-extern int isonum_722(char *);
-extern int isonum_723(char *);
-extern int isonum_731(char *);
-extern int isonum_732(char *);
-extern int isonum_733(char *);
+/* Number conversion inlines, named after the section in ISO 9660
+   they correspond to. */
+
+#include asm/byteorder.h
+#include asm/unaligned.h
+
+static inline int isonum_711(char *p)
+{
+   return *(u8 *)p;
+}
+static inline int isonum_712(char *p)
+{
+   return *(s8 *)p;
+}
+static inline int isonum_721(char *p)
+{
+   return le16_to_cpu(get_unaligned((u16 *)p));
+}
+static inline int isonum_722(char *p)
+{
+   return be16_to_cpu(get_unaligned((u16 *)p));
+}
+static inline int isonum_723(char *p)
+{
+   /* Ignore bigendian datum due to broken mastering programs */
+   return le16_to_cpu(get_unaligned((u16 *)p));
+}
+static inline int isonum_731(char *p)
+{
+   return le32_to_cpu(get_unaligned((u32 *)p));
+}
+static inline int isonum_732(char *p)
+{
+   return be32_to_cpu(get_unaligned((u32 *)p));
+}
+static inline int isonum_733(char *p)
+{
+   /* Ignore bigendian datum due to broken mastering programs */
+   return le32_to_cpu(get_unaligned((u32 *)p));
+}
 extern int iso_date(char *, int);
 
 extern int parse_rock_ridge_inode(struct iso_directory_record *, struct inode *);



[PATCH] Re: Linux 2.4.4-ac2

2001-05-01 Thread J . A . Magallon


On 05.01 Hugh Dickins wrote:
 On Tue, 1 May 2001, J . A . Magallon wrote:
   
   OK works here ...
  
  Me too.
  
  Perhaps this reschedules ok in UP but kinda fails in SMP...
 
 Great.  And see Andrea's SCHED_YIELD explanation in the sluggish
 mail thread.  Well, I didn't try to understand it in full, and I
 think he was expecting another thread to hang, rather than the main
 startup itself; but no doubt deeper thought would make sense of it all.
 

I saw it. Minimal change to make 2.4.4-ac2 work:
== patch-fork-yield
--- linux/kernel/fork.c.origTue May  1 20:03:12 2001
+++ linux/kernel/fork.c Tue May  1 20:52:18 2001
@@ -677,8 +677,11 @@
 * few simple things and then exec(). This is only important in the
 * first timeslice. In the long run, the scheduling behavior is
 * unchanged.
+* Make sure the child gets the SCHED_YIELD flag cleared, even if
+* it inherited it, to avoid deadlocks.
 */
p-counter = (current-counter + 1)  1;
+   p-policy = ~SCHED_YIELD;
current-counter = 1;
current-policy |= SCHED_YIELD;
current-need_resched = 1;

Is this enough (Andrea?) or just works for me ?.

-- 
J.A. Magallon  #  Let the source
mailto:[EMAIL PROTECTED]  #  be with you, Luke... 

Linux werewolf 2.4.4-ac1 #1 SMP Tue May 1 11:35:17 CEST 2001 i686

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



Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability

2001-05-01 Thread Seth Goldberg

Will Newton wrote:

  I Should clarify that this is the KX133A chipset.  In any event,
there are a bunch of people having this problem (check out the list
archives).  I just upgraded to this IWILL board from an Abit KA7-RAID
(which worked with no problem), so I'm just trying tofgure it out :)

 -Seth

 
  is exhibiting weird behavior under K7 optimizations. The jist of my
  research is that compiling a kernel for ANY CPU with the Athlon MMX
  optimization
  *AND* 3DNOW results in massive amounts of oops'es and total system
  instability. The following is what I've tried:
 
 With:
 
 Athlon 700
 Asus K7V (KX133 based)
 
 I have been running Athlon based kernels for months, no problems (well,
 none like you mention).
 
 gcc 2.96-81 BTW
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



OnStream USB

2001-05-01 Thread Geoffrey Gallaway

Hello,

I am considering getting an OnStream USB tape backup drive. I want the
USB version because I have about 4 machines all on different networks
that need to be backed up. Using USB would allow me to move the unit
from one machine to another without rebooting the machine.

I see that the SCSI version of the drive seems to be supported in linux
but I can only find tidbits of information that don't confirm or deny
this. Listed below are two sites that have some information which seem 
to confirm that the drive does indeed work, but I simply want to be 
sure.

http://www2.one-eyed-alien.net/~mdharm/linux-usb/
http://linux1.onstream.nl/test/

Thank you,
Geoff

-- 
Geoffrey Gallaway || 
[EMAIL PROTECTED] || Clones are people two.
D e v o r z h u n ||
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



[PATCH] strtok - strsep (The Easy Cases)

2001-05-01 Thread Rene Scharfe

Hello,

the patch at the bottom does the bulk job of strtok replacement. It's a
very boring patch, containing easy cases, only. It became a bit big, too,
but I trust you can digest it nevertheless. It's made against kernel
version 2.4.4.

What is the benefit of getting rid of strtok? It is for cutting strings
into pieces and it's used in argument parsing code of most file
systems and framebuffers. The problem is: strtok is not reentrant and its
manpage tells you to stop using it. There is a replacement function:
strsep. strsep has the added benefit of returning empty tokens, too. We
don't need strtok, it's a bug - do you need any more reasons for replacing
it? In the longer run I want the kernel to be completely cleaned from
strtok - expect more patches to come.

Please apply this patch to the official version of the kernel.


René




diff -ur linux-2.4.4/arch/m68k/atari/config.c linux-2.4.4-rs/arch/m68k/atari/config.c
--- linux-2.4.4/arch/m68k/atari/config.cTue Nov 28 02:57:34 2000
+++ linux-2.4.4-rs/arch/m68k/atari/config.c Tue May  1 17:03:46 2001
@@ -206,13 +206,15 @@
 char *p;
 int ovsc_shift;
 
-/* copy string to local array, strtok works destructively... */
+/* copy string to local array, strsep works destructively... */
 strncpy( switches, str, len );
 switches[len] = 0;
 atari_switches = 0;
 
 /* parse the options */
-for( p = strtok( switches, , ); p; p = strtok( NULL, , ) ) {
+while( p = strsep( switches, , ) ) {
+   if (!*p)
+   continue;
ovsc_shift = 0;
if (strncmp( p, ov_, 3 ) == 0) {
p += 3;
diff -ur linux-2.4.4/drivers/scsi/ibmmca.c linux-2.4.4-rs/drivers/scsi/ibmmca.c
--- linux-2.4.4/drivers/scsi/ibmmca.c   Sat Mar  3 03:38:38 2001
+++ linux-2.4.4-rs/drivers/scsi/ibmmca.cTue May  1 17:48:14 2001
@@ -1406,9 +1406,9 @@
io_base = 0;
id_base = 0;
if (str) {
-  token = strtok(str,,);
   j = 0;
-  while (token) {
+  while (token = strsep(str,,)) {
+if (!*token) continue;
 if (!strcmp(token,activity)) display_mode |= LED_ACTIVITY;
 if (!strcmp(token,display)) display_mode |= LED_DISP;
 if (!strcmp(token,adisplay)) display_mode |= LED_ADISP;
@@ -1424,7 +1424,6 @@
  scsi_id[id_base++] = simple_strtoul(token,NULL,0);
j++;
 }
-token = strtok(NULL,,);
   }
} else if (ints) {
   for (i = 0; i  IM_MAX_HOSTS  2*i+2  ints[0]; i++) {
diff -ur linux-2.4.4/drivers/video/acornfb.c linux-2.4.4-rs/drivers/video/acornfb.c
--- linux-2.4.4/drivers/video/acornfb.c Sat Apr 28 12:23:20 2001
+++ linux-2.4.4-rs/drivers/video/acornfb.c  Tue May  1 17:03:46 2001
@@ -1527,7 +1527,7 @@
 
acornfb_init_fbinfo();
 
-   for (opt = strtok(options, ,); opt; opt = strtok(NULL, ,)) {
+   while (opt = strsep(options, ,)) {
if (!*opt)
continue;
 
diff -ur linux-2.4.4/drivers/video/amifb.c linux-2.4.4-rs/drivers/video/amifb.c
--- linux-2.4.4/drivers/video/amifb.c   Sat Apr 28 12:23:20 2001
+++ linux-2.4.4-rs/drivers/video/amifb.cTue May  1 17:03:46 2001
@@ -1195,7 +1195,9 @@
if (!options || !*options)
return 0;
 
-   for (this_opt = strtok(options, ,); this_opt; this_opt = strtok(NULL, ,)) {
+   while (this_opt = strsep(options, ,)) {
+   if (!*this_opt)
+   continue;
if (!strcmp(this_opt, inverse)) {
amifb_inverse = 1;
fb_invert_cmaps();
diff -ur linux-2.4.4/drivers/video/atafb.c linux-2.4.4-rs/drivers/video/atafb.c
--- linux-2.4.4/drivers/video/atafb.c   Sat Apr 28 12:23:20 2001
+++ linux-2.4.4-rs/drivers/video/atafb.cTue May  1 17:03:46 2001
@@ -2899,7 +2899,7 @@
 if (!options || !*options)
return 0;
  
-for(this_opt=strtok(options,,); this_opt; this_opt=strtok(NULL,,)) {
+while (this_opt = strsep(options, ,)) {
if (!*this_opt) continue;
if ((temp=get_video_mode(this_opt)))
default_par=temp;
diff -ur linux-2.4.4/drivers/video/aty128fb.c linux-2.4.4-rs/drivers/video/aty128fb.c
--- linux-2.4.4/drivers/video/aty128fb.cFri Feb  9 20:30:23 2001
+++ linux-2.4.4-rs/drivers/video/aty128fb.c Tue May  1 17:03:46 2001
@@ -1614,8 +1614,9 @@
 if (!options || !*options)
return 0;
 
-for (this_opt = strtok(options, ,); this_opt;
-this_opt = strtok(NULL, ,)) {
+while (this_opt = strsep(options, ,)) {
+   if (!*this_opt)
+   continue;
if (!strncmp(this_opt, font:, 5)) {
char *p;
int i;
diff -ur linux-2.4.4/drivers/video/atyfb.c linux-2.4.4-rs/drivers/video/atyfb.c
--- linux-2.4.4/drivers/video/atyfb.c   Sat Apr 28 12:23:20 2001
+++ linux-2.4.4-rs/drivers/video/atyfb.cTue May  1 17:03:46 2001
@@ -4062,8 +4062,9 @@
 if (!options || !*options)
return 0;
 
-for 

  1   2   3   >