Re: query: IP over PCI?

[Adrian Cox]

Josh Fryman wrote:


> there have been many references in the past (notably in the beowulf
> community) about TCP/IP over PCI -- that was way back with kernel
> 2.2.9 and thereabouts (1999).  at that time, there were some patches
> available to implement this...

There are four versions of this that I know of. They come from 
MontaVista, LynuxWorks, Ziatech, and myself. Mine is based on code 
originally written for ARM by Mark van Doesburg, and ported to PowerPC 
by myself. This is probably what you know from the Strongarm Beowulf 
project. I made quite large changes, which haven't been completely 
ported back to ARM. I also added a console over PCI, to avoid the need 
for a serial cable to each plug-in card. This code is available as a 
patch for 2.2 kernels at:

ftp://ftp.agelectronics.co.uk/pub/pcimsg-patch-20001201.gz

- Adrian Cox

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: hang on mount, 2.4.2-pre4, VIA

[Tobias Ringstrom]

On Tue, 20 Feb 2001, Dan Christian wrote:
> Hello,
>   I just tried upgrading to 2.4.2-pre4 from 2.4.1 and get a hang when
> mounting the file systems.  I have the same problem with 2.4.1-ac18.

Have you tried to set LOGLEVEL in /etc/sysconfig/init to something higher
(8)? That way you may see what is happening, instead of just getting a
kernel freeze.

/Tobias


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.1-ac20 -- SMP option + Athlon target still causes the build to break

[Miles Lane]

/usr/src/linux/include/asm/hw_irq.h:198: `current' undeclared (first use 
in this function)

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

Re: [patch] VIA 4.2x driver for 2.2 kernels

[Vojtech Pavlik]

On Tue, Feb 20, 2001 at 11:15:02PM -0800, Shane Wegner wrote:
> On Wed, Feb 21, 2001 at 08:09:19AM +0100, Vojtech Pavlik wrote:
> > On Tue, Feb 20, 2001 at 03:59:27PM -0800, Shane Wegner wrote:
> > 
> > > > You wanted my VIA driver for 2.2. Here is a patch that brings the very
> > > > latest 4.2 driver to the 2.2 kernel. The patch is against the
> > > > 2.2.19-pre13 kernel plus yours 1221 ide patch.
> > > 
> > > This drivers breaks with my HP 8110 CD-R drive.  It's
> > > sitting on primary slave of a Via 686B controler.  When I
> > > try to do a hdparm -d1 -u1 -k1 /dev/hdb, the kernel locks
> > > up hard.  Not even an oops.  Reverting to the old driver
> > > works fine.
> > 
> > Don't do that. Use the kernel option to enable DMA instead.
> > 
> > Hmm, I'll have to look into this anyway - many users seem to do that
> > and it isn't as harmless as it looks (it worked by pure luck with
> > the previous version).

> Ok, can I still use -u1 -k1 -c1 on the drives or is it even
> necessary anymore.

If you enable automatic DMA in the kernel config, it isn't necessary at
all. The VIA driver sets up everything.

> Is the deprecation of -d1 VIA IDE
> specific or does it apply to the entire subsystem.

Well, in my opinion it was always a potentially dangerous option and so
it remains. I'll update the VIA driver to make sure its not dangerous
at least with it anymore.

Scenario:

1) AutoDMA not enabled
2) VIA sets PIO mode on boot
3) User enables DMA -> IDE driver starts using dma
4) But VIA is still set to PIO mode

I'll have to make the VIA driver check when IDE dma is enabled, test
whether the chipset was already programmed for it and program the
chipset for it if needed.

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

Re: [patch] VIA 4.2x driver for 2.2 kernels

[Shane Wegner]

On Wed, Feb 21, 2001 at 08:09:19AM +0100, Vojtech Pavlik wrote:
> On Tue, Feb 20, 2001 at 03:59:27PM -0800, Shane Wegner wrote:
> 
> > > You wanted my VIA driver for 2.2. Here is a patch that brings the very
> > > latest 4.2 driver to the 2.2 kernel. The patch is against the
> > > 2.2.19-pre13 kernel plus yours 1221 ide patch.
> > 
> > This drivers breaks with my HP 8110 CD-R drive.  It's
> > sitting on primary slave of a Via 686B controler.  When I
> > try to do a hdparm -d1 -u1 -k1 /dev/hdb, the kernel locks
> > up hard.  Not even an oops.  Reverting to the old driver
> > works fine.
> 
> Don't do that. Use the kernel option to enable DMA instead.
> 
> Hmm, I'll have to look into this anyway - many users seem to do that and
> it isn't as harmless as it looks (it worked by pure luck with the
> previous version).
Ok, can I still use -u1 -k1 -c1 on the drives or is it even
necessary anymore.  Is the deprecation of -d1 VIA IDE
specific or does it apply to the entire subsystem.

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

Re: [patch] VIA 4.2x driver for 2.2 kernels

[Vojtech Pavlik]

On Tue, Feb 20, 2001 at 03:59:27PM -0800, Shane Wegner wrote:

> > You wanted my VIA driver for 2.2. Here is a patch that brings the very
> > latest 4.2 driver to the 2.2 kernel. The patch is against the
> > 2.2.19-pre13 kernel plus yours 1221 ide patch.
> 
> This drivers breaks with my HP 8110 CD-R drive.  It's
> sitting on primary slave of a Via 686B controler.  When I
> try to do a hdparm -d1 -u1 -k1 /dev/hdb, the kernel locks
> up hard.  Not even an oops.  Reverting to the old driver
> works fine.

Don't do that. Use the kernel option to enable DMA instead.

Hmm, I'll have to look into this anyway - many users seem to do that and
it isn't as harmless as it looks (it worked by pure luck with the
previous version).

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

Re: [rfc] Near-constant time directory index for Ext2

[Ed Tomlinson]

Alan Cox wrote:

>> probably a bad idea to use it, because in theory at least the VFS layer
>> might decide to switch the hash function around. I'm more interested in
>> hearing whether it's a good hash, and maybe we could improve the VFS hash
>> enough that there's no reason to use anything else..
> 
> Reiserfs seems to have done a lot of work on this and be using tea, which is
> also nice as tea is non trivial to abuse as a user to create pessimal file
> searches intentionally

The default in reiserfs is now the R5 hash, but you are right that lots of efforts 
went 
into finding this hash.  This includes testing various hashes on real directory 
structures to see which one worked best.  R5 won.

Ed Tomlinson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: loopback mount broken in 2.4.2-pre4

[Nathan Dabney]

On Wed, Feb 21, 2001 at 12:36:34AM -0500, [EMAIL PROTECTED] wrote:
> The subject gives just about all the information I have.  :)  If I try to
> mount an iso image via loopback while running 2.4.2-pre4, mount will hang
> forever.  Downgrading to 2.4.1 seems to resolve the issue (haven't tried
> any previous -pre patches).

http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.2-pre4/

-Nathan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: can somebody explain how linux support 64G memory

[Robert Read]

There are two ways, the PAE flag and the PSE-36 feature introduced in
P3. These extensions are documented in the IA-32 Intel Architecture
Software Developer's Manuals, which you can find here:

http://developer.intel.com/design/Pentium4/manuals/ 

Look in Volume 3, Chapter 3 for this info.

robert


On Wed, Feb 21, 2001 at 10:44:30AM +0800, michaelc wrote:
> Hi,
>How does linux support more than 4G memory? I 've read the
>documentation of  Intel IA-32 Architecture, I knew that OS
>just address up to 4G physical address space, If OS want to
>access additional 4-GByte section of physical memory, it must
>change the pointer in register CR3 or entries in the
>page-directory-pointer table. That means that Linux just has
>up to 4-GByte page mapping at one time , is that right?
> 
>   
> 
> -- 
> Best regards,
>  michael chen  mailto:[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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

loopback mount broken in 2.4.2-pre4

[pf-kernel]

The subject gives just about all the information I have.  :)  If I try to
mount an iso image via loopback while running 2.4.2-pre4, mount will hang
forever.  Downgrading to 2.4.1 seems to resolve the issue (haven't tried
any previous -pre patches).


---
Unsolicited advertisments to this address are not welcome.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Different CFLAGS for arch and non-arch files.

[Peter Samuelson]

[Peter Bergner]
> Hopefully someone can point me in the right direction here.
> I need to use different CFLAGS options depending on whether
> I'm compiling arch dependent code or arch independent code.

Use the per-directory $(EXTRA_CFLAGS), and/or the per-file
$(CFLAGS_foo.o).  See also $(EXTRA_AFLAGS), $(EXTRA_LDFLAGS) and
$(AFLAGS_foo.o).  I suppose there ought to be a $(LDFLAGS_foo.o) for
completeness, but nobody has needed it yet.

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

Admin: don't cross-post to the LVM list!

[Richard Gooch]

  Hi, all. Please do not cross-post messages on the LVM list to other
(open) Linux lists. I just did a reply and got a nastygram saying my
message pending moderator approval. That's a nasty trap, as people who
respond to a cross-post should not be bounced.

So, please don't crosspost when sending to a closed list.

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: [PATCH] new setprocuid syscall

[Peter Samuelson]

[BERECZ Szabolcs]
> The conclusion: it's cannot be implemented without slowdown.

Or: it cannot be implemented 100% safely and correctly without slowdown.

If you know the use you wish to put this to, and are willing to risk a
permission check somewhere being confused momentarily by a non-atomic
update of a 32-bit number (or the non-atomic update between several
32-bit numbers, which I think is less serious because then you are not
granting more than the union of the two UIDs) go ahead and patch your
kernel.

> So ignore my patch.

For official kernels, I agree.  They need to be as safe and
deterministic as possible, especially security-wise, and a semaphore on
every permission check would be ridiculous.

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

Re: Newbie ask for help: cramfs port to isofs

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:zhaoway <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> I plan to automatically de-compressing ``*.cramed'' files made with
> cramit.c (which is a simplified version of mkcramfs.c also attached
> below) from within isofs.o. This indeed isn't a very clean idea I
> agree. If you have better design, please let me know.
> 

It would be better to have this controlled by SUSP records.  It looks
like the -z option to mkisofs was intended to do this, but it never
quite got done and integrated.

-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: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Richard Gooch]

Andrea Arcangeli writes:
> On Tue, Feb 20, 2001 at 05:31:25PM -0700, Andreas Dilger wrote:
> > The reason why the IOP was changed was because the VG_CREATE ioctl now
> > depends on the vg_number in the supplied vg_t to determine which VG minor
> > number to use.  The old interface used the minor number of the opened
> > device inode, but for devfs the device inodes don't exist until the VG
> > is created...  If you run an older kernel with new tools, you can only
> > use the first VG.
> 
> Ah, I was reading the patch incidentally against 2.2 patch where devfs support
> is not included, so I wasn't thinking the devfs way ;). Thanks for the
> explanation.
> 
> I assume it's not possible to mknod on top of devfs.  So then we
> could use a temporary device in /var/tmp or whatever for that.
> However those workarounds tends to be ugly.

You definately can mknod(2) on devfs.

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: Reiserfs, 3 Raid1 arrays, 2.4.1 machine locks up

[Colonel]

   >There seem to be several reports of reiserfs falling over when memory is
   >low.  It seems to be undetermined if this problem is actually reiserfs
   > or MM related, but there are other threads on this list regarding similar
   > issues. This would explain why the same disk would work on a different
   > machine with more memory.  Any chance you could add memory to the box
   > temporarily just to see if it helps, this may help prove if this is the
   > problem or not.
   >
   >
   > Well, I didn't happen to start the thread, but your comments may
   > explain some "gee I wonder if it died" problems I just had with my
   > 2.4.1-pre2+reiser test box.  It only has 16M, so it's always low
   > memory (never been a real problem in the past however).  The test
   > situation is easily repeatable for me [1].  It's a 486 wall mount, so
   > it's easier to convert the fs than add memory, and it showed about
   > 200k free at the time of the sluggishness.  Previous 2.4.1 testing
   > with ext2 fs didn't show any sluggishness, but I also didn't happen to
   > run the test above either.  When I come back to the office later, I'll
   > convert the fs, repeat the test and pass on the results.
   >
   >
   > [1]  Since I decided to try to catch up on kernels, I had just grabbed
   > -ac18, cd to ~linux and run "rm -r *" via an ssh connection.  In a
   > second connection, I tried a simple "dmesg" and waited over a minute
   > for results (long enough to log in directly on the box and bring up
   > top) followed by loading emacs for ftp transfers from kernel.org,
   > which again 'went to sleep'.
   > -

   If these are freezes I had them too in 2.4.1, 2.4.2-pre1 fixed it for me.
   Really I think it was the patch in handle_mm_fault setting TASK_RUNNING.

   /RogerL

Ohoh, I see that I fat-fingered the kernel version.  The test box
kernel is 2.4.2-pre2 with Axboe's loop4 patch to the loopback fs.  It
runs a three partition drive, a small /boot in ext2, / as reiser and
swap.  I am verifying that the freeze is repeatable at the moment, and
so far I cannot cause free memory to drop to 200k and a short ice age
does not occur.  Unless I can get that to repeat, the effort will be
useless... the only real difference is swap, it was not initially
active and now it is.  Free memory never drops below 540k now, so I
would suspect a MM influence.  [EMAIL PROTECTED] didn't mention
the memory values in his initial post, but it would be interesting to
see if he simply leaves his machine alone if it recovers
(i.e. probable swap thrashing) and then determine if the freeze ever
re-occurs.  James seems to have better repeatability than I do.
Rebooting and retrying still doesn't result in a noticable freeze for
me.  Some other factor must have been involved that I didn't notice.
Still seems like MM over reiser tho.


PS for james:
>One thing I did notice was that the syncing of the raid 1 arrays went in
sequence, md0, md1, md2 instead of in parrallel.  I assume it is because
the machine just doesn't have the horsepower, etc. or is it that I have
multiple raid arrays on the same drives?

Same drives.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] exclusive wakeup for lock_buffer

[Ulf Carlsson]

> --- linux/include/linux/locks.h.orig  Mon Feb 19 23:16:50 2001
> +++ linux/include/linux/locks.h   Mon Feb 19 23:21:48 2001
> @@ -13,6 +13,7 @@
>   * lock buffers.
>   */
>  extern void __wait_on_buffer(struct buffer_head *);
> +extern void __lock_buffer(struct buffer_head *);

This doesn't match the function definition either.

Ulf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Network console project (was: LILO and serial speeds over 9600)

[H. Peter Anvin]

Hi everyone,

We have set up a network console project on sourceforge and are starting
to work on actual details.  If you're interested in this subject please
do join that list.

Please see:

http://sourceforge.net/mail/?group_id=20426

-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: finding Tekram SCSI dc395U linux patch driver:

[James Cleverdon]

:From: Juergen Schoew <[EMAIL PROTECTED]>
:Date:  Thu, 15 Feb 2001 22:46:22 +0100 (MEZ)
:Reply-To: Juergen Schoew <[EMAIL PROTECTED]>
:Organization: UNIX-AG Siegen
:To: Thomas Lau <[EMAIL PROTECTED]>
:Subject: RE: finding Tekram SCSI dc395U linux patch driver:
:Cc: [EMAIL PROTECTED]
:
:Hi,
:On 15-Feb-01 Thomas Lau wrote:
:> hey, I found this driver on mandrake kernel sources, it's ac3, but I
:> need ac14 code, also, why still not port this driver into kernel?
:> the patch file already released 1 years ago
:
:Have you checked http://www.garloff.de/kurt/linux/dc395/index.html
:there ist a driver Version 1.32 (2000-12-02).
:
:Regards
:
:Juergen Schoew


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

[Rusty Russell]

In message <[EMAIL PROTECTED]
.com> you write:
> > We unlink the module
> > We free the memory
> > 
> > At the same time another cpu may be walking the exception table that we fre
e.
> 
> True.
> 
> Rusty had a patch that locked the module list properly IIRC.

This is a while back, but I thought the solution Philipp and I came up
with was to simply used a rw semaphore for this, which was taken (read
only) on page fault if we have to scan the exception table.

Rusty.
--
Premature optmztion is rt of all evl. --DK
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: problems with reiserfs + nfs using 2.4.2-pre4

[Neil Brown]

On Tuesday February 20, [EMAIL PROTECTED] wrote:
> Hi,
> 
> On Tue, 20 Feb 2001, Neil Brown wrote:
> 
> > 2/ lookup("..").
> 
> A small question:
> Why exactly is this needed?
> 
> bye, Roman

Having read the subsequent posts, I now see what you are thinking and
know how to answer this.

The problem that I see is indeed related to rename, but not in the way
that Trond mentions.  (Tronds issue is a real, though very different,
issue). 

Suppose I have a directory path

   /a/b/c/d/e/f/g

Where filehandle X refers to /a/b and filehande Y refers to
/a/b/c/d/e/f/g

Then an NFS request comes in saying

   RENAME X/c to Y/h

If this was performed, then you would end up with a directory path
 
 /a/b

and a disconnected loop:


d/e/f/g/h
^   v
+---+

which is not good.
This possibility is protected against by the VFS layer.  It serialises
all directory renames using s_vfs_rename_sem and then checks that the
source of the rename isn't an ancestor of the target.
For this check to be reliable, each dentry for a directory must be
properly connected to the root.

Now if you have a filesystem that:

 - cannot do ".." lookups efficiently, or doesn't want to and
 - can protect against this sort of loop (and any other issues that
the VFS usually protects against) itself

then it can (with my patch) simply define decode_fh and encode_fh and
do whatever it likes, such as create a dentry that isn't properly
connected.

get_parent is only called by nfsd_find_fh_dentry which is a helper
routine which is normally called by the decode_fh function (and is
called by the default decode_fh function).
If a filesystem provides it's own decode_fh which doesn't call
nfsd_find_fh_dentry, then get_parent won't be called and isn't needed.

NeilBrown

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

Different CFLAGS for arch and non-arch files.

[Peter Bergner]

Hopefully someone can point me in the right direction here.
I need to use different CFLAGS options depending on whether
I'm compiling arch dependent code or arch independent code.
It seems the arch/XXX/Makefile only adds extra options to
CFLAGS and doesn't allow me specify options I want to apply
only to arch dependent code and others I'd like to apply
only to arch independent code.  Has anyone done such a thing?

I guess I'd like to have CFLAGS, CFLAGS_ARCH and CFLAGS_NONARCH
vars that would be set in the arch/XXX/Makefile and then break
up the SUBDIRS var in the toplevel Makefile into SUBDIRS and
ARCHSUBDIRS so we could iterate over them with the different
CFLAGS options (ie, CFLAGS + CFLAGS_NONARCH for the arch independent
files and CFLAGS + CFLAGS_ARCH for the arch dependent files).

My reason for doing this is that our new architecture's ABI
specifies the use of a TOC (table of contents) and we're running
into a TOC overflow problem.  I can use GCC's -mminimal-toc option,
but not for routines that will be called before relocation is turned
on (the global TOC contains virtual addrs of the private TOCs).
My idea is to compile all the arch dependent code without the
-minimal-toc option and all the arch independent code with the
-minimal-toc option.

Any clues on what I can/need to do would be appreciated.

Peter

--
Peter Bergner
SLIC Optimizing Translator Development / Linux PPC64 Kernel Development
IBM Rochester, MN
[EMAIL PROTECTED]

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

Need help as a Linux newcomer

[Sedat Sengul]

Hi Guys;
I am a newcomer for Linux world. I used largely pSOS and a little bit
WinCE. I tried to find some sort of documents about Kernel structure,
linux directory structure and dependency of source files in Linux. 
I am interested in Embedded Linux due to some resource restrictions.
All I found from web so far, are installation informations and tool
usage definitions.

Your help is much appreciated.
Thanks

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

can somebody explain how linux support 64G memory

[michaelc]

Hi,
   How does linux support more than 4G memory? I 've read the
   documentation of  Intel IA-32 Architecture, I knew that OS
   just address up to 4G physical address space, If OS want to
   access additional 4-GByte section of physical memory, it must
   change the pointer in register CR3 or entries in the
   page-directory-pointer table. That means that Linux just has
   up to 4-GByte page mapping at one time , is that right?

  

-- 
Best regards,
 michael chen  mailto:[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/

[BUG] 2.4.2-pre4 - kernel BUG at inode.c:885!

[Shawn Starr]

My friend has Linux on an Pentium Overdrive system I've attached the
dmesg and kern.log files.

Shawn.


Linux version 2.4.2-pre4 (root@stucko) (gcc version 2.95.3 20010125 (prerelease)) #1 
Mon Feb 19 18:37:12 EST 2001
BIOS-provided physical RAM map:
 BIOS-88: 0009f000 @  (usable)
 BIOS-88: 0170 @ 0010 (usable)
On node 0 totalpages: 6144
zone(0): 4096 pages.
zone(1): 2048 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=Linux ro root=302 BOOT_FILE=/vmlinuz
Initializing CPU#0
Detected 83.524 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 166.29 BogoMIPS
Memory: 22012k/24576k available (1069k kernel code, 2176k reserved, 422k data, 56k 
init, 0k highmem)
Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
CPU: Before vendor init, caps: 013f  , vendor = 0
Intel Pentium with F0 0F bug - workaround enabled.
CPU: After vendor init, caps: 013f   
CPU: After generic, caps: 013f   
CPU: Common caps: 013f   
CPU: Intel OverDrive PODP5V83 stepping 02
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
isapnp: Scanning for Pnp cards...
isapnp: Card 'Adaptec AVA-1505AI'
isapnp: Card '3Com 3C509B EtherLink III'
isapnp: 2 Plug & Play cards detected total
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
parport0: PC-style at 0x378 [PCSPP(,...)]
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
block: queued sectors max/low 14528kB/4842kB, 64 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
hda: ST3491A D, ATA DISK drive
hdb: QUANTUM PD210A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 836070 sectors (428 MB) w/120KiB Cache, CHS=899/15/62
hdb: 408564 sectors (209 MB) w/32KiB Cache, CHS=873/13/36
Partition check:
 hda: hda1 hda2
 hdb: hdb1 hdb2
paride: epat registered as protocol 0
pd: pd version 1.05, major 45, cluster 64, nice 0
pda: Sharing parport0 at 0x378
pda: epat 1.01, Shuttle EPAT chip c6 at 0x378, mode 1 (5/3), delay 1
pda: AVATAR  AR2250, master, 489472 blocks [239M], (956/16/32), removable media
 pda: unknown partition table
Floppy drive(s): fd0 is 1.44M
FDC 0 is an 8272A
eth0: 3c509 at 0x220, 10baseT port, address  00 a0 24 46 41 c0, IRQ 5.
3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED]
Serial driver version 5.02 (2000-08-09) with ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16450
ttyS01 at 0x02f8 (irq = 3) is a 16450
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 3M
agpgart: no supported devices found.
[drm] Initialized tdfx 1.0.0 2928 on minor 63
[drm:radeon_init] *ERROR* Cannot initialize agpgart module.
SCSI subsystem driver Revision: 1.00
request_module[scsi_hostadapter]: Root fs not mounted
request_module[scsi_hostadapter]: Root fs not mounted
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 2048)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 56k freed
eth0: Setting Rx mode to 1 addresses.


Feb 20 21:31:59 stucko kernel: Loaded 8964 symbols from /boot/System.map-2.4.2-pre4.
Feb 20 21:31:59 stucko kernel: Symbols match kernel version 2.4.2.
Feb 20 21:31:59 stucko kernel: No module symbols loaded.
Feb 20 21:31:59 stucko kernel: Linux version 2.4.2-pre4 (root@stucko) (gcc version 
2.95.3 20010125 (prerelease)) #1 Mon Feb 19 18:37:12 EST 2001
Feb 20 21:31:59 stucko kernel: BIOS-provided physical RAM map:
Feb 20 21:31:59 stucko kernel:  BIOS-88: 0009f000 @  (usable)
Feb 20 21:31:59 stucko kernel:  BIOS-88: 0170 @ 0010 (usable)
Feb 20 21:31:59 stucko kernel: On node 0 totalpages: 6144
Feb 20 21:31:59 stucko kernel: zone(0): 4096 pages.
Feb 20 21:31:59 stucko kernel: zone(1): 2048 pages.
Feb 20 21:31:59 stucko kernel: zone(2): 0 pages.
Feb 20 21:31:59 stucko kernel: Kernel command line: auto BOOT_IMAGE=Linux ro root=302 
BOOT_FILE=/vmlinuz
Feb 20 21:31:59 stucko kernel: Initializing CPU#0
Feb 20 21:31:59 stucko kernel: Detected 83.524 MHz processor.
Feb 20 21:31:59 stucko kernel: Console: colour VGA+ 80x25
Feb 20 21:31:59 stucko kernel: Calibrating delay loop... 166.29 BogoMIPS
Feb 20 21:31:59 stucko kernel: Memory: 22012k/24576k available (1069k kernel code, 
2176k reserved, 422k data, 56k init, 0k highmem)
Feb 20 21:31:59 stucko kernel: Dentry-cache hash table entries: 4096 (order: 3, 32768 
bytes)
Feb 20 21:31:59 stucko kernel: Buffer-cache hash 

Very high bandwith packet based interface and performance problems

[Nye Liu]

I am working on a very high speed packet based interface but we are having
severe problems related to bandwidth vs cpu horsepower. enclosed is a part
of a summary. PLEASE cc responses directly to [EMAIL PROTECTED]

Thanks!!!

-- 
"Who would be stupid enough to quote a fictitious character?"
-- Don Quixote



Due to the limited horsepower of our ppc740 (as it has no cache) our
proprietary, 2 Gbit packet based interface is capable of overwhelming
the software throughput capabilities of the kernel. This congestion is
causing severe network performance issues in both UDP and TCP.  In UDP,
if the frame rate exceeds approximately 300Mbit (1500 byte packets),
the kernel usage goes to 100%, leaving no cpu power for user space
applications to even recieve frames, causing severe queuing packet
loss. In the TCP case, there seem to be constant acks from the kernel,
but most data never seems to make it to user space.

Inspecting the /proc/net/dev and /proc/net/snmp counters reveal no errors.

As a control, the private 10/100 ethernet interface is capable of
sustaining 100Mbits of unidirectional UDP and TCP trafic with no problems.

Similary, if a traffic policer is used to limit the load of the
proprietary high speed interface to approx. 200Mbits, there is no packet
loss in UDP. Since we lack a shaper, we can't test TCP reliably, as
the policer drops packets instead of shaping output. We can test this
qualitatively by artificially preventing the TCP source from sending
too quickly.. we can do this by loading the source cpu heavily. however,
results from this are mixed. We seem to be able to attain only approx.
50-60Mbits by this method.

Questions:

There are two options in the 2.0 kernel. One is "Cpu is too slow for
network" or something similar. A second (driver specific option) is a
flow control mechanism.

In 2.4, the first seems to be missing. The second is only available for
a few drivers (e.g. tulip)

What do these options do?

In 2.4, what is the recommended way of keeping a high speed interface
from overwhelming the kernel network queue (e.g. Gig ethernet)?

Does this affect user space programs (e.g. ftpd, apache, etc)?

If so, how?

What are the mechanisms by which the Linux kernel drops frames?

Which mechanisms are accompanied by statistics, and what are they.

Which mechanisms are NOT accompanied by statistics.

Why is the kernel acking a blocked TCP stream? (i.e. when a user space
TCP program is unable to read from a socket because it is not being
schedulued due to kernel cpu load)

(todd... please comment, as this is a prelim document for the problem
description)

-Nye

-- 
"Who would be stupid enough to quote a fictitious character?"
-- Don Quixote

QUOTA broken?

[Vibol Hou]

Can someone confirm that the 2.4.1-ac15+ quota system is NOT broken?  I am
having problems running quota-2.00 on 2.4.1-ac15 although quota worked fine
in 2.4.0.

--
Vibol Hou

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

[Jens Axboe]

On Tue, Feb 20 2001, Adam Schrotenboer wrote:
> Jens,
> 
> Please excuse this possibly stupid q. I don't know as much about kernel 
> hacking as I would like to.
> 
> I noticed that you are rewriting the loop block device to be a block 
> remapper (yes, I had noticed this before, the q just never occurred to 
> me before); does this imply that the native block size of the loop file 
> fs must be the same size as the underlying fs? exemplia gratia, ext2 fs 
> w/ block size 1024, iso image block size 2048; or ext2 block size 1024, 
> reiserfs image block size 512 (I'm assuming this is possible, but don't 
> know for sure. of course on reiserfs the likely best size is 4096 to 
> match page size, since tails are packed anyway); or perhaps a more 
> useful/common example than the previous: iso block size 2048, ext2 block 
> size 1024 (most common block size, right??).

A remapper was the original idea, and the loop-remap-XX patches did
that. But it gave me so many head aches exactly due to for example
block size differences, and also the stacking then becomes even
more problematic.

So no, the current loop patches do not use simple buffer_head
remapping.

-- 
Jens Axboe

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

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Andrea Arcangeli]

On Tue, Feb 20, 2001 at 05:31:25PM -0700, Andreas Dilger wrote:
> The reason why the IOP was changed was because the VG_CREATE ioctl now
> depends on the vg_number in the supplied vg_t to determine which VG minor
> number to use.  The old interface used the minor number of the opened
> device inode, but for devfs the device inodes don't exist until the VG
> is created...  If you run an older kernel with new tools, you can only
> use the first VG.

Ah, I was reading the patch incidentally against 2.2 patch where devfs support
is not included, so I wasn't thinking the devfs way ;). Thanks for the
explanation.

I assume it's not possible to mknod on top of devfs.  So then we could use a
temporary device in /var/tmp or whatever for that.  However those workarounds
tends to be ugly.

Probably the best way to preserve the IOP that I recommend for beta6 is to add
a new ioctl to the VG chardevice.  Rename VG_CREATE to VG_CREATE_OLD.
VG_CREATE_OLD is a wrapper that calculates the minor number from the inode and
then fallbacks into VG_CREATE, and the new VG_CREATE is the one that gets
the minor of the vg from userspace.

Either ways we don't break backwards compatibilty across 0.9* cycle.

If there would been a strong reason and it would be a mess to provide backwards
compatibilty I would of course agree to raise at IOP 11, but just to avoid a
few lines of code for a wrapper or a temporary mknod on /tmp for a devfs-only
fix, I think it worth to preserve IOP 10.

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: patch: loop-5

[Adam Schrotenboer]

Jens,

Please excuse this possibly stupid q. I don't know as much about kernel 
hacking as I would like to.

I noticed that you are rewriting the loop block device to be a block 
remapper (yes, I had noticed this before, the q just never occurred to 
me before); does this imply that the native block size of the loop file 
fs must be the same size as the underlying fs? exemplia gratia, ext2 fs 
w/ block size 1024, iso image block size 2048; or ext2 block size 1024, 
reiserfs image block size 512 (I'm assuming this is possible, but don't 
know for sure. of course on reiserfs the likely best size is 4096 to 
match page size, since tails are packed anyway); or perhaps a more 
useful/common example than the previous: iso block size 2048, ext2 block 
size 1024 (most common block size, right??).

I admit that I gave one, maybe two more examples than necessary. the 
idea of the first two was to cover both possibilities, i.e. loop larger 
than base, and loop smaller than base. The third was merely to ward off 
the possiblity that the 3rd was and impossible configuration, and to 
reduce flames from various people who consider something this 
"elementary" to be "obvious", either in utility or specification.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [rfc] Near-constant time directory index for Ext2

[Bernd Eckenfels]

In article <01022100361408.18944@gimli> you wrote:
> But actually, rm is not problem, it's open and create.  To do a
> create you have to make sure the file doesn't already exist, and
> without an index you have to scan on average half the directory file. 

Unless you use a File System which is better for that, like Reiser-FS. Of
course a even better solution is to distribute those files in hashed subdirs.

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [rfc] Near-constant time directory index for Ext2

[Andreas Dilger]

Linus writes:
> On Tue, 20 Feb 2001, Daniel Phillips wrote:
> > You mean full_name_hash?  I will un-static it and try it.  I should have
> > some statistics tomorrow.
> 
> I was more thinking about just using "dentry->d_name->hash" directly, and
> not worrying about how that hash was computed. Yes, for ext2 it will have
> the same value as "full_name_hash" - the difference really being that
> d_hash has already been precomputed for you anyway.

I _thought_ that's what you meant, but then I was also thinking that the
dentry hash was on the full path name and not just the filename?  This
wouldn't be any good for use in the directory index, in case the directory
is renamed.  If this is _not_ the case, then it is a definite candidate.

> Note that dentry->d_name->hash is really quick (no extra computation), but
> I'm not claiming that it has anything like a CRC quality. And it's
> probably a bad idea to use it, because in theory at least the VFS layer
> might decide to switch the hash function around.

I was thinking about this as well.  Since the setup Daniel has allows us
to store a hash version, we could run the hash function on a fixed string
at SB init time to give us a hash "version" number.  If the hash function
changes we will get a new hash "version".  We could inline each new dentry
hash function into the ext2 code (so we can unpack the directories), or
as a cop-out if any directory has a hash version not equal to the current
one we re-hash all the entries in the directory.

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

2.2.x: ReiserFS + NFSv3

[Matthias Andree]

The current state of ReiserFS + kNFSd for NFS v3 is best described as
"broken", files get unaccessible when accessed across NFS (server logs
ReiserFS warning vs-13048 and cannot itself locally access those files
until the inode cache is flushed), at least for 2.2.18. I have seen that
some people (Neil Brown and Alan Cox among them, apologies to the ones
I missed, it's not meant as offense) have started to discuss the cause
of the problem, which I appreciate.

I cannot currently try 2.4.x on the production machines for various
reasons, one of these being called "vmware 1.x".

As to ReiserFS 3.5 + kNFSd, there have been some patches published
recently in various places to get those two FSs into the same kernel,
like knfsd patches for ReiserFS (originating from Andy Kleen), Chris
Mason's NFS patches, but the list of dependencies for those patches are
so long one and the patches so diverse that it's hardly possible to get
2.2.18 (e.  g.) up and running with ReiserFS AND knfsd v3. 

What I'm after is a single patch for ReiserFS and possibly another patch
to get ReiserFS play nicely with NFSv3, and if these patches require the
VM-global-7 patches by Andrea, that's still fine since these don't
interfere with ReiserFS AFAICS. 

Getting ext3fs and reiserfs into the same kernel is a piece of cake
compared to what seems to be required to get reiserfs and nfsv3 up and
running.

The current 2.2.18 + NFSv3 + ReiserFS is a horrible mess, the track of
recommendations/requirements looks like:

2.2.18 
+ ah's IDE patches (to get AMD Irongate IDE working fast)
+ aa's VM patches (to get the severe bugs out)
+ ReiserFS
+ knfsd-patches for ReiserFS
+ 2.2.19pre7aa1 NFS patches
+ Chris Mason's NFS patches

Heck, when's 2.2.19 released so we have a stable kernel with new VM
that's a base for other file systems to build upon?

Can the NFS and ReiserFS developers, possibly including ext2, xfs, jfs,
ext3 maintainers sit together, find out what the current problem with
knfsd v3 is and go fix it, regardless if it requires changes to the
architectures? If it's broken, it needs fixing, regardless which
version.

Plus, can the 2.2 release cycle please be shortened? I don't see that
2.2.19pre is being frozen, but I see lots of bug fixes going in, and I
cannot see when 2.2.19 is going to be out. You can't expect to get every
possible bug fix in for the next release, there's always one more bug to
fix.


This is a lot of rant and request, which I hope does not contain any
personal offense; since every single person involved and mentioned is
very helpful, but the big picture simply doesn't quite work out :-(



Is there anything which should keep me from switching from ReiserFS
3.5.29 to the latest 0.0.5 series ext3fs? Does knfsd with NFSv3 work out
when served from ext3fs?

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

Re: kernel_thread() & thread starting

[Kenn Humborg]

On Sun, Feb 18, 2001 at 10:53:16PM +, Russell King wrote:
> Kenn Humborg writes:
> > When starting bdflush and kupdated, bdflush_init() uses a semaphore to
> > make sure that the threads have run before continuing.  Shouldn't
> > start_context_thread() do something similar?
> 
> I think this would be a good idea.  Here is a patch to try.  Please report
> back if it works so that it can be forwarded to Linus.  Thanks.

Works perfectly for me.  

I'll leave it up to you guys to decide what's the right way to deal with 
this and pass a patch to Linus/Alan.  Meanwhile, I'll keep Russell's 
patch below in our CVS tree.

Thanks,
Kenn

> --- orig/kernel/context.c Tue Jan 30 13:31:11 2001
> +++ linux/kernel/context.cSun Feb 18 22:51:56 2001
> @@ -63,7 +63,7 @@
>   return ret;
>  }
>  
> -static int context_thread(void *dummy)
> +static int context_thread(void *sem)
>  {
>   struct task_struct *curtask = current;
>   DECLARE_WAITQUEUE(wait, curtask);
> @@ -79,6 +79,8 @@
>   recalc_sigpending(curtask);
>   spin_unlock_irq(>sigmask_lock);
>  
> + up((struct semaphore *)sem);
> +
>   /* Install a handler so SIGCLD is delivered */
>   sa.sa.sa_handler = SIG_IGN;
>   sa.sa.sa_flags = 0;
> @@ -148,7 +150,9 @@
>   
>  int start_context_thread(void)
>  {
> - kernel_thread(context_thread, NULL, CLONE_FS | CLONE_FILES);
> + DECLARE_MUTEX_LOCKED(sem);
> + kernel_thread(context_thread, , CLONE_FS | CLONE_FILES);
> + down();
>   return 0;
>  }
>  
> 
> 
> --
> Russell King ([EMAIL PROTECTED])The developer of ARM Linux
>  http://www.arm.linux.org.uk/personal/aboutme.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: reiserfs probs on 2.2.17

[Chris Mason]

On Wednesday, February 21, 2001 01:44:10 AM +0100 Arnaud Installe
<[EMAIL PROTECTED]> wrote:

> Hello,
> 
> I've had a problem with a reiserfs partition on a 2.2.17 kernel the other
> day.  Everything I did on it just waited forever.  (Since shutdown tries
> to umount all partitions the only way to reboot the machine was to kill
> the watchdog process.)
> 
> The problem persisted after the reboot, so the partition must've contained
> errors.  Running `reiserfsck --replay-by-journal' fixed the problem.  (I
> think: before that I also ran `reiserfsck --check 'on it.)
> 


Which reiserfs version are you running?  From the ps output, it looks like
you've got a bunch of processes waiting on the log, and one process waiting
on a semaphore, so everyone is probably waiting for that process to close
the transaction.  These kinds of deadlocks should have been long since
fixed, so there is probably a larger problem.

Running reiserfsck --replay-journal will replay the journal.  This happens
on every mount, so I'm really not sure how it could have fixed things ;-)
The --check option is readonly, and if there was a metadata problem it
probably would have reported it.

-chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Better BUG() macro - take 2

[J . A . Magallon]

On 02.20 Paul Gortmaker wrote:
>  
> +#ifdef CONFIG_DEBUG_ERRORS
> +const char *kernel_bug = "kernel BUG at %s: line %d!\n";
> +#endif
> 
..
>  EXPORT_SYMBOL(daemonize);
> +EXPORT_SYMBOL(kernel_bug);
>  

Should also be #ifdef'd.
 
-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.1-ac19 #1 SMP Mon Feb 19 21:52:31 CET 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/

reiserfs probs on 2.2.17

[Arnaud Installe]

Resending it, as it doesn't seem it got through the previous times.

- Forwarded message from Arnaud Installe <[EMAIL PROTECTED]> -

To: [EMAIL PROTECTED]
Subject: reiserfs probs on 2.2.17
Date: Tue, 20 Feb 2001 00:42:29 +0100

Hello,

I've had a problem with a reiserfs partition on a 2.2.17 kernel the other
day.  Everything I did on it just waited forever.  (Since shutdown tries
to umount all partitions the only way to reboot the machine was to kill
the watchdog process.)

The problem persisted after the reboot, so the partition must've contained
errors.  Running `reiserfsck --replay-by-journal' fixed the problem.  (I
think: before that I also ran `reiserfsck --check 'on it.)

This is the output I got from `ps':

 EIP COMMAND   PENDING  WCHAN WCHAN
400c415e init [4]  1324d9 do_select
 [kflushd] 12b493 bdflush
 [kupdate] 12b508 kupdate
 [kpiod]   121382 kpiod
 [kswapd]  12496a kswapd
 [kreiserfsd]  16107c reiserfs_journal_commit_thread
 [kreiserfsd]  16107c reiserfs_journal_commit_thread
 [kreiserfsd]  16107c reiserfs_journal_commit_thread
 [kreiserfsd]  16107c reiserfs_journal_commit_thread
 [kreiserfsd]  16107c reiserfs_journal_commit_thread
 [kreiserfsd]  16107c reiserfs_journal_commit_thread
 [kreiserfsd]  16107c reiserfs_journal_commit_thread
 [kreiserfsd]  16107c reiserfs_journal_commit_thread
 [kreiserfsd]  16107c reiserfs_journal_commit_thread
400da15e portmap   1324d9 do_select
400a8c41 /usr/sbin/atd 1146d3 nanosleep
400a8c41 crond 1146d3 nanosleep
401b615e /usr/sbin/sshd    1324d9 do_select
400c415e xntpd -A  1324d9 do_select
400c615e rpc.rstatd    1324d9 do_select
400bdab4 /sbin/mingetty t  19e3c3 read_chan
400c415e /sbin/syslogd -n  1324d9 do_select
400e715e Xvnc :0 -desktop  1324d9 do_select
401f315e twm   1324d9 do_select
400eda04 /usr/jdk118/bin/ 0300 161e04 check_journal_end
40d7a310 /usr/sbin/snmpd   1324d9 do_select
400c42f7 shutdown -r 0 w  00010002 161e04 check_journal_end
 [shutdown http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: netdev issues (3c905B)

[Vibol Hou]

Hi Martin,

Here's /proc/interrupts:

   CPU0   CPU1
  0:27480432754927IO-APIC-edge  timer
  1:  2  0IO-APIC-edge  keyboard
  2:  0  0  XT-PIC  cascade
  4:   2737   2892IO-APIC-edge  serial
 17:95736129568840   IO-APIC-level  eth0
 18: 483436 482421   IO-APIC-level  aic7xxx
NMI:55055055505399
LOC:55026095502508
ERR:  0

-Vibol

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Martin Moerman
Sent: Tuesday, February 20, 2001 4:22 PM
To: Vibol Hou
Cc: Linux-Kernel
Subject: Re: netdev issues (3c905B)




Vibol,

I see that the card is on IRQ 17 ???

can you send us /proc/interrupts

/Martin


On Tue, 20 Feb 2001, Vibol Hou wrote:

> Hi,
>
> I have some problems on a heavily loaded web server.  The first is that
the
> kernel is spitting out a bunch of "NETDEV WATCHDOG: eth0: transmit timed
> out" errors.  I do not recall this happening in 2.4.0 under the same
> conditions.
>
> Another problem that I seem to have, of which I have had reports from
> clients, is that the server has problems talking to clients using modems
> This didn't occur before with the 2.2 series kernel (all other things held
> constant).  It seems each time a client tries to load up any site on the
> server, the connection will just die (or stall).  This does not apply to
> high-bandwidth connections (DSL and up) since everything seems fine on DSL
> and faster, but I tried connecting using my dial-up account with
Earthlink,
> and the reports seem to be true.  Can those of you on a 56k modem try
> connecting to http://khmerconnection.com and see if the page loads?
Apache
> isn't the only service affected.  It seems *any* TCP communication runs
like
> a turtle (even SSH.  takes minutes to login, then minutes to echo each
> letter.  doesn't do this on a DSL connection from the same computer).
>
> The card that is exhibiting this problem is a 3c905B (lspci below):
>
> 00:08.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
> (rev 30)
> Subsystem: 3Com Corporation: Unknown device 9055
> Flags: bus master, medium devsel, latency 80, IRQ 17
> I/O ports at e400 [size=128]
> Memory at e8001000 (32-bit, non-prefetchable) [size=128]
> Expansion ROM at e400 [disabled] [size=128K]
> Capabilities: [dc] Power Management version 1
>
> dmesg shows hordes of these at high peak usage (300KBps+):
>
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: transmit timed out, tx_status 00 status e601.
>   diagnostics: net 0cd8 media 8880 dma 003a.
> eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
>   Flags; bus-master 1, full 0; dirty 9256291(3) current 9256291(3).
>   Transmit list  vs. f7de5230.
>   0: @f7de5200  length 8042 status 00010042
>   1: @f7de5210  length 804a status 8001004a
>   2: @f7de5220  length 8036 status 80010036
>   3: @f7de5230  length 8036 status 00010036
>   4: @f7de5240  length 8042 status 00010042
>   5: @f7de5250  length 8036 status 00010036
>   6: @f7de5260  length 85ea status 000105ea
>   7: @f7de5270  length 85ea status 000105ea
>   8: @f7de5280  length 803a status 0001003a
>   9: @f7de5290  length 803e status 0001003e
>   10: @f7de52a0  length 803a status 0001003a
>   11: @f7de52b0  length 803e status 0001003e
>   12: @f7de52c0  length 803e status 0001003e
>   13: @f7de52d0  length 804a status 0001004a
>   14: @f7de52e0  length 804a status 0001004a
>   15: @f7de52f0  length 803e status 0001003e
> eth0: Resetting the Tx ring pointer.
>
> Any ideas?
>
> Thanks,
> --
> Vibol Hou
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] 2.4.1-ac UP-APIC updates

[Mikael Pettersson]

On Tue, 20 Feb 2001 16:00:53 -0500 (EST), Ingo Molnar wrote:

>my major gripe right now is that we still have bug reports that say that
>systems hang when using nmi_watchdog=1 and work if nmi_watchdog=0.
>Changing the NMI watchdog to be 1 Hz will make these bugreports "Linux
>hangs once a week" instead of a "Linux hangs after 1-2 hours", which is
>clearly hiding things and making debugging harder.

All reports I've seen have been for SMP kernels on MP machines using
the IO-APIC to drive the watchdog. Are you saying there are also cases
where UP boxes fail with nmi_watchdog non-zero? (My 1Hz change only
affected the local APIC-driven watchdog which MP boxes normally don't use.)

>(and driving kernel-profiling from the NMI interrupt is a short-term
>patch, so there is just no point in going to 1 Hz right now just to go
>back to 100 Hz a few days later.)

Another "constructive" use of the perfctrs. Ok, this I can see wants
a higher rate.

How far in the future is this? I'm concerned that the conflicting
uses of the perfctrs (watchdog, kernel profiling, my perfctr driver
for user-space performance measurements) is going to require some
low-level request/release API.

>the rest of the changes are excellent - it's only the 100 Hz NMI issue i
>have a problem with.

Ok. 

Alan beat me to it for -ac20, so I'm not including a new patch now
with the 1Hz bit backed out. Ingo, I guess this means the kernel
profiling patch will have to "fix" the 1Hz thing by itself.

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

[VERY OT]...but funny - No flames :)

[Shawn Starr]

ALL YOUR LINUX ARE BELONG TO US ;-)

*snicker*

Shawn.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [rfc] Near-constant time directory index for Ext2

[Alan Cox]

> probably a bad idea to use it, because in theory at least the VFS layer
> might decide to switch the hash function around. I'm more interested in
> hearing whether it's a good hash, and maybe we could improve the VFS hash
> enough that there's no reason to use anything else..

Reiserfs seems to have done a lot of work on this and be using tea, which is
also nice as tea is non trivial to abuse as a user to create pessimal file
searches intentionally

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [rfc] Near-constant time directory index for Ext2

[Linus Torvalds]

On Tue, 20 Feb 2001, Daniel Phillips wrote:
> 
> You mean full_name_hash?  I will un-static it and try it.  I should have
> some statistics tomorrow.  I have a couple of simple metrics for
> measuring the effectiveness of the hash function: the uniformity of
> the hash space splitting (which in turn affects the average fullness
> of directory leaves) and speed.

I was more thinking about just using "dentry->d_name->hash" directly, and
not worrying about how that hash was computed. Yes, for ext2 it will have
the same value as "full_name_hash" - the difference really being that
d_hash has already been precomputed for you anyway.

> Let the hash races begin.

Note that dentry->d_name->hash is really quick (no extra computation), but
I'm not claiming that it has anything like a CRC quality. And it's
probably a bad idea to use it, because in theory at least the VFS layer
might decide to switch the hash function around. I'm more interested in
hearing whether it's a good hash, and maybe we could improve the VFS hash
enough that there's no reason to use anything else..

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: netdev issues (3c905B)

[Martin Moerman]

Vibol,

I see that the card is on IRQ 17 ???

can you send us /proc/interrupts

/Martin


On Tue, 20 Feb 2001, Vibol Hou wrote:

> Hi,
> 
> I have some problems on a heavily loaded web server.  The first is that the
> kernel is spitting out a bunch of "NETDEV WATCHDOG: eth0: transmit timed
> out" errors.  I do not recall this happening in 2.4.0 under the same
> conditions.
> 
> Another problem that I seem to have, of which I have had reports from
> clients, is that the server has problems talking to clients using modems
> This didn't occur before with the 2.2 series kernel (all other things held
> constant).  It seems each time a client tries to load up any site on the
> server, the connection will just die (or stall).  This does not apply to
> high-bandwidth connections (DSL and up) since everything seems fine on DSL
> and faster, but I tried connecting using my dial-up account with Earthlink,
> and the reports seem to be true.  Can those of you on a 56k modem try
> connecting to http://khmerconnection.com and see if the page loads?  Apache
> isn't the only service affected.  It seems *any* TCP communication runs like
> a turtle (even SSH.  takes minutes to login, then minutes to echo each
> letter.  doesn't do this on a DSL connection from the same computer).
> 
> The card that is exhibiting this problem is a 3c905B (lspci below):
> 
> 00:08.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
> (rev 30)
> Subsystem: 3Com Corporation: Unknown device 9055
> Flags: bus master, medium devsel, latency 80, IRQ 17
> I/O ports at e400 [size=128]
> Memory at e8001000 (32-bit, non-prefetchable) [size=128]
> Expansion ROM at e400 [disabled] [size=128K]
> Capabilities: [dc] Power Management version 1
> 
> dmesg shows hordes of these at high peak usage (300KBps+):
> 
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: transmit timed out, tx_status 00 status e601.
>   diagnostics: net 0cd8 media 8880 dma 003a.
> eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
>   Flags; bus-master 1, full 0; dirty 9256291(3) current 9256291(3).
>   Transmit list  vs. f7de5230.
>   0: @f7de5200  length 8042 status 00010042
>   1: @f7de5210  length 804a status 8001004a
>   2: @f7de5220  length 8036 status 80010036
>   3: @f7de5230  length 8036 status 00010036
>   4: @f7de5240  length 8042 status 00010042
>   5: @f7de5250  length 8036 status 00010036
>   6: @f7de5260  length 85ea status 000105ea
>   7: @f7de5270  length 85ea status 000105ea
>   8: @f7de5280  length 803a status 0001003a
>   9: @f7de5290  length 803e status 0001003e
>   10: @f7de52a0  length 803a status 0001003a
>   11: @f7de52b0  length 803e status 0001003e
>   12: @f7de52c0  length 803e status 0001003e
>   13: @f7de52d0  length 804a status 0001004a
>   14: @f7de52e0  length 804a status 0001004a
>   15: @f7de52f0  length 803e status 0001003e
> eth0: Resetting the Tx ring pointer.
> 
> Any ideas?
> 
> Thanks,
> --
> Vibol Hou
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Andreas Dilger]

Andrea writes:
> On Tue, Feb 20, 2001 at 10:49:07PM +, Heinz Mauelshagen wrote:
> > A change in the i/o protocoll version *forces* you to update
> > the driver as well.
> 
> I didn't had much time to look into beta5 yet but I can't see why you changed
> the protocol to 11. There's no breakage between beta4 and beta5 in the
> datastructures shared with userspace.  I don't like gratuitous API breakage.

The reason why the IOP was changed was because the VG_CREATE ioctl now
depends on the vg_number in the supplied vg_t to determine which VG minor
number to use.  The old interface used the minor number of the opened
device inode, but for devfs the device inodes don't exist until the VG
is created...  If you run an older kernel with new tools, you can only
use the first VG.

I suggested reverting this change for the current release, and only fixing
the LVM devfs code (which is probably still broken in other ways).  Heinz
decided to update the IOP instead.  Note that with the new library build,
it is possible to have multiple IOP tools installed at the same time, and
the correct ones are chosen at runtime based on the kernel IOP.

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

Re: Is this the ultimate stack-smash fix?

[Andreas Bombe]

On Tue, Feb 20, 2001 at 10:09:55AM +0100, Xavier Bestel wrote:
> Le 20 Feb 2001 02:10:12 +0100, Andreas Bombe a écrit :
> > On Sat, Feb 17, 2001 at 09:53:48PM -0700, Eric W. Biederman wrote:
> > > Peter Samuelson <[EMAIL PROTECTED]> writes:
> > > > It also sounds like you will be
> > > > breaking the extremely useful C postulate that, at the ABI level at
> > > > least, arrays and pointers are equivalent.  I can't see *how* you plan
> > > > to work around that one.
> > > 
> > > Huh?  Pointers and arrays are clearly different at the ABI level.
> > > 
> > > A pointer is a word that contains an address of something.
> > > An array is an array.
> > 
> > An array is a word that contains the address of the first element.
> 
> 
> No. Exercise 3: compile and run this:
> file a.c:
> char array[] = "I'm really an array";
> 
> file b.c:
> extern char* array;
>
> main() { printf("array = %s\n", array); }
> 
> ... and watch it biting the dust !

Deliberately linking to the wrong symbol is not a point.  Might as well
replace file a.c with "int array = 0;".  That'll also bite the dust.  So?

> in short: an array is NOT a pointer.

In this context we were talking *function calls*, not confusing the
linker.  And whether you say "char array[];" or "char *const array;",
array is a pointer.  Even more so at the ABI = function call interface.

Another try:  Assume that
#include "secret.h"
int main() { printf("array = %s\n", array); return 0; }
is correct code.

Is the variable array a pointer to a char or an array of chars?

Oh well, who cares.

-- 
 Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.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/

Linux 2.4.1ac20

[Alan Cox]

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

2.4.1-ac20
o   Update fusion drivers   (Steve Ralston)
o   Further VM page launder balancing   (Rik van Riel)
o   Hopefully fix ext2 block size checking  (Andries Brouwer)
o   Update the i810 random number generator (Jeff Garzik)
o   Hopefully fix the bonding crash on down/reboot  (Dave Miller)
o   Tulip update (add accton comets, clean up pm)   (Jeff Garzik)
o   Merge wavelan_cs, pcnet_cs and fmvj18x_cs   (Jeff Garzik)
changes from Dave Hinds tree
o   Make awe32 behave in 2.4 like 2.2 if given an   (Bill Nottingham)
io
o   Fix alpha build problems in stallion, c101 (Andrzej Krzysztofowicz)
synclink and wavfront drivers
o   Add isa_check_signature and missing ioctl ids  (Andrzej Krzysztofowicz)
for hayesesp
o   Fix math emulation bug  (Martin Schwidefsky)
o   Disable APIC during APM to avoid suspend/resume (Mikael Pettersson)
problems.
o   SMP kernel on UP hardware APIC fixes(Maciej Rozycki)
o   Code cleanups in nmi, reduce NMI rate to 1Hz(Mikael Pettersson)

2.4.1-ac19
o   Fix second module/exception table race  (me)
| I hope ;)
o   Additional CPIA usb ident   (Adam J Richter)
o   Add SA1100 udc and also stall recovery to   (Oleg Drokin)
usbnet
o   Limit smbfs to 2Gig/file(Urban Widmark)
o   Config/doc update for the eicon driver  (Armin Schindler)
o   Update PMS driver to new request_region (Andrey Panin)
o   sys_semop bug check is overcareful  (Hugh Dickins)
o   Fix ipc off by one on checks in ipc (Hugh Dickins)
o   Allow exceptions during module init (Philipp Rumpf)
o   Driver namespace cleanup(Jeff Garzik)
o   Network driver cleanups (Jeff Garzik, 
o   PPC irq updates (Paul Mackerras)
o   SMP fixes for PPC boxes (Paul Mackerras)
o   Fix tmpfs block size reporting  (Christoph Rohland)
o   Update maintainers to add missing YAM maintainer(Jean-Paul Roubelat)
o   Add hooks for /proc/rtas(Paul Mackerras)
o   Fix wrong bogomip reporting on SMP ppc  (Paul Mackerras)
o   Remove unused dbcf inline function on PPC   (Paul Mackerras)
o   Update Cort Dougans email/urls  (Paul Mackerras)
o   Dont assume bit settings on pcnet/pci chips (Paul Mackerras)
o   Add mac ppc serial console hooks(Paul Mackerras)
o   Frame buffer driver updates for ppc (Paul Mackerras)
o   Fix devfs names for ppc serial  (Paul Mackerras)
o   Move some symbols out of net where they didnt   
belong, and into right export locations (Andrzej Krzysztofowicz)
o   Tidy and fix up syncppp drivers (Krzysztof Halasa)

2.4.1-ac18
o   Fix SO_SNDTIMEO bugs(Alexey Kuznetsov)
o   Fix tmpfs fsync (Lennert Buytenhek)
o   PPC now uses generic pci bus setup  (Paul Mackerras)
o   Remove PPC boot argument printing   (Paul Mackerras)
o   Jeff Tranter has moved  (Jeff Tranter)
o   ymf_pci driver cleanups (Pete Zaitcev)
o   Fix USB 2.0 compliance in hub.c (Brad Hards)
o   Fix usb hub device claim race   (Paul Mackerras)
o   Fix some bugs in mac_hid driver (Paul Mackerras)
o   Fix more typos  (Dag Wieers)
o   PPC compile warnings/symbol export fixes(Paul Mackerras)

2.4.1-ac17
o   Fix pegasus for bigendian   (Roman Weissgaerber)
o   Further smbfs fixes (Urban Widmark)
o   Update ISDN version tags(Kai Germaschewski)
o   Finish ISDN move to new style module_init   (Kai Germaschewski)
o   Small Eicon driver updates/fix license bug  (Armin Schindler)
o   Fix reiserfs tail packing problem   (Alexander Zarochentcev
 Chris Mason)
o   Export aci symbols from drivers/sound/aci.c (Alexandr Kanevskiy)
o   Merge Linus 2.4.2pre4
o   Starfire update (Ionu Badulescu)
o   Fix 3270 merge  (Richard Hitt)

2.4.1-ac16
o   Fix the exception table/unload race (me)
o   Further tulip fixup (Manfred Spraul)
o   Fix USB oops on traverse/delete race(Randy Dunlap)
o   Set max_sectors to 255 for 

netdev issues (3c905B)

[Vibol Hou]

Hi,

I have some problems on a heavily loaded web server.  The first is that the
kernel is spitting out a bunch of "NETDEV WATCHDOG: eth0: transmit timed
out" errors.  I do not recall this happening in 2.4.0 under the same
conditions.

Another problem that I seem to have, of which I have had reports from
clients, is that the server has problems talking to clients using modems
This didn't occur before with the 2.2 series kernel (all other things held
constant).  It seems each time a client tries to load up any site on the
server, the connection will just die (or stall).  This does not apply to
high-bandwidth connections (DSL and up) since everything seems fine on DSL
and faster, but I tried connecting using my dial-up account with Earthlink,
and the reports seem to be true.  Can those of you on a 56k modem try
connecting to http://khmerconnection.com and see if the page loads?  Apache
isn't the only service affected.  It seems *any* TCP communication runs like
a turtle (even SSH.  takes minutes to login, then minutes to echo each
letter.  doesn't do this on a DSL connection from the same computer).

The card that is exhibiting this problem is a 3c905B (lspci below):

00:08.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
(rev 30)
Subsystem: 3Com Corporation: Unknown device 9055
Flags: bus master, medium devsel, latency 80, IRQ 17
I/O ports at e400 [size=128]
Memory at e8001000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at e400 [disabled] [size=128K]
Capabilities: [dc] Power Management version 1

dmesg shows hordes of these at high peak usage (300KBps+):

NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, tx_status 00 status e601.
  diagnostics: net 0cd8 media 8880 dma 003a.
eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
  Flags; bus-master 1, full 0; dirty 9256291(3) current 9256291(3).
  Transmit list  vs. f7de5230.
  0: @f7de5200  length 8042 status 00010042
  1: @f7de5210  length 804a status 8001004a
  2: @f7de5220  length 8036 status 80010036
  3: @f7de5230  length 8036 status 00010036
  4: @f7de5240  length 8042 status 00010042
  5: @f7de5250  length 8036 status 00010036
  6: @f7de5260  length 85ea status 000105ea
  7: @f7de5270  length 85ea status 000105ea
  8: @f7de5280  length 803a status 0001003a
  9: @f7de5290  length 803e status 0001003e
  10: @f7de52a0  length 803a status 0001003a
  11: @f7de52b0  length 803e status 0001003e
  12: @f7de52c0  length 803e status 0001003e
  13: @f7de52d0  length 804a status 0001004a
  14: @f7de52e0  length 804a status 0001004a
  15: @f7de52f0  length 803e status 0001003e
eth0: Resetting the Tx ring pointer.

Any ideas?

Thanks,
--
Vibol Hou

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] VIA 4.2x driver for 2.2 kernels

[Shane Wegner]

On Tue, Feb 20, 2001 at 01:40:28PM +0100, Vojtech Pavlik wrote:
> Hi Andre!
> 
> You wanted my VIA driver for 2.2. Here is a patch that brings the very
> latest 4.2 driver to the 2.2 kernel. The patch is against the
> 2.2.19-pre13 kernel plus yours 1221 ide patch.
Hi,

This drivers breaks with my HP 8110 CD-R drive.  It's
sitting on primary slave of a Via 686B controler.  When I
try to do a hdparm -d1 -u1 -k1 /dev/hdb, the kernel locks
up hard.  Not even an oops.  Reverting to the old driver
works fine.

Uniform Multi-Platform E-IDE driver Revision: 6.30
ide: Assuming 33MHz system bus speed for PIO modes;
override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100%% native mode: will probe irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on
pci00:07.1
ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:pio,
hdb:pio
ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:pio,
hdd:pio
HPT370: IDE controller on PCI bus 00 dev 70
HPT370: chipset revision 3
HPT370: not 100%% native mode: will probe irqs later
ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:DMA,
hdf:pio
ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA,
hdh:pio
hdb: Hewlett-Packard CD-Writer Plus 8100, ATAPI CDROM drive
VP_IDE: Calibrating PCI clock ... 34.91 MHz
hde: Maxtor 92720U8, ATA DISK drive
hdg: Maxtor 96147U8, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide2 at 0xdc00-0xdc07,0xe002 on irq 10
ide3 at 0xe400-0xe407,0xe802 on irq 10
hde: Maxtor 92720U8, 25965MB w/2048kB Cache,
CHS=52755/16/63, UDMA(66)
hdg: Maxtor 96147U8, 58623MB w/2048kB Cache,
CHS=119108/16/63, UDMA(66)

The one thing I see here which looks odd is the PCI clock
timing at 34.91 MHZ.  The CPU is not overclocked so the PCI
clock should be 33MHZ but that's probably not related.

Regards,
Shane

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

Re: plugging in 2.4. Does it work?

[Jens Axboe]

On Wed, Feb 21 2001, Peter T. Breuer wrote:
> I recall that in 2.2 the make_request code tested that the
> buffers were contiguous in memory. From 2.2.18:
> 
> /* Can we add it to the end of this request? */
> if (back) {
> if (req->bhtail->b_data + req->bhtail->b_size
> != bh->b_data) {
> if (req->nr_segments < max_segments)
> req->nr_segments++;
> else break;
> }
> 
> It looks to me like it tested that the b_data char* pointers of the
> two requests being considered are exactly distant by the declared
> size of one.
> 
> Is that no longer the case? If so, that's my answer.

It will still cluster, the code above checks if the next bh is
contigious -- if it isn't, then check if we can grow another segment.
So you may be lucky that some buffer_heads in the chain are indeed
contiguous, that's what the segment count is for. This is exactly
the same in 2.4.

-- 
Jens Axboe

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

Re: Reiserfs, 3 Raid1 arrays, 2.4.1 machine locks up

[Roger Larsson]

On Tuesday 20 February 2001 22:21, Colonel wrote:
>From: "Tom Sightler" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Date: Tue, 20 Feb 2001 14:43:07 -0500
>Content-Type: text/plain;
>  charset="iso-8859-1"
>
>>> >I'm building a firewall on a P133 with 48 MB of memory using RH
>>> > 7.0, latest updates, etc. and kernel 2.4.1.
>>> >I've built a customized install of RH (~200MB)  which I untar
>>> > onto
>
>the
>
>>> >system after building my raid arrays, etc. via a Rescue CD which
>>> > I created using Timo's Rescue CD project.  The booting kernel
>>> > is 2.4.1-ac10, no networking, raid compiled in but raid1 as a
>>> > module
>>>
>>> Hmm, raid as a module was always a Bad Idea(tm) in the 2.2
>>> "alpha" raid (which was misnamed and is 2.4 raid).  I suggest you
>>> change that and update, as I had no problems with 2.4.2-pre2/3,
>>> nor have any been posted to the raid list.
>>
>>I just tried with 2.4.1-ac14, raid and raid1 compiled in and it did
>> the same thing.  I'm going to try to compile reiserfs in (if I have
>> enough
>
>room
>
>>to still fit the kernel on the floppy with it's initial ramdisk,
>> etc.)
>
>and
>
>>see what that does.
>
>There seem to be several reports of reiserfs falling over when memory is
>low.  It seems to be undetermined if this problem is actually reiserfs
> or MM related, but there are other threads on this list regarding similar
> issues. This would explain why the same disk would work on a different
> machine with more memory.  Any chance you could add memory to the box
> temporarily just to see if it helps, this may help prove if this is the
> problem or not.
>
>
> Well, I didn't happen to start the thread, but your comments may
> explain some "gee I wonder if it died" problems I just had with my
> 2.4.1-pre2+reiser test box.  It only has 16M, so it's always low
> memory (never been a real problem in the past however).  The test
> situation is easily repeatable for me [1].  It's a 486 wall mount, so
> it's easier to convert the fs than add memory, and it showed about
> 200k free at the time of the sluggishness.  Previous 2.4.1 testing
> with ext2 fs didn't show any sluggishness, but I also didn't happen to
> run the test above either.  When I come back to the office later, I'll
> convert the fs, repeat the test and pass on the results.
>
>
> [1]  Since I decided to try to catch up on kernels, I had just grabbed
> -ac18, cd to ~linux and run "rm -r *" via an ssh connection.  In a
> second connection, I tried a simple "dmesg" and waited over a minute
> for results (long enough to log in directly on the box and bring up
> top) followed by loading emacs for ftp transfers from kernel.org,
> which again 'went to sleep'.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

If these are freezes I had them too in 2.4.1, 2.4.2-pre1 fixed it for me.
Really I think it was the patch in handle_mm_fault setting TASK_RUNNING.

/RogerL

-- 
Home page:
  none currently
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: plugging in 2.4. Does it work?

[Peter T. Breuer]

"A month of sundays ago Jens Axboe wrote:"
> On Wed, Feb 21 2001, Peter T. Breuer wrote:
> > Hurrr ... are you saying that the buffers in the bh's in the request are
> > not contiguous?  My reading of the make_request code in 2.2 was that
> > they were!  Has that changed?  There is now a reference to an elevator
> > algorithm in the code, and I can't make out the effect by looking ... 
> > I have been copying the buffer in the request as though it were a single
> > contigous whole.  If that is not the case, then yes, bang would happen.
> 
> Nothing has changed in this regard at all between 2.2 and 2.4. The
> buffers are guaranteed to be sequentially sector-wise, but definitely
> not contigious in memory!

I recall that in 2.2 the make_request code tested that the
buffers were contiguous in memory. From 2.2.18:

/* Can we add it to the end of this request? */
if (back) {
if (req->bhtail->b_data + req->bhtail->b_size
!= bh->b_data) {
if (req->nr_segments < max_segments)
req->nr_segments++;
else break;
}

It looks to me like it tested that the b_data char* pointers of the
two requests being considered are exactly distant by the declared
size of one.

Is that no longer the case? If so, that's my answer.


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

Re: DNS goofups galore...

[James Antill]

"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] (James Antill) writes:
> 
> >"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> writes:
> 
> >> % telnet mail.bar.org smtp
> >> 220 mail.foo.org ESMTP ready
> >> 
> >> 
> >> This kills loop detection. Yes, it is done this way =%-) and it breaks
> >> if done wrong.
> 
> > This is humour, yeh ?
> 
> No.

 This was a comment on the "loop detection" claim.

[snip ... domain example]

> No. This is a misconfiguration. Yes, RFC821 is a bit rusty but as far
> as I know, nothing has superseded it yet. And Section 3.7 states
> clearly:
> 
>   Whenever domain names are used in SMTP only the official names are
>   used, the use of nicknames or aliases is not allowed.

 _In_ SMTP, that doesn't say anything about MX records to me and even
if it does it's very old and needs to change.

> And the 220 Message is defined as
> 
> 220 

 So... you should have the reverse for the ip address after the
220. Which most people do (but not all, mainly due to there not being
enough ips).

[snip CNAME lesson]

 The question was, why can't you use CNAMEs. You said 'because of loop
detection'. I said 'But that doesn't work anyway, because you can have
to names pointing at one machine without a CNAME record ... and that
needs to, and currently does, work'.

> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen   -- Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]

 Let me put it this way...

tanstaafl.de.   IN MX   50 mail.hometree.net.
tanstaafl.de.   IN MX   10 mail.intermeta.de.
intermeta.de.   IN MX   50 mail.hometree.net.
intermeta.de.   IN MX   10 mail.intermeta.de.

mail.hometree.net.  IN A194.231.17.49
mail.intermeta.de.  IN A212.34.181.3

49.17.231.194.in-addr.arpa.  IN PTR  limes.hometree.net.
3.181.34.212.in-addr.arpa.  IN PTR  babsi.intermeta.de.

-- 
# James Antill -- [EMAIL PROTECTED]
:0:
* ^From: .*james@and\.org
/dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [rfc] Near-constant time directory index for Ext2

[Daniel Phillips]

On Tue, 20 Feb 2001, Jeremy Jackson wrote:
> Mike Dresser wrote:
> 
> > the way i'm reading this, the problem is there's 65535 files in the directory
> > /where/postfix/lives.  rm * or what have you, is going to take forever and
> > ever, and bog the machine down while its doing it.  My understanding is you
> > could do the rm *, and instead of it reading the tree over and over for every
> > file that has to be deleted, it just jumps one or two blocks to the file that's
> > being deleted, instead of thousands of files to be scanned for each file
> > deleted.
> 
> I thought about it again, and the proformance problem with "rm *" is that
> the shell reads and sorts the directory, passes each file as a separate
> argument to rm, which then causes the kernel to lookup each file
> from a random directory block (random because of previous sort),
> modify that directory block, then read another... after a few seconds
> the modified blocks start to be written back to disk while new ones
> are looked up... disk seek contention.  and this becomes hard on the
> dir. block cache (wherever this is) since from source each dir entry
> is just over 256 bytes (?) 65535 files would require 16MB to
> cache dir entries.  Plus it has to read in all the inodes, modify,
> then write, taking up xxMB more.  You're probably swapping
> out,  with swap partition on same disk, the disk may explode.
> 
> If it were truly doing a linear scan, it might be faster.  Two
> successive mods to same dir block would be merged
> onto same write.
> 
> Perhaps rm -rf . would be faster?  Let rm do glob expansion,
> without the sort.  Care to recreate those 65535 files and try it?
> 
> or use ls with the nosort flag pipe through xargs then to rm...
> again loose sorting but don't delete directory or subdirs.

Indeed, rm -rf is faster.  It does a readdir to get all the directory
entries in internal order, then calls unlink to remove them, one at a
time.  This removes each entry from the front of the file, shortening
the time that has to be spent scanning forward in the file to find the
target entry.  Manfred Spraul observed that this could be speeded up
with by caching the file position, and sent me a patch to do that.  It
did speed things up - about 20%.

But actually, rm is not problem, it's open and create.  To do a
create you have to make sure the file doesn't already exist, and
without an index you have to scan on average half the directory file. 
Open requires a similar scan.  Here we are talking about using an index
to speed that up quadraticly when operating on N files.  That is the
real gravy.

-- 
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [LONG RANT] Re: Linux stifles innovation...

[Brian May]

> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:

Jeff> FWIW, -every single- Windows driver source code I've seen
Jeff> has been bloody awful.  Asking them to release that code
Jeff> would probably result in embarrassment.  Same reasoning why
Jeff> many companies won't release hardware specifications...  The
Jeff> internal docs are bad.  Really bad.

Speaking as a user, I would much prefer to use an open source driver
that is "bloody awful" rather then a closed source driver that still
might be "bloody awful", unless I am confident that the vendor will
support me if I encounter a bug. (IMHO "bloody awful" means "awfully
buggy").

In the past, I have had a case where my AGFA scanner stopped working,
as the software kept coming up with illegal operation errors.
Technical support were not the least bit interested in helping (no one
else has reported having the same problem), but instead blamed the
problem on my computer (try reinstalling it again, maybe this time it
will work?) Or: bring the scanner in, and if the same problem occurs
on our computer, we will fix it, otherwise we will have to charge you
for testing it.

At one stage I tricked the consultant into copying down the CPU
register information, but I got the strong impression that they
weren't interested in diagnosing the bug (they probably didn't have the
programmers anymore).

I ended up having to reinstall the entire MS-operating system on the
computer so it would work again. However, my feeling is that if I knew
what the problem was, it would have been easy to work around, eg. by
editing the appropriate entry in the system registry. I couldn't do
determine this myself though, without access to the source code.

(the scanner in question died about 1 month after warranty expired,
with very little use, so I went and purchased a HP scanner instead.)
-- 
Brian May <[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: problems with reiserfs + nfs using 2.4.2-pre4

[Chris Mason]

On Wednesday, February 21, 2001 09:54:19 AM +1100 Brian May
<[EMAIL PROTECTED]> wrote:

>> "dek" == dek ml <[EMAIL PROTECTED]> writes:
> 
> dek> OK so I think what I can take from this is: for kernel 2.4 in
> dek> the foreseeable future, reiserfs over NFS won't work without
> dek> a special patch.  And, filesystems other than ext2 in general
> 
> Does this apply to the user space NFS server? kernel space NFS server?
> Or both?

Both, but in different ways.  Andi Kleen has a set patches for using the
userspace NFS server with reiserfs:

ftp.suse.com/pub/people/ak/nfs

-chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: plugging in 2.4. Does it work?

[Jens Axboe]

On Wed, Feb 21 2001, Peter T. Breuer wrote:
> Actually I ignore the return value at present. I just wanted to know what
> happened. I haven't the faintest idea whether running end_that_request_last
> MEANS anything.

end_that_request_last most important job is up'ing any waiters on
the request (not usual), and put the now completed request back
on the queue free (or pending) list.

> > end_that_request_last, you are totally screwing the request
> > lists. Maybe this is what's going wrong?
> 
> At the time that end_request is run, it's on my own queue, not on the
> kernels queue. But I am eager for insight ... are you saying that
> after end_that_request_last has run, all bets are off, because the
> thing is completely vamooshed in every possible sense? I guess so.
> But fear not ... I've already taken it off my queue too. I really
> wanted the dequeue return value just in case maybe it would mean that
> I'd have to put it back on my queue and have another attempt at 
> acking it.

You cannot put it on different queues when you have run
end_that_request_last on it. For all you know, it may be a part
of a new I/O request as soon as you drop the io_request_lock.
That's why you have to dequeue prior to doing the final end_request, so
none of the lists the request may be on are destroyed.

> > > 1) setting read-ahead to 0 disables request agregation by some means of
> > > which I am not aware, and everything goes hunky dory.
> > 
> > Most likely what you are seeing happen is that we will do a
> > wait_on_buffer before we have a chance to merge this request on
> > the queue. Do writes, and you'll see lots of merging.
> 
> OK ... that sounds like something to avoid for a while! Wait_on_buffer,
> eh? If it makes things safe, I'm all for trying it myself!

When someones reads the data, that is. The only real reason (as you
discovered) that we get clustered reads is when a lot of read aheads
are queued. Or if the queue is already doing something else before
the request is started. This is not something you should do in your
driver, but it's worth while knowing about it so you can optimize
your driver for max performance.

> > There's no trick, and no required values. And there's really no special
> > trick to handling clustered requests. Either you are doing scatter
> > gather and setup your sg tables by going through the complete buffer
> > list on the request, or you are just transferring to rq->buffer the
> > amount specified by current_nr_sectors. That's it. Really.
> 
> Hurrr ... are you saying that the buffers in the bh's in the request are
> not contiguous?  My reading of the make_request code in 2.2 was that
> they were!  Has that changed?  There is now a reference to an elevator
> algorithm in the code, and I can't make out the effect by looking ... 
> I have been copying the buffer in the request as though it were a single
> contigous whole.  If that is not the case, then yes, bang would happen.

Nothing has changed in this regard at all between 2.2 and 2.4. The
buffers are guaranteed to be sequentially sector-wise, but definitely
not contigious in memory!

-- 
Jens Axboe

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

Re: plugging in 2.4. Does it work?

[Peter T. Breuer]

"A month of sundays ago Jens Axboe wrote:"
> Forgot to mention that the above doesn't make much sense at all. If
> there are no errors, you loop through ending all the buffers. Then

Yes, that's right, thanks. I know I do one more end_that_request_first
than is necessary, but it is harmless as there is a guard in the 
kernel code. At least, it's harmless until someone removes that guard.

It is like that because I added the while loop to the front of the code I
already had working when I decided to try plugging.

> you fall through and end the the first (non-existant) chunk? And
> end_that_request_first does not need to hold the io_request_lock,
> you can move that down to protect end_that_request_last.

OK, thanks!

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

Re: eepro100.c, kernel 2.4.1

[Andrey Savochkin]

On Tue, Feb 20, 2001 at 05:18:37PM +0900, Augustin Vidovic wrote:
> 00:0c.0 Ethernet controller: Intel Corporation 82557 (rev 08)
> 00:0d.0 Ethernet controller: Intel Corporation 82557 (rev 08)

It's i82559.
It can't have that original bug which is checked by those EEPROM bits and
workaround for which is implemented.
You probably have another one :-)

What are the symptomes of the lock-ups?
Does TX timeout happen?
Does the card recover and resume operations after that?

Best regards
Andrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: plugging in 2.4. Does it work?

[Peter T. Breuer]

"A month of sundays ago Jens Axboe wrote:"
> On Tue, Feb 20 2001, Peter T. Breuer wrote:
> > More like "how does one get it to work".
[snip muddy end_request code]

Probably. I decided that accuracy might get a better response, though
I did have to expand the macros to get to this. It's really:

   io_spin_lock
   while (end_that_request_first(req ...);
   // one more time for luck
   if (!end_that_request_first(req ...) 
  end_that_request_last(req);
   io_spin_unlock

> Firstly, I hope that the dequeue var does not return whether the 
> request should be dequeued or not. Because if you do it after

Actually I ignore the return value at present. I just wanted to know what
happened. I haven't the faintest idea whether running end_that_request_last
MEANS anything.

> end_that_request_last, you are totally screwing the request
> lists. Maybe this is what's going wrong?

At the time that end_request is run, it's on my own queue, not on the
kernels queue. But I am eager for insight ... are you saying that
after end_that_request_last has run, all bets are off, because the
thing is completely vamooshed in every possible sense? I guess so.
But fear not ... I've already taken it off my queue too. I really
wanted the dequeue return value just in case maybe it would mean that
I'd have to put it back on my queue and have another attempt at 
acking it.

> > I've discovered that
> > 
> > 1) setting read-ahead to 0 disables request agregation by some means of
> > which I am not aware, and everything goes hunky dory.
> 
> Most likely what you are seeing happen is that we will do a
> wait_on_buffer before we have a chance to merge this request on
> the queue. Do writes, and you'll see lots of merging.

OK ... that sounds like something to avoid for a while! Wait_on_buffer,
eh? If it makes things safe, I'm all for trying it myself!

> > 2) setting read-ahead to 4 or 8 seems to be safe. I see 4K requests
> > being formed and treated OK.
> > 
> > 3) disabling plugging stops request aggretaion and makes everything
> > safe.
> > 
> > Any clues? Is the trick just "powers of 2"? how is one supposed to
> > handle plugging? Where is the canonical example. I can't see any driver
> > that does it.
> 
> There's no trick, and no required values. And there's really no special
> trick to handling clustered requests. Either you are doing scatter
> gather and setup your sg tables by going through the complete buffer
> list on the request, or you are just transferring to rq->buffer the
> amount specified by current_nr_sectors. That's it. Really.

Hurrr ... are you saying that the buffers in the bh's in the request are
not contiguous?  My reading of the make_request code in 2.2 was that
they were!  Has that changed?  There is now a reference to an elevator
algorithm in the code, and I can't make out the effect by looking ... 
I have been copying the buffer in the request as though it were a single
contigous whole.  If that is not the case, then yes, bang would happen.

My aim in allowing request aggregation was to reduce the number
of ioctl calls I do from the userspace-half of the driver, since I 
have to do one ioctl per request in the protocol. A P3 maxes out the
cpu with the driver at just about 300MB/s (cache speed) but I wanted to
go faster on other architectures.

I must apparently also call blk_init_queue, but yes I do.

Thanks for the reply Jens, I appreciate it.

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

Re: [PATCH] make nfsroot accept server addresses from BOOTP root

[Tom Rini]

On Tue, Feb 20, 2001 at 11:02:10PM +, Russell King wrote:
> Ben LaHaise writes:
> > Yeah, that's the problem I was trying to work around, mostly because the
> > docs on dhcpd are sufficiently vague and obscure.  Personally, I don't
> > actually need tftp support, so I've just configured the system to now
> > point at the NFS server.  For anyone who cares, the last patch was wrong,
> > this one is right.
> 
> This is the dhcp entry for a host that I use to tftp a kernel from a 
> different machine to that running dhcpd:
> 
> host tasslehoff
> {
> hardware ethernet   00:10:57:00:03:EC;
> fixed-address   tasslehoff;
> next-server raistlin;
> filename"/usr/src/k/tasslehoff";
> }
> 
> The booting host is called "tasslehoff".  The tftp server host is called
> "raistlin", and the dhcp server is called "flint".
> 
> According to Tom, this should also cause Linux to nfs mount from the
> "next-server" address, and it is fair that this is not documented by
> the dhcp man pages since it appears to be a Linux Kernel quirk.

Well, assuming next-server gets translated into TFTP server by the
dhcp-doing-bootp bit, yes.  I'm using that right now to bootp on
one box and NFS off another.

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

swap still stuck

[J . A . Magallon]

Hi, everyone.

I seem to have again a problem that was talked about on the list, but I thought
it was yet corrected with some VM constants balancing.

I run 2.4.1-ac19-SMP. System works fine, but after a couple kernel untars
and an open netscape, starts to swap. Read buffers are still there. Do the
untars, launch netscape and instead of trashing buffers takes a bite on
swap.

Then you let netscape (what a mem hog example...) forgotten and start to do
some terminal work, config kernel, build, etc. Return to netscape and it is
much less responsible and disk starts to crawl to un-swap netscape. And
my 200 Mb of read buffers are still in main memory...

Is there any utility to say to kernel TROW AWAY YOUR READ BUFFERS ?. It looks
like it does not know how to do it.

I have finished some work session with just the last rxvt on screen, a mem like:

werewolf:~/soft/snd/alsa/alsa-utils# free
 total   used   free sharedbuffers cached
Mem:255524 244888  10636  0  94816  97052
-/+ buffers/cache:  53020 202504
Swap:   152576   9024 143552

but swap being 50Mb.

Why system does not try to drop read buffer pages before swapping ?


-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.1-ac19 #1 SMP Mon Feb 19 21:52:31 CET 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: [rfc] Near-constant time directory index for Ext2

[Jonathan Morton]

>Perhaps rm -rf . would be faster?  Let rm do glob expansion,
>without the sort.  Care to recreate those 65535 files and try it?

Perhaps, but I think that form is still fairly slow.  It takes an
"uncomfortable" amount of time to remove a complex directory structure
using, eg. "rm -rf /usr/src/linux-obsolete" or "rm -rf
downloads/XFree86-old-and-buggy".  I'm not sure, but I would guess it's not
as much quicker than removing each file individually as you might think.

If I had more time on my hands, I'd run some quick benchmarks on some of my
systems.

--
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED]  (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-BEGIN GEEK CODE BLOCK-
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ 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/

Detecting SMP

[Burton Windle]

Hello. Is there a way, when running a non-SMP kernel, to detect or
otherwise tell (software only; the machine is 2400 miles away) if the
system has SMP capibilties? Would /proc/cpuinfo show two CPUs if the
kernel is non-SMP?  Thanks!

(btw, the kernel in question is a stock RH6.2 kernel 2.2.14-5, and yes, I 
know I should update it anyways and that a SMP kernel will run on a UP
system)

-- 
Burton Windle   [EMAIL PROTECTED]
Linux: the "grim reaper of innocent orphaned children."
  from /usr/src/linux-2.4.0/init/main.c:655

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] make nfsroot accept server addresses from BOOTP root

[Russell King]

Ben LaHaise writes:
> Yeah, that's the problem I was trying to work around, mostly because the
> docs on dhcpd are sufficiently vague and obscure.  Personally, I don't
> actually need tftp support, so I've just configured the system to now
> point at the NFS server.  For anyone who cares, the last patch was wrong,
> this one is right.

This is the dhcp entry for a host that I use to tftp a kernel from a 
different machine to that running dhcpd:

host tasslehoff
{
hardware ethernet   00:10:57:00:03:EC;
fixed-address   tasslehoff;
next-server raistlin;
filename"/usr/src/k/tasslehoff";
}

The booting host is called "tasslehoff".  The tftp server host is called
"raistlin", and the dhcp server is called "flint".

According to Tom, this should also cause Linux to nfs mount from the
"next-server" address, and it is fair that this is not documented by
the dhcp man pages since it appears to be a Linux Kernel quirk.

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

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

Re: [PATCH] trylock for rw_semaphores: 2.4.1

[Brian J. Watson]

Ben LaHaise wrote:
> How about the following instead?  Warning: compiled, not tested.
> 
> -ben
> 
> +/* returns 1 if it successfully obtained the semaphore for write */
> +static inline int down_write_trylock(struct rw_semaphore *sem)
> +{
> +   int old = RW_LOCK_BIAS, new = 0;
> +   int res;
> +
> +   res = cmpxchg(>count.counter, old, new);
> +   return (res == RW_LOCK_BIAS);
> +}

Excellent! This simplifies things greatly. :)

The reason I returned 0 for success and 1 for failure is because that's the
semantic of down_trylock(). IMO they should be consistent.

The only other thing this routine needs is the WAITQUEUE_DEBUG code, at least to
keep the readers and writers fields accurate.


> +
> +/* returns 1 if it successfully obtained the semaphore for read */
> +static inline int down_read_trylock(struct rw_semaphore *sem)
> +{
> +   int ret = 1;
> +   asm volatile(
> +   LOCK "subl $1,%0
> +   js 2f
> +   1:
> +   .section .text.lock,\"ax\"
> +   2:" LOCK "inc %0
> +   subl %1,%1
> +   jmp 1b
> +   .previous"
> +   :"=m" (*(volatile int *)sem), "=r" (ret) : "1" (ret) : "memory");
> +   return ret;
> +}

There's a couple of races I can see here:

1) Task A holds the write lock and the count is at zero. Simultaneously, task B
calls down_read_trylock() and task C calls down_read(). Task B wins and
decrements the count to -1. Not long after, task C decrements it to -2, sees the
carry bit is clear, and calls down_read_failed(). Meanwhile, task B bumps the
count back up to -1 and returns. When task C calls __up_read(), it bumps the
count to zero, sees that the zero flag is set, calls __rwsem_wake(), who sets
the write_bias_granted field to 1.

Now task D comes along. It calls down_write(), which decrements the count to
-BIAS, sees that the zero bit is clear and the carry bit is set, and calls
down_write_failed_biased(). Here it sees that the write_bias_granted field is 1,
xchg's it for a 0, and continues on, blissfully unaware that both A and D hold
the write lock.

2) Task A holds the write lock, and task B is waiting to get the write lock. The
count is at -BIAS. Task C calls down_read_trylock(), who decrements the count to
-BIAS-1. At this moment, task A releases the write lock. It bumps the count to
-1, sees that the carry bit is clear, and continues along. Now task C bumps the
count to 0, and returns. Task B continues sleeping, unaware that the write lock
is available. The next task who tries to grab the lock will decrement the count
below zero. It'll join task B in the biased code where it'll fall into a
never-ending sleep, because no one is going to call __rwsem_wake(). Anyone else
who tries to grab the lock will fall into a similar deep, deep sleep.


Adapting from your down_write_trylock() code, I implemented a new
down_read_trylock() that avoids these races.

Same disclaimer: compiled, not tested.


-Brian

diff -ru4 2.4.1/include/asm-i386/semaphore.h 2.4.1-ben/include/asm-i386/semaphore.h
--- 2.4.1/include/asm-i386/semaphore.h  Fri Feb 16 18:47:23 2001
+++ 2.4.1-ben/include/asm-i386/semaphore.h  Tue Feb 20 14:23:19 2001
@@ -381,6 +381,61 @@
 #endif
__up_write(sem);
 }
 
+/* returns 0 if it successfully obtained the semaphore for write */
+static inline int down_write_trylock(struct rw_semaphore *sem)
+{
+   int old = RW_LOCK_BIAS, new = 0;
+
+#if WAITQUEUE_DEBUG
+   if (sem->__magic != (long)>__magic)
+   BUG();
+#endif
+   if (cmpxchg(>count.counter, old, new) == RW_LOCK_BIAS) {
+#if WAITQUEUE_DEBUG
+   if (atomic_read(>writers))
+   BUG();
+   if (atomic_read(>readers))
+   BUG();
+   if (sem->read_bias_granted)
+   BUG();
+   if (sem->write_bias_granted)
+   BUG();
+   atomic_inc(>writers);
+#endif
+   return 0;
+   }
+   else
+   return 1;
+}
+
+/* returns 0 if it successfully obtained the semaphore for read */
+static inline int down_read_trylock(struct rw_semaphore *sem)
+{
+   int old, new;
+
+#if WAITQUEUE_DEBUG
+   if (sem->__magic != (long)>__magic)
+   BUG();
+#endif
+repeat:
+   old = atomic_read(>count);
+   if (old <= 0)
+   return 1;
+   new = old - 1;
+   if (cmpxchg(>count.counter, old, new) == old) {
+#if WAITQUEUE_DEBUG
+   if (sem->write_bias_granted)
+   BUG();
+   if (atomic_read(>writers))
+   BUG();
+   atomic_inc(>readers);
+#endif
+   return 0;
+   }
+   else
+   goto repeat;
+}
+
 #endif
 #endif

RE: Assistance in understanding this...?

[Tracy Camp]

> Hi Tracy-
> 
> There was a recent thread about ext2fs-- it was
> something like doing a format of a large ext2 fs
> could cause the VM to run out of memory.
> The solution is to do a sync() calls every 10 (pick
> a number) writes so that they get flushed to disk
> and that memory can be reused.

So I'm using 2.4.1 now (on advice given by Alan Cox on the lkml related to
the ext2 fs problems talked about in the lkml archive based on the belief
that the vm was fixed in some manner related to these crashes).  The same
code as below and the same problems.  I changed the brelse() call to
bforget() - same deal except that the memory dedicated to buffers remains
constant.  It is my understanding that when calling
wait_on_buffer(bh) this in effect makes sure the operation has been
committed to disk and will give you the same result as performing a
sync().  I can trigger panics during the operation or after
the operation - the fragility seems to remain persistent.  Panic's seem to
quite consistently be 'unable to handle kernel paging request at ' or of the 'unable to handle kernel NULL pointer dereference at
virtual address ' nature.

Any other suggestions?

t.

> 
> See
> http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-07/0902.html.
> 
> HTH.
> ~Randy_
> |NOTE: Any views presented here are mine alone|
> |& may not represent the views of my employer.|
> ---
> 
> > From: Tracy Camp [mailto:[EMAIL PROTECTED]]
> > 
> > I'm developing a driver that performs some 'formatting' of 
> > sorts on a scsi
> > block device as part of the initialization process.  This involves
> > writting a long series of non-contiguous blocks to a disk device -
> > something akin to:
> > 
> > for(i =0; i < NUM_BLOCKS; i++) {
> > bh = getblk(i * offset_size);
> > memcpy(bh->b_data,,sizeof(struct somestruct));
> > mark_buffer_dirty(bh);
> > ll_rw_block(bh, WRITE,1);
> > wait_on_buffer(bh);
> > brelse(bh);
> > }
> > 
> > the kernel here I should mention is stock 2.4.0
> > 
> > This all works fine it seems, except that after awhile the 
> > system becomes
> > very fragile and eventually panic's with a NULL pointer 
> > derefrence.  This
> > presumeably occurs because of a resource shortage.  Thing I'm not
> > understand is how doing the above even for a large value of NUM_BLOCKS
> > creates a resource shortage.  I'm obviously missing something here
> > 
> > This is typically triggered by running any external program, 
> > (ie. vi, top,
> > or gcc seem to work fine for this). and the only noticable 
> > thing is that
> > the memory allocated to buffers grows to be pretty much all 
> > memory except
> > for the last two megs - this seems normal?  I can capture some of the
> > panic/dumps if anyone thinks they might be of interest.  
> > 
> > Ideas?
> > 
> > t.
> > 

Tracy Camp
Product Development
Miralink Corp.PDX
Portland OR
503-223-3140


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: plugging in 2.4. Does it work?

[Jens Axboe]

On Tue, Feb 20 2001, Peter T. Breuer wrote:
>  int my_end_request(struct request *req) {
>unsigned long flags; int dequeue = 0;
>spin_lock_irqsave(_request_lock, flags);
>if (!req->errors) {
>  while (req->nr_sectors > 0) {
>printk( KERN_DEBUG "running end_first on req with %d sectors\n",
>   req->nr_sectors);
>if (!end_that_request_first (req, !req->errors, DEVICE_NAME))
>  break;
>  }
>}
>printk( KERN_DEBUG "running end_first on req with %d sectors\n",
> req->nr_sectors);
>if (!end_that_request_first (req, !req->errors, DEVICE_NAME)) {
>  printk( KERN_DEBUG "running end_last on req with %d sectors\n",
>   req->nr_sectors);
>  end_that_request_last(req);
>  dequeue = 1;
>}
>spin_unlock_irqrestore(_request_lock, flags);
>return dequeue;
>  }

Forgot to mention that the above doesn't make much sense at all. If
there are no errors, you loop through ending all the buffers. Then
you fall through and end the the first (non-existant) chunk? And
end_that_request_first does not need to hold the io_request_lock,
you can move that down to protect end_that_request_last.

-- 
Jens Axboe

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

Re: plugging in 2.4. Does it work?

[Jens Axboe]

On Tue, Feb 20 2001, Peter T. Breuer wrote:
> More like "how does one get it to work".
> 
> Does anyone have a simple recipe for doing plugging right in 2.4?
> I'm doing something wrong.
> 
> When I disable plugging on my block driver (by registering a no-op
> plugging function), the driver works fine.  In particular my end_request
> code works fine - it does an if end_that_request_first return;
> end_that_request_last on the request to murder. Here it is
> 
>  int my_end_request(struct request *req) {
>unsigned long flags; int dequeue = 0;
>spin_lock_irqsave(_request_lock, flags);
>if (!req->errors) {
>  while (req->nr_sectors > 0) {
>printk( KERN_DEBUG "running end_first on req with %d sectors\n",
>   req->nr_sectors);
>if (!end_that_request_first (req, !req->errors, DEVICE_NAME))
>  break;
>  }
>}
>printk( KERN_DEBUG "running end_first on req with %d sectors\n",
> req->nr_sectors);
>if (!end_that_request_first (req, !req->errors, DEVICE_NAME)) {
>  printk( KERN_DEBUG "running end_last on req with %d sectors\n",
>   req->nr_sectors);
>  end_that_request_last(req);
>  dequeue = 1;
>}
>spin_unlock_irqrestore(_request_lock, flags);
>return dequeue;
>  }

Could this snippet possibly become more unreadable :-)
Firstly, I hope that the dequeue var does not return whether the 
request should be dequeued or not. Because if you do it after
end_that_request_last, you are totally screwing the request
lists. Maybe this is what's going wrong?

> I've discovered that
> 
> 1) setting read-ahead to 0 disables request agregation by some means of
> which I am not aware, and everything goes hunky dory.

Most likely what you are seeing happen is that we will do a
wait_on_buffer before we have a chance to merge this request on
the queue. Do writes, and you'll see lots of merging.

> 2) setting read-ahead to 4 or 8 seems to be safe. I see 4K requests
> being formed and treated OK.
> 
> 3) disabling plugging stops request aggretaion and makes everything
> safe.
> 
> Any clues? Is the trick just "powers of 2"? how is one supposed to
> handle plugging? Where is the canonical example. I can't see any driver
> that does it.

There's no trick, and no required values. And there's really no special
trick to handling clustered requests. Either you are doing scatter
gather and setup your sg tables by going through the complete buffer
list on the request, or you are just transferring to rq->buffer the
amount specified by current_nr_sectors. That's it. Really.

-- 
Jens Axboe

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

Re: problems with reiserfs + nfs using 2.4.2-pre4

[Brian May]

> "dek" == dek ml <[EMAIL PROTECTED]> writes:

dek> OK so I think what I can take from this is: for kernel 2.4 in
dek> the foreseeable future, reiserfs over NFS won't work without
dek> a special patch.  And, filesystems other than ext2 in general

Does this apply to the user space NFS server? kernel space NFS server?
Or both?
-- 
Brian May <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] SysV IPC semaphores, kernel 2.2.x

[Bhavesh P. Davda]

Soliciting comments to some enhancements I have made to the
implementation of SysV semaphores in the 2.2 kernel, to clean up kernel
resources (semaphores) on process exits. Please Cc: me at
bhavesh(at)avaya.com

Thanks,
- Bhavesh 
-- 
Bhavesh P. Davda
Avaya Inc.

--- /root2/usr/src/linux-2.2.16/ipc/sem.c   Wed May  3 18:16:53 2000
+++ /usr/src/linux-2.2.16/ipc/sem.c Tue Feb 20 15:04:25 2001
@@ -48,6 +48,23 @@
  *  better but only get the semops right which only wait for zero
or
  *  increase. If there are decrement operations in the operations
  *  array we do the same as before.
+ *
+ * Enhancements added February 2001:
+ * Copyright (C) 2001 Bhavesh Davda
+ *  One can ask for semaphores that are accounted for using two new
flags
+ *  when creating the semaphore set:
+ *  IPC_CLNUP:  maintains a count of the number of processes that have
a
+ *  handle to the semaphore set, and frees the semaphore
set
+ *  when the last process with a handle to the set goes
away
+ *  IPC_TMWU:   (Take Me With U) frees the semaphore set when the
creator
+ *  of the semaphore set goes away
+ * These enhancements were added to plug a Denial-Of-Service hole that
has
+ * always existed with semaphores as a system resource. Accidental DOS,
for
+ * example "kill -9" leaving semaphore sets around can be prevented by 
+ * freeing system resources when they are no longer being used, by 
+ * passing these flags when creating the semaphores.
+ * WORK NEEDED: locks to protect data structures (linked lists) from
race
+ * conditions (specifically in insertlist(), deletelist() and
eatlist())
  */
 
 #include 
@@ -66,6 +83,26 @@
 static struct wait_queue *sem_lock = NULL;
 static int max_semid = 0;
 
+struct proclist {
+   struct proclist *next;
+   pid_t pid;
+};
+
+struct semproc {
+   int numclients;
+   pid_t creator;
+   struct proclist *head;
+};
+
+static struct semproc persemid[SEMMNI];
+
+struct semlist {
+   struct semlist *next;
+   int semid;
+};
+
+static struct semlist *perprocess[PID_MAX];
+
 static unsigned short sem_seq = 0;
 
 void __init sem_init (void)
@@ -74,11 +111,191 @@
 
sem_lock = NULL;
used_sems = used_semids = max_semid = sem_seq = 0;
-   for (i = 0; i < SEMMNI; i++)
+   for (i = 0; i < SEMMNI; i++) {
semary[i] = (struct semid_ds *) IPC_UNUSED;
+   persemid[i].numclients = SEM_DONTCOUNT;
+   persemid[i].creator = SEM_DONTCOUNT;
+   persemid[i].head = NULL;
+   }
+   for (i = 0; i < PID_MAX; i++) {
+   perprocess[i] = NULL;
+   }
return;
 }
 
+static void insertlist(int pid, int semid)
+{
+   struct semlist *newsem;
+   struct proclist *newproc;
+   /* create a new node for the per process list */
+   newsem = (struct semlist *) 
+   kmalloc(sizeof(struct semlist), GFP_ATOMIC);
+   newsem->semid = semid;
+   newsem->next = NULL;
+   if (perprocess[pid]) {
+   /* linked list exists, prepend to it */
+   newsem->next = perprocess[pid];
+   }
+   perprocess[pid] = newsem;
+
+   /* create a new node for the per semid list */
+   newproc = (struct proclist *) 
+   kmalloc(sizeof(struct proclist), GFP_ATOMIC);
+   newproc->pid = pid;
+   newproc->next = NULL;
+   if (persemid[semid].head) {
+   /* linked list exists, prepend to it */
+   newproc->next = persemid[semid].head;
+   }
+   persemid[semid].head = newproc;
+}
+
+#ifdef DEBUG
+static void dumplists (int pid, int semid)
+{
+   struct semlist *currsem;
+   struct proclist *currproc;
+
+   printk("Linked list of semids for pid %d\n", pid);
+   currsem = perprocess[pid];
+   while (currsem) {
+   printk("[%d]->", currsem->semid);
+   currsem = currsem->next;
+   }
+   printk("$\n");
+
+   printk("Linked list of pids for semid %d\n", semid);
+   currproc = persemid[semid].head;
+   while (currproc) {
+   printk("[%d]->", currproc->pid);
+   currproc = currproc->next;
+   }
+   printk("$\n");
+}
+#endif
+
+static void deletelist(int pid, int semid)
+{
+   struct semlist *currsem, *prevsem;
+   struct proclist *currproc, *prevproc;
+
+   /* first delete semaphore from perprocess list */
+   prevsem = NULL;
+   currsem = perprocess[pid];
+
+   while (currsem && (currsem->semid != semid)) {
+   prevsem = currsem;
+   currsem = currsem->next;
+   }
+
+   /* didn't find it */
+   if (currsem == NULL) {
+   return;
+   }
+
+#ifdef DEBUG
+printk("deletelist: About to remove node semid %d from
perprocess[%d]\n",
+   semid, pid);
+#endif
+   if (prevsem == NULL) {
+   /* head of list */
+   perprocess[pid] = currsem->next;
+   } else {
+   

Re: [rfc] Near-constant time directory index for Ext2

[Jeremy Jackson]

Mike Dresser wrote:

> the way i'm reading this, the problem is there's 65535 files in the directory
> /where/postfix/lives.  rm * or what have you, is going to take forever and
> ever, and bog the machine down while its doing it.  My understanding is you
> could do the rm *, and instead of it reading the tree over and over for every
> file that has to be deleted, it just jumps one or two blocks to the file that's
> being deleted, instead of thousands of files to be scanned for each file
> deleted.
>

I thought about it again, and the proformance problem with "rm *" is that
the shell reads and sorts the directory, passes each file as a separate
argument to rm, which then causes the kernel to lookup each file
from a random directory block (random because of previous sort),
modify that directory block, then read another... after a few seconds
the modified blocks start to be written back to disk while new ones
are looked up... disk seek contention.  and this becomes hard on the
dir. block cache (wherever this is) since from source each dir entry
is just over 256 bytes (?) 65535 files would require 16MB to
cache dir entries.  Plus it has to read in all the inodes, modify,
then write, taking up xxMB more.  You're probably swapping
out,  with swap partition on same disk, the disk may explode.

If it were truly doing a linear scan, it might be faster.  Two
successive mods to same dir block would be merged
onto same write.

Perhaps rm -rf . would be faster?  Let rm do glob expansion,
without the sort.  Care to recreate those 65535 files and try it?

or use ls with the nosort flag pipe through xargs then to rm...
again loose sorting but don't delete directory or subdirs.

>
> Jeremy Jackson wrote:
>
> > > In article <01022020011905.18944@gimli>,
> > > Daniel Phillips  <[EMAIL PROTECTED]> wrote:
> > > >Earlier this month a runaway installation script decided to mail all its
> > > >problems to root.  After a couple of hours the script aborted, having
> > > >created 65535 entries in Postfix's maildrop directory.  Removing those
> > > >files took an awfully long time.  The problem is that Ext2 does each
> > > >directory access using a simple, linear search though the entire
> > > >directory file, resulting in n**2 behaviour to create/delete n files.
> > > >It's about time we fixed that.
> >

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

plugging in 2.4. Does it work?

[Peter T. Breuer]

More like "how does one get it to work".

Does anyone have a simple recipe for doing plugging right in 2.4?
I'm doing something wrong.

When I disable plugging on my block driver (by registering a no-op
plugging function), the driver works fine.  In particular my end_request
code works fine - it does an if end_that_request_first return;
end_that_request_last on the request to murder. Here it is

 int my_end_request(struct request *req) {
   unsigned long flags; int dequeue = 0;
   spin_lock_irqsave(_request_lock, flags);
   if (!req->errors) {
 while (req->nr_sectors > 0) {
   printk( KERN_DEBUG "running end_first on req with %d sectors\n",
  req->nr_sectors);
   if (!end_that_request_first (req, !req->errors, DEVICE_NAME))
 break;
 }
   }
   printk( KERN_DEBUG "running end_first on req with %d sectors\n",
req->nr_sectors);
   if (!end_that_request_first (req, !req->errors, DEVICE_NAME)) {
 printk( KERN_DEBUG "running end_last on req with %d sectors\n",
  req->nr_sectors);
 end_that_request_last(req);
 dequeue = 1;
   }
   spin_unlock_irqrestore(_request_lock, flags);
   return dequeue;
 }

When I allow the kernel to use its default plugging function and
enable read-ahead of 20, I see read requests being aggregated
10-in-one with 1K blocks, but the userspace request hangs, or
the calling process dies! Or worse. Sometimes I get some
recordable logs .. and they show nothing wrong:

Feb 20 10:46:42 barney kernel: running end_first on req with 20 sectors
Feb 20 10:46:42 barney kernel: running end_first on req with 18 sectors
Feb 20 10:46:42 barney kernel: running end_first on req with 16 sectors
Feb 20 10:46:42 barney kernel: running end_first on req with 14 sectors
Feb 20 10:46:42 barney kernel: running end_first on req with 12 sectors
Feb 20 10:46:42 barney kernel: running end_first on req with 10 sectors
Feb 20 10:46:42 barney kernel: running end_first on req with 8 sectors
Feb 20 10:46:42 barney kernel: running end_first on req with 6 sectors
Feb 20 10:46:42 barney kernel: running end_first on req with 4 sectors
Feb 20 10:46:42 barney kernel: running end_first on req with 2 sectors
Feb 20 10:46:42 barney kernel: running end_first on req with 2 sectors
Feb 20 10:46:42 barney kernel: running end_last on req with 2 sectors
Feb 20 10:52:47 barney kernel: running end_first on req with 2 sectors
Feb 20 10:52:47 barney kernel: running end_first on req with 2 sectors
Feb 20 10:52:47 barney kernel: running end_last on req with 2 sectors

But death follows soomer rather than later.

I've discovered that

1) setting read-ahead to 0 disables request agregation by some means of
which I am not aware, and everything goes hunky dory.

2) setting read-ahead to 4 or 8 seems to be safe. I see 4K requests
being formed and treated OK.

3) disabling plugging stops request aggretaion and makes everything
safe.

Any clues? Is the trick just "powers of 2"? how is one supposed to
handle plugging? Where is the canonical example. I can't see any driver
that does it.

Peter

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

Re: [lvm-devel] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com

[Andrea Arcangeli]

On Tue, Feb 20, 2001 at 10:49:07PM +, Heinz Mauelshagen wrote:
> 
> Hi all,
> 
> a tarball of the Linux Logical Volume Manager 0.9.1 Beta 5 is available now at
> 
>
> 
> for download (Follow the "LVM download page" link).
> 
> This release fixes several bugs.
> See the CHANGELOG file contained in the tarball for further information.
> 
> A change in the i/o protocoll version *forces* you to update
> the driver as well.
> Follow instructions in PATCHES/README to achieve this please.
> 
> 
> Please help us to stabilize for 0.9.1 ASAP and test is as much as possible!
> Feed back related information to <[EMAIL PROTECTED]>.

The bheads in the lv_t is the wrong way to go, I just wrote an alternate patch
for rawio that keeps the bh inside the kiovec, not in the lv, this also
imrproves rawio performance in general (such allocation deallocation flood was
wasteful). No a single change is required at the lvm layer, all the changes lives in
the kiobuf layer. It's tested and it works for me.

diff -urN rawio-ref/fs/buffer.c rawio/fs/buffer.c
--- rawio-ref/fs/buffer.c   Tue Feb 20 23:17:10 2001
+++ rawio/fs/buffer.c   Tue Feb 20 23:17:27 2001
@@ -1240,6 +1240,29 @@
wake_up(_wait);
 }
 
+int alloc_kiobuf_bhs(struct kiobuf * kiobuf)
+{
+   int i, j;
+
+   for (i = 0; i < KIO_MAX_SECTORS; i++)
+   if (!(kiobuf->bh[i] = get_unused_buffer_head(0))) {
+   for (j = 0; j < i; j++)
+   put_unused_buffer_head(kiobuf->bh[j]);
+   wake_up(_wait);
+   return -ENOMEM;
+   }
+   return 0;
+}
+
+void free_kiobuf_bhs(struct kiobuf * kiobuf)
+{
+   int i;
+
+   for (i = 0; i < KIO_MAX_SECTORS; i++)
+   put_unused_buffer_head(kiobuf->bh[i]);
+   wake_up(_wait);
+}
+
 static void end_buffer_io_async(struct buffer_head * bh, int uptodate)
 {
unsigned long flags;
@@ -1333,10 +1356,8 @@
iosize = 0;
}

-   put_unused_buffer_head(tmp);
iosize += size;
}
-   wake_up(_wait);

dprintk ("do_kio end %d %d\n", iosize, err);

@@ -1390,7 +1411,7 @@
int i;
int bufind;
int pageind;
-   int bhind;
+   int bhind, kiobuf_bh_nr;
int offset;
unsigned long   blocknr;
struct kiobuf * iobuf = NULL;
@@ -1422,6 +1443,7 @@
 */
bufind = bhind = transferred = err = 0;
for (i = 0; i < nr; i++) {
+   kiobuf_bh_nr = 0;
iobuf = iovec[i];
err = setup_kiobuf_bounce_pages(iobuf, GFP_USER);
if (err) 
@@ -1444,12 +1466,8 @@
 
while (length > 0) {
blocknr = b[bufind++];
-   tmp = get_unused_buffer_head(0);
-   if (!tmp) {
-   err = -ENOMEM;
-   goto error;
-   }
-   
+   tmp = iobuf->bh[kiobuf_bh_nr++];
+
tmp->b_dev = B_FREE;
tmp->b_size = size;
tmp->b_data = (char *) (page + offset);
@@ -1460,7 +1478,8 @@
if (rw == WRITE) {
set_bit(BH_Uptodate, >b_state);
set_bit(BH_Dirty, >b_state);
-   }
+   } else
+   clear_bit(BH_Uptodate, >b_state);
 
dprintk ("buffer %d (%d) at %p\n", 
 bhind, tmp->b_blocknr, tmp->b_data);
@@ -1478,7 +1497,7 @@
transferred += err;
else
goto finished;
-   bhind = 0;
+   kiobuf_bh_nr = bhind = 0;
}

if (offset >= PAGE_SIZE) {
@@ -1506,17 +1525,6 @@
if (transferred)
return transferred;
return err;
-
- error:
-   /* We got an error allocation the bh'es.  Just free the current
-   buffer_heads and exit. */
-   for (i = 0; i < bhind; i++)
-   put_unused_buffer_head(bh[i]);
-   wake_up(_wait);
-
-   clear_kiobuf_bounce_pages(iobuf);
-
-   goto finished;
 }
 
 /*
diff -urN rawio-ref/fs/iobuf.c rawio/fs/iobuf.c
--- rawio-ref/fs/iobuf.cTue Feb 20 23:17:10 2001
+++ rawio/fs/iobuf.cTue Feb 20 23:17:24 2001
@@ -41,6 +41,11 @@

Re: [PATCH] exclusive wakeup for lock_buffer

[Alan Cox]

> > >  extern void __wait_on_buffer(struct buffer_head *);
> > > +extern void __lock_buffer(struct buffer_head *);
> > 
> > So are we starting 2.5 now ?
> 
> Alan,
> 
> This patch only avoids unecessary wakeups. It doesn't add any new
> functionality.

I think making potentially very hard to debug changes to core code for
minor performance reasons alone isnt 2.4.x work. At least not yet

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] exclusive wakeup for lock_buffer

[Marcelo Tosatti]

On Tue, 20 Feb 2001, Alan Cox wrote:

> > --- linux/include/linux/locks.h.origMon Feb 19 23:16:50 2001
> > +++ linux/include/linux/locks.h Mon Feb 19 23:21:48 2001
> > @@ -13,6 +13,7 @@
> >   * lock buffers.
> >   */
> >  extern void __wait_on_buffer(struct buffer_head *);
> > +extern void __lock_buffer(struct buffer_head *);
> 
> So are we starting 2.5 now ?

Alan,

This patch only avoids unecessary wakeups. It doesn't add any new
functionality.




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] configurable printk buffer size

[Robert Read]

The obvious solution struck me just after the last email.  I change
the config parameter to be an order, like the argument to
get_free_pages().  How does this look?  It's not tested, but there
isn't much to it...

robert


diff --exclude=*~ -ru linux-2.4.2-pre4/arch/i386/config.in 
linux-2.4.2-pre4-logbuf/arch/i386/config.in
--- linux-2.4.2-pre4/arch/i386/config.inMon Jan  8 13:27:56 2001
+++ linux-2.4.2-pre4-logbuf/arch/i386/config.in Tue Feb 20 14:10:12 2001
@@ -366,4 +366,5 @@
 
 #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+int 'Printk buffer size order 2**x' CONFIG_PRINTK_BUF_ORDER 14
 endmenu
diff --exclude=*~ -ru linux-2.4.2-pre4/kernel/printk.c 
linux-2.4.2-pre4-logbuf/kernel/printk.c
--- linux-2.4.2-pre4/kernel/printk.cTue Feb 20 11:56:31 2001
+++ linux-2.4.2-pre4-logbuf/kernel/printk.c Tue Feb 20 14:10:06 2001
@@ -23,7 +23,11 @@
 
 #include 
 
-#define LOG_BUF_LEN(16384)
+#ifdef CONFIG_PRINTK_BUF_LEN
+# define LOG_BUF_LEN   (2**CONFIG_PRINTK_BUF_ORDER)
+#else
+# define LOG_BUF_LEN   (16384)
+#endif   
 #define LOG_BUF_MASK   (LOG_BUF_LEN-1)
 
 static char buf[1024];

Re: [PATCH] Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.

[Robert Read]

On Tue, Feb 20, 2001 at 02:53:04PM -0600, Thomas Dodd wrote:
> Robert Read wrote:
> 
> Why not just make the config option in Kbytes.
> and do:
> 
> #define LOG_BUF_LEN (CONFIG_PRINTK_BUF_LEN * 1024)
> 

This is good idea, but I believe LOG_BUF_LEN needs to be a power of
2.  A bitmask is used in several places to wrap around the end of the
ring buffer.  For example

#define LOG_BUF_MASK (LOG_BUF_LEN-1)

printk() {
  
  log_buf[(log_start+log_size) & LOG_BUF_MASK] = *p;
}


I think LOG_BUF_LEN could be defined to round up (or down) at compile
time, but my post-lunch-sleepy brain can't think of the trick to do
it.

robert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [rfc] Near-constant time directory index for Ext2

[Daniel Phillips]

On Tue, 20 Feb 2001, Linus Torvalds wrote:
> In article <01022020011905.18944@gimli>,
> Daniel Phillips  <[EMAIL PROTECTED]> wrote:
> >Earlier this month a runaway installation script decided to mail all its
> >problems to root.  After a couple of hours the script aborted, having
> >created 65535 entries in Postfix's maildrop directory.  Removing those
> >files took an awfully long time.  The problem is that Ext2 does each
> >directory access using a simple, linear search though the entire
> >directory file, resulting in n**2 behaviour to create/delete n files. 
> >It's about time we fixed that.
> 
> Interesting.
> 
> However, if you're playing with the directory structure, please consider
> getting rid of the "struct buffer_head"-centricity, and using the page
> cache instead.  The page cache has much nicer caching semantics, and
> looking up data in the page cache is much faster because it never needs
> to do the "virtual->physical" translation. 

Oh yes, I was planning on it.  I started with the buffers version
for two main reasons version: 1) it's simple and solid and 2) it
provides the basis for a backport to 2.2 - after the 2.4/2.5 version is
complete of course.

> Talk to Al Viro about this - he's already posted patches to move the
> regular ext2 directory tree into the page cache, and they weren't
> applied to 2.4.x only because there was no great feeling of "we _must_
> do this for correctness".
> 
> I see that you already considered this issue, but I wanted to bring it
> up again simply because something like this certainly looks like a
> potential candidate for 2.5.x, but I will _refuse_ to add code that
> increases our reliance of "struct buffer_head" as a caching entity.  So
> I'd rather see the page cache conversion happen sooner rather than
> later... 

You are preaching to the converted.

> Also, just out of interest: if you've already been worrying about
> hashes, what's the verdict on just using the native dentry hash value
> directly? It has other constraints (_really_ low latency and absolutely
> performance critical to calculate for the common case, which is not
> needing a real lookup at all), but maybe it is good enough? And if not,
> and you have done some statistics on it, I'd love to hear about it ;)

You mean full_name_hash?  I will un-static it and try it.  I should have
some statistics tomorrow.  I have a couple of simple metrics for
measuring the effectiveness of the hash function: the uniformity of
the hash space splitting (which in turn affects the average fullness
of directory leaves) and speed.

Let the hash races begin.

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

make drivers/scsi/seagate.c use ioremap instead of isa_{read,write} (242p4)

[Rasmus Andersen]

Hi.

(I have not been able to find a probable current maintainer for
this code.)

The following patch makes drivers/scsi/seagate.c use ioremap
instead of isa_{read, write} (I have not been able to find
a fitting place to put an iounmap since the driver does not
have a release function). The patch also removes some unneces-
sary zero initialization and fixes some resource leaks in
the init/detection process.

It applies against 241ac19 and 242p4.

Comments?.

--- linux-241ac19-clean/drivers/scsi/seagate.c  Sun Nov 12 04:01:11 2000
+++ linux-241ac19/drivers/scsi/seagate.cTue Feb 20 22:32:10 2001
@@ -230,7 +230,7 @@
 static int incommand;   /* set if arbitration has finished
and we are in some command phase. */
 
-static unsigned int base_address = 0;   /* Where the card ROM starts, used to 
+static unsigned int base_address;   /* Where the card ROM starts, used to 
calculate memory mapped register
location.  */
 
@@ -243,23 +243,26 @@
 static unsigned long st0x_dr;   /* data register, read write 256
bytes in length.  */
 
-static volatile int st0x_aborted = 0;   /* set when we are aborted, ie by a
+static volatile int st0x_aborted;   /* set when we are aborted, ie by a
time out, etc.  */
 
-static unsigned char controller_type = 0;   /* set to SEAGATE for ST0x
-   boards or FD for TMC-8xx
-   boards */
+static unsigned char controller_type;   /* set to SEAGATE for ST0x
+   boards or FD for TMC-8xx
+   boards */
 static int irq = IRQ;
 
+static void *status_remap;
+static void *data_remap;
+
 MODULE_PARM(base_address, "i");
 MODULE_PARM(controller_type, "b");
 MODULE_PARM(irq, "i");
 
 #define retcode(result) (((result) << 16) | (message << 8) | status)
-#define STATUS ((u8) isa_readb(st0x_cr_sr))
-#define DATA ((u8) isa_readb(st0x_dr))
-#define WRITE_CONTROL(d) { isa_writeb((d), st0x_cr_sr); }
-#define WRITE_DATA(d) { isa_writeb((d), st0x_dr); }
+#define STATUS ((u8) readb(status_remap))
+#define DATA ((u8) readb(data_remap))
+#define WRITE_CONTROL(d) { writeb((d), status_remap); }
+#define WRITE_DATA(d) { writeb((d), data_remap); }
 
 void st0x_setup (char *str, int *ints)
 {
@@ -489,13 +492,13 @@
  */
   instance = scsi_register (tpnt, 0);
   if(instance == NULL)
-   return 0;
+goto err_scsi_register;

   hostno = instance->host_no;
   if (request_irq (irq, do_seagate_reconnect_intr, SA_INTERRUPT,
   (controller_type == SEAGATE) ? "seagate" : "tmc-8xx", NULL)) {
 printk ("scsi%d : unable to allocate IRQ%d\n", hostno, irq);
-return 0;
+goto err_request_irq;
   }
   instance->irq = irq;
   instance->io_port = base_address;
@@ -546,7 +549,25 @@
 " SWAPCNTDATA"
 #endif
  "\n", tpnt->name);
+
+  status_remap = ioremap(st0x_cr_sr, sizeof(u8));
+  if (!status_remap)
+goto err_status_remap;
+
+  data_remap = ioremap(st0x_dr, sizeof(u8));
+  if (!data_remap)
+goto err_data_remap;
+  
   return 1;
+
+ err_data_remap:
+  iounmap(status_remap);
+ err_status_remap:
+  free_irq(irq, do_seagate_reconnect_intr);
+ err_request_irq:
+  scsi_unregister(instance);
+ err_scsi_register:
+  return 0;
 }
 
 const char *seagate_st0x_info (struct Scsi_Host *shpnt)


-- 
Rasmus([EMAIL PROTECTED])

It is wonderful to be here in the great state of Chicago.
-Former U.S. Vice-President Dan Quayle
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.

[Ishikawa]

Robert Read wrote:

> I have used 128k and larger buffer sizes, and I just noticed this
> fragment in the RedHat Tux Webserver patch.  It creates a 2MB buffer:
>
>

I am encouraged to try a large buffer then.

Thank you.



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

Re: [rfc] Near-constant time directory index for Ext2

[Mike Dresser]

the way i'm reading this, the problem is there's 65535 files in the directory
/where/postfix/lives.  rm * or what have you, is going to take forever and
ever, and bog the machine down while its doing it.  My understanding is you
could do the rm *, and instead of it reading the tree over and over for every
file that has to be deleted, it just jumps one or two blocks to the file that's
being deleted, instead of thousands of files to be scanned for each file
deleted.

Jeremy Jackson wrote:

> > In article <01022020011905.18944@gimli>,
> > Daniel Phillips  <[EMAIL PROTECTED]> wrote:
> > >Earlier this month a runaway installation script decided to mail all its
> > >problems to root.  After a couple of hours the script aborted, having
> > >created 65535 entries in Postfix's maildrop directory.  Removing those
> > >files took an awfully long time.  The problem is that Ext2 does each
> > >directory access using a simple, linear search though the entire
> > >directory file, resulting in n**2 behaviour to create/delete n files.
> > >It's about time we fixed that.
>
> In the case of your script I'm not sure this will help, but:
> I've seen /home directories organised like /home/a/adamsonj,
> /home/a/arthurtone, /home/b/barrettj, etc.
> this way (crude) indexing only costs areas where it's needed,
> without kernel modification. (app does it)  What other placed would we
> need indexing *in* the filesystem?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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: Reiserfs, 3 Raid1 arrays, 2.4.1 machine locks up

[Colonel]

   From: "Tom Sightler" <[EMAIL PROTECTED]>
   Cc: <[EMAIL PROTECTED]>
   Date: Tue, 20 Feb 2001 14:43:07 -0500
   Content-Type: text/plain;
   charset="iso-8859-1"

   >> >I'm building a firewall on a P133 with 48 MB of memory using RH 7.0,
   >> >latest updates, etc. and kernel 2.4.1.
   >> >I've built a customized install of RH (~200MB)  which I untar onto
   the
   >> >system after building my raid arrays, etc. via a Rescue CD which I
   >> >created using Timo's Rescue CD project.  The booting kernel is
   >> >2.4.1-ac10, no networking, raid compiled in but raid1 as a module
   >>
   >> Hmm, raid as a module was always a Bad Idea(tm) in the 2.2 "alpha"
   >> raid (which was misnamed and is 2.4 raid).  I suggest you change that
   >> and update, as I had no problems with 2.4.2-pre2/3, nor have any been
   >> posted to the raid list.
   >
   >I just tried with 2.4.1-ac14, raid and raid1 compiled in and it did the
   >same thing.  I'm going to try to compile reiserfs in (if I have enough
   room
   >to still fit the kernel on the floppy with it's initial ramdisk, etc.)
   and
   >see what that does.

   There seem to be several reports of reiserfs falling over when memory is
   low.  It seems to be undetermined if this problem is actually reiserfs or MM
   related, but there are other threads on this list regarding similar issues.
   This would explain why the same disk would work on a different machine with
   more memory.  Any chance you could add memory to the box temporarily just to
   see if it helps, this may help prove if this is the problem or not.


Well, I didn't happen to start the thread, but your comments may
explain some "gee I wonder if it died" problems I just had with my
2.4.1-pre2+reiser test box.  It only has 16M, so it's always low
memory (never been a real problem in the past however).  The test
situation is easily repeatable for me [1].  It's a 486 wall mount, so
it's easier to convert the fs than add memory, and it showed about
200k free at the time of the sluggishness.  Previous 2.4.1 testing
with ext2 fs didn't show any sluggishness, but I also didn't happen to
run the test above either.  When I come back to the office later, I'll
convert the fs, repeat the test and pass on the results.


[1]  Since I decided to try to catch up on kernels, I had just grabbed
-ac18, cd to ~linux and run "rm -r *" via an ssh connection.  In a
second connection, I tried a simple "dmesg" and waited over a minute
for results (long enough to log in directly on the box and bring up
top) followed by loading emacs for ftp transfers from kernel.org,
which again 'went to sleep'.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [rfc] Near-constant time directory index for Ext2

[Jeremy Jackson]

> In article <01022020011905.18944@gimli>,
> Daniel Phillips  <[EMAIL PROTECTED]> wrote:
> >Earlier this month a runaway installation script decided to mail all its
> >problems to root.  After a couple of hours the script aborted, having
> >created 65535 entries in Postfix's maildrop directory.  Removing those
> >files took an awfully long time.  The problem is that Ext2 does each
> >directory access using a simple, linear search though the entire
> >directory file, resulting in n**2 behaviour to create/delete n files.
> >It's about time we fixed that.

In the case of your script I'm not sure this will help, but:
I've seen /home directories organised like /home/a/adamsonj,
/home/a/arthurtone, /home/b/barrettj, etc.
this way (crude) indexing only costs areas where it's needed,
without kernel modification. (app does it)  What other placed would we
need indexing *in* the filesystem?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [beta patch] SSE copy_page() / clear_page()

[Manfred Spraul]

Pavel Machek wrote:
> 
> > > > + __asm__ __volatile__(
> > > > + "mov %1, %0\n\t"
> > > > + : "=r" (i)
> > > > + : "r" (kaddr+offset)); /* load tlb entry */
> > > > + for(i=0;i > > > + __asm__ __volatile__(
> > > > + "prefetchnta (%1, %0)\n\t"
> > > > + "prefetchnta 32(%1, %0)\n\t"
> > > > + : /* no output */
> > > > + : "r" (i), "r" (kaddr+offset));
> > > > + }
> > > > + }
> > > >   left = __copy_to_user(desc->buf, kaddr + offset, size);
> > > >   kunmap(page);
> > >
> > > This seems bogus -- you need to handle faults --
> > > i.e. __prefetchnta_to_user() ;-).
> >

Ahm. That's file_read_actor, not file_write_actor ;-)
I'm prefetching the kernel space buffer.

> > It wants wrapping nicely. A generic prefetch and prefetchw does help some other
> > cases (scheduler for one).
> >
> > Does the prefetch instruction fault on PIII/PIV then - the K7 one appears not
> > to be a source of faults
> 
> My fault. I was told that prefetch instructions are always
> non-faulting.
>

But there is another problem:

The tlb preloading with a simple 'mov' is not enough:
the Pentium III cpu decodes the 'mov', begins to load the tlb entry -
this will take at least several dozend cpu ticks.

But the cpu continues to decode further instructions. It sees the
'prefetchnta', notices that the tlb entry is not loaded and ignores the
next prefetchnta's (prefetch without tlb is turned into NOP).

--  
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Reiserfs, 3 Raid1 arrays, 2.4.1 machine locks up

[James A. Pattie]

Tom Sightler wrote:

> > > There seem to be several reports of reiserfs falling over when memory is
> > > low.  It seems to be undetermined if this problem is actually reiserfs
> or MM
> > > related, but there are other threads on this list regarding similar
> issues.
> > > This would explain why the same disk would work on a different machine
> with
> > > more memory.  Any chance you could add memory to the box temporarily
> just to
> > > see if it helps, this may help prove if this is the problem or not.
> > >
> >
> > Out of all the old 72 pin simms we have, we have it maxed out at 48 MB's.
> I'm
> > tempted to take the 2 drives out and put them in the k6-2, but that's too
> much
> > of a hassle.  I'm currently going to try 2.4.1-ac19 and see what happens.
> >
> > The machine does have 128MB of swap space working, and whenever I've
> checked
> > memory usage (while the system was still responding), it never went over a
> > couple megs of swap space used.
>
> Ah yes, but, from what I've read, the problem seems to occur when
> buffer/cache memory is low (<6MB), you could have tons of swap and still
> reach this level.
>
> Later,
> Tom

You were right!  I managed to find another 32MB of memory to bump it up to 64
MB total and it worked perfectly.  It appears that I had only about 4 MB of
buffer/cache in the 48 MB system and over 15MB in the 64 MB system.  I did my
install and switched back to the 48MB running normally and its working just
fine.

Thanks,


--
James A. Pattie
[EMAIL PROTECTED]

Linux  --  SysAdmin / Programmer
PC & Web Xperience, Inc.
http://www.pcxperience.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: [beta patch] SSE copy_page() / clear_page()

[Alan Cox]

> > Does the prefetch instruction fault on PIII/PIV then - the K7 one appears not
> > to be a source of faults
> 
> My fault. I was told that prefetch instructions are always
> non-faulting.

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

radio-terratec.c + RDS

[Rolf Offermanns]

Hi!
I have written the radio-terratec driver some time ago.

I am searching for someone who has send me an email about him being able to 
get the RDS part of the terratec card to work.

Unfortunately I have lost the mail and his address.

If you are reading this, please contact me.

Allthough I am reading the ml archive please CC: to me.

Thanks,
Rolf


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] 2.4.1-ac UP-APIC updates

[Ingo Molnar]

On Tue, 20 Feb 2001, Alan Cox wrote:

> > i dont like this one. 100 times a second makes absolutely no performance
> > difference whatsoever - but eg. i'm driving kernel profiling from the NMI
> > handler to get profiles of eg. IRQ handlers and other cli()-ed code areas.
>
> So set it to 100Hz as a debugging option like slab debugging

my major gripe right now is that we still have bug reports that say that
systems hang when using nmi_watchdog=1 and work if nmi_watchdog=0.
Changing the NMI watchdog to be 1 Hz will make these bugreports "Linux
hangs once a week" instead of a "Linux hangs after 1-2 hours", which is
clearly hiding things and making debugging harder.

(and driving kernel-profiling from the NMI interrupt is a short-term
patch, so there is just no point in going to 1 Hz right now just to go
back to 100 Hz a few days later.)

the rest of the changes are excellent - it's only the 100 Hz NMI issue i
have a problem with.

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: [PATCH] Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.

[Thomas Dodd]

Thomas Dodd wrote:
> 
> Robert Read wrote:
> >
> > Ok, here is a simple patch to add a config option, I'm compiling it
> > now, so it's not tested yet.  One question: what is the best way to
> > force this option to be a power of 2?
> 
> Why not just make the config option in Kbytes.
> and do:
> 
> #define LOG_BUF_LEN (CONFIG_PRINTK_BUF_LEN * 1024)
> 
> since the config option has a default option and will
> always be defined, is the #ifdef check really needed?

Oops...

It's not needed if all arch's have the config option added.
Only parisc uses a different file, config.common instead of config.in
Would this break any thing?

-Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [beta patch] SSE copy_page() / clear_page()

[Pavel Machek]

> > > + __asm__ __volatile__(
> > > + "mov %1, %0\n\t"
> > > + : "=r" (i)
> > > + : "r" (kaddr+offset)); /* load tlb entry */
> > > + for(i=0;i > > + __asm__ __volatile__(
> > > + "prefetchnta (%1, %0)\n\t"
> > > + "prefetchnta 32(%1, %0)\n\t"
> > > + : /* no output */
> > > + : "r" (i), "r" (kaddr+offset));
> > > + }
> > > + }
> > >   left = __copy_to_user(desc->buf, kaddr + offset, size);
> > >   kunmap(page);
> > 
> > This seems bogus -- you need to handle faults --
> > i.e. __prefetchnta_to_user() ;-).
> 
> It wants wrapping nicely. A generic prefetch and prefetchw does help some other
> cases (scheduler for one).
> 
> Does the prefetch instruction fault on PIII/PIV then - the K7 one appears not
> to be a source of faults

My fault. I was told that prefetch instructions are always
non-faulting.

Pavel

-- 
The best software in life is free (not shareware)!  Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Probem with network performance 2.4.1

[Mike Galbraith]

On Tue, 20 Feb 2001, Richard B. Johnson wrote:

> There is nothing in either the VXI/Bus driver or the the Ethernet
> driver that gives up the CPU, i.e., nobody calls schedule() in any
> (known) path.

Check out IKD.  Ktrace is wonderful for making such unknowns visible.

-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: [beta patch] SSE copy_page() / clear_page()

[Alan Cox]

> > +   __asm__ __volatile__(
> > +   "mov %1, %0\n\t"
> > +   : "=r" (i)
> > +   : "r" (kaddr+offset)); /* load tlb entry */
> > +   for(i=0;i > +   __asm__ __volatile__(
> > +   "prefetchnta (%1, %0)\n\t"
> > +   "prefetchnta 32(%1, %0)\n\t"
> > +   : /* no output */
> > +   : "r" (i), "r" (kaddr+offset));
> > +   }
> > +   }
> > left = __copy_to_user(desc->buf, kaddr + offset, size);
> > kunmap(page);
> 
> This seems bogus -- you need to handle faults --
> i.e. __prefetchnta_to_user() ;-).

It wants wrapping nicely. A generic prefetch and prefetchw does help some other
cases (scheduler for one).

Does the prefetch instruction fault on PIII/PIV then - the K7 one appears not
to be a source of faults

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: can somebody explain barrier() macro ?

[Alan Cox]

> barrier() is defined in kernel.h as follows :
> 
> #define barrier() __asm__ __volatile__("": : :"memory")
> 
> what does this mean ? is this like "nop" ?

Its adds an empty piece of assembler (ie no code) and declares that this
non code causes effects on memory. That forces gcc to writeback before the
barrier and reload cached values afterwards
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] 2.4.1-ac UP-APIC updates

[Alan Cox]

> i dont like this one. 100 times a second makes absolutely no performance
> difference whatsoever - but eg. i'm driving kernel profiling from the NMI
> handler to get profiles of eg. IRQ handlers and other cli()-ed code areas.

So set it to 100Hz as a debugging option like slab 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: Probem with network performance 2.4.1

[Richard B. Johnson]

On Tue, 20 Feb 2001, Mike Galbraith wrote:

> On Tue, 20 Feb 2001, Richard B. Johnson wrote:
> 
> > There is nothing in either the VXI/Bus driver or the the Ethernet
> > driver that gives up the CPU, i.e., nobody calls schedule() in any
> > (known) path.
> 
> Check out IKD.  Ktrace is wonderful for making such unknowns visible.
> 
>   -Mike
> 

OKay. I will do. Thanks.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

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


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

Re: [PATCH] Re: kernel/printk.c: increasing the buffer size to capture devfsd debug messages.

[Thomas Dodd]

Robert Read wrote:
> 
> On Tue, Feb 20, 2001 at 01:37:16PM -0600, Thomas Dodd wrote:
> > Robert Read wrote:
> > >
> > > On Wed, Feb 21, 2001 at 02:30:08AM +0900, Ishikawa wrote:
> > > >
> > > > Has anyone tried 128K buffer size in kernel/printk.c
> > > > and still have the kernel boot (without
> > > > hard to notice memory corruption problems  and other subtle bugs)?
> > > > Any hints and tips will be appreciated.
> > >
> > > I have used 128k and larger buffer sizes, and I just noticed this
> > > fragment in the RedHat Tux Webserver patch.  It creates a 2MB buffer:
> >
> > I think this should be a config option.
> 
> Ok, here is a simple patch to add a config option, I'm compiling it
> now, so it's not tested yet.  One question: what is the best way to
> force this option to be a power of 2?

Why not just make the config option in Kbytes.
and do:

#define LOG_BUF_LEN (CONFIG_PRINTK_BUF_LEN * 1024)

since the config option has a default option and will
always be defined, is the #ifdef check really needed?

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

[Jens Axboe]

Slightly delayed, but here is loop-5. It's against 2.4.2-pre4, as
testing on 2.4.1-ac19 showed other problems (oom killer would kill
dbench or bash before it could finish...). I'll take a look at ac19
next. Changes since loop-4:

o Make sure loop_thread is up. A mount -o loop could sometimes sneak
  in a request before the helper thread was started. (me)

o Remove all the backing file setup, count on get_file just
  holding a reference to it. (Neil Brown)

o Remove fs/buffer.c:wakeup_bdflush work around. loop doesn't block
  on requests, so it shouldn't be needed.

*.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.2-pre4/loop-5

-- 
Jens Axboe

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

Re: [ANNOUNCE] Adaptive Domain Environment for Operating Systems

[Karim Yaghmour]

I've set up a sourceforge project for Adeos:
http://www.sourceforge.net/projects/adeos

There's also a development mailing list which can be found here:
http://lists.sourceforge.net/lists/listinfo/adeos-devel

There's also some code here:
ftp://ftp.opersys.com/pub/Adeos/Adeos.tgz

Be aware that this code will certainly crash your machine. It
is an attempt to drive Linux into ring-one, but it is not
functionnal. You've been warned.

Feel free to join in the discussion.

Best regards,

Karim Yaghmour

Karim Yaghmour wrote:
> 
> I've put up the following (white) papers out for general discussion:
> -Adaptive Domain Environment for Operating Systems (Adeos)
> -Building a Real-Time Operating System on top of the Adeos
> 
> The first paper discusses the design and implementation of a nano-kernel-
> like facility that may be used to take control away from an unmodified
> running linux on ix86 for further uses including (but not limited to):
> -patch-less kernel debuggers/probers
> -running multiple general purpose OSes on the same hardware,
> -OS development
> -etc.
> 
> As the first item suggests, this may be of interest to some on
> this list as kernel debuggers have been a rather pointy subject...
> 
> The second document discusses a special case usage of Adeos that
> enables a real-time-bound kernel to co-exist with Linux on top of
> Adeos.
> 
> The documents can be found here:
> http://www.opersys.com/adeos/index.html
> 
> I've requested a project entry for Adeos on sourceforge and will
> update the project's home page as soon as everything is set up.
> 
> In the mean time, anyone interested to participate in the project
> or that has pertinent information regarding the implementation, or
> its feasibility or lack of, as described in the Adeos document is
> welcomed to contact me.
> 
> KEEP IN MIND that the documents are only a suggested method of
> doing things designed to stimulate discussion. There isn't one
> line of functionnal code out there (yet).
> 
> Best regards,
> 
> Karim
> 

===
 Karim Yaghmour
   [EMAIL PROTECTED]
  Operating System Consultant
 (Linux kernel, real-time and distributed systems)
===
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: *grin* Windows 2000 & HPC: Scalable, Inexpensive

[Dr. Kelsey Hudson]

On Wed, 14 Feb 2001, Mike Harrold wrote:
> 
> The sad thing is, 3/4 of the page is an outright lie. It isn't
> a first, W2k is not the de facto standard OS, and the TCO is
> significantly higher than any cluster running Linux.

No shit, not to mention that Linux is going to be faster and better suited
to the task.

> It's a sad day when companies can get away with blatant lies
> all in the name of "marketing."

Unfortunately that happens all too often. I'd _LOVE_ to be in a legal
position where I could slap M$ (and any other company that does this, for
that matter) and put them in their place. Feeding off the ignorance in
society is counterproductive.

 Kelsey Hudson   [EMAIL PROTECTED] 
 Software Engineer
 Compendium Technologies, Inc   (619) 725-0771
--- 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Xpert]Video drivers and the kernel

[Pavel Machek]

Hi!

> (Aside, is this because X uses keyboard in raw mode?  would be nice to still
> be able to ctrl-alt-del to rebood from console)  Anyone know about
> using alt-sysrq to restore console?

Alt-SysRq-U,S,B. Should work as long as kernel is alive. It is not completely 
clean shutdown, but will prevent fsck.
Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

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