[PATCH] DocBook Makefile, kernel 2.4.0-test8

[Bob Tanner]

Small patch to fix the DocBook Makefile. 

It looks like videodev.c moved from $(TOPDIR)/drivers/char/videodev.c to
$(TOPDIR)/drivers/media/video/videodev.c 

kernel-2.4.0-test8
-- 
Bob Tanner <[EMAIL PROTECTED]>   | Phone : (612)943-8700
http://www.mn-linux.org | Fax   : (612)943-8500
Key fingerprint =  6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 



--- linux-2.4.0-test8/Documentation/DocBook/MakefileSat Aug 12 16:25:54 2000
+++ linux/Documentation/DocBook/MakefileWed Sep 13 00:43:10 2000
@@ -55,11 +55,11 @@
$(TOPDIR)/scripts/docgen $(TOPDIR)/arch/i386/kernel/mca.c \
mcabook.sgml
 
-videobook.sgml: videobook.tmpl $(TOPDIR)/drivers/char/videodev.c
-   $(TOPDIR)/scripts/docgen $(TOPDIR)/drivers/char/videodev.c \
+videobook.sgml: videobook.tmpl $(TOPDIR)/drivers/media/video/videodev.c
+   $(TOPDIR)/scripts/docgen $(TOPDIR)/drivers/media/video/videodev.c \
videobook.sgml
 
-APISOURCES :=  $(TOPDIR)/drivers/char/videodev.c \
+APISOURCES :=  $(TOPDIR)/drivers/media/video/videodev.c \
$(TOPDIR)/arch/i386/kernel/mca.c \
$(TOPDIR)/arch/i386/kernel/mtrr.c \
$(TOPDIR)/drivers/char/misc.c \


Small patch to fix the DocBook Makefile.

It looks like videodev.c moved from $(TOPDIR)/drivers/char/videodev.c to
$(TOPDIR)/drivers/media/video/videodev.c

kernel-2.4.0-test8

Bob Tanner <[EMAIL PROTECTED]

Re: byte order of IDE identify data on ppc, sparc etc

[Andre Hedrick]

Hi Andries,

I truly understand the pain, with my new PPC that was a gift from a PPC
user that want ATA native and strong it is a mess.  I am fearing the task
that you are wanting to chase, but if you can streamline it and it works
:-), you know that you have me backing the change.

Cheers,

Andre Hedrick
The Linux ATA/IDE guy

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

Update Linux 2.4 Status/TODO list

[tytso]

OK, here's the updated Linux 2.4 bug list.  I let myself get a bit
behind, so it took me a while to process through all of my backlogged
l-k mail archives to assemble this list.  As always, it's complete as I
can make it, but it's not perfect.  In particualar, some bugs listed on
this page may have been fixed already.  If so, or if you know some bug
that didn't make on to this list, please let me know.

For people who are wondering what changed, the differences from the last
major release of this page can be found at 

http://linux24.sourceforge.net/status-changes.html

As always, if you're curious what state this document is in, you can
always get the latest copy by going to:

http://linux24.sourceforge.net

- Ted

 Linux 2.4 Status/TODO Page

   Last modified: [tytso:2913.0151EDT]

   Hopefully up to date as of: test8

1. Should Be Fixed (Confirmation Wanted)

 * Fbcon races (cursor problems when running continual streaming
   output mixed with printk + races when switching from X while doing
   continuous rapid printing --- Alan)

2. Capable Of Corrupting Your FS/data

 * Use PCI DMA by default in IDE is unsafe (must not do so on via
   VPx, x < 3) (requires chipset tuning to be enabled according to
   Andre Hedrick --- we need to turn this on by default -- TYT)
 * Fix the OOPS in usb-storage from the error-recovery handler.
   (reported by Matthew Dharm)
 * Non-atomic page-map operations can cause loss of dirty bit on
   pages (sct, alan)

3. Security

 * Fix module remove race bug (still to be done: TTY, ldisc, I2C,
   video_device - Al Viro) (Rogier Wolff will handle ATM)

4. Boot Time Failures

 * Use PCI DMA 'lost interrupt' problem with some hw [which ?] (NEC
   Versa LX with PIIX tuning)
 * HT6560/UMC8672 ide sets up stuff too early (before region stuff
   can be done)
 * Crashes on boot on some Compaqs ? (may be fixed)
 * Boot hangs on a range of Dell docking stations (Latitude)
  + Almost certainly related: PCI code doesn't see devices behind
DECchip 21150 PCI bridges (used in Dell Latitude). Reported
by Simon Trimmer . (Patch from Martin Mares exists but it
disables cardbus devices, according to Tigran.)
  + Derek Fawcus at Cisco reports similar problems with Toshiba
Tecra 8000 attached to the DeskStation V+ docking station.
(once again, caused by bridge returning 0 when reading the
I/O base/limit and Memory base/limit registers which confuses
the new PCI resource code).
 * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for
   more info)

5. Compile errors

 * arcnet/com20020-isa.c doesn't compile, as of 2.4.0-test8. Dan
   Aloni has a fix
 * drivers/sound/cs46xx.c has compile errors test7 and test8 (C
   Sanjayan Rosenmund)

6. In Progress

 * Finish I2O merge (Intel/Alan)
 * Restore O_SYNC functionality (Stephen) - core code and ext2 done
 * Fix all remaining PCI code to use pci_enable_device (mostly done)
 * Fix, um, interesting races around dup2() and friends. (Al Viro)
 * Finish the audit/code review of the code dealing with descriptor
   tables. (Al Viro)
 * DMFE is not SMP safe (Frank Davis patch exists, but hasn't gotten
   much commens yet)
 * Audit all char and block drivers to ensure they are safe with the
   2.3 locking - a lot of them are not especially on the
   read()/write() path. (Frank Davis --- moving slowly; if someone
   wants to help, contact Frank)

7. Obvious Projects For People (well if you have the hardware..)

 * Make syncppp use new ppp code
 * Fix SPX socket code

8. Fix Exists But Isnt Merged

 * Update SGI VisWS to new-style IRQ handling (Ingo)
 * Support MP table above 1Gig (Ingo)
 * Dont panic on boot when meeting HP boxes with wacked APIC table
   numbering (AC)
 * Scheduler bugs in RT (Dimitris)
 * AIC7xxx doesnt work non PCI ? (Doug says OK, new version due
   anyway)
 * Fix boards with different TSC per CPU and kill TSC use on them
 * Floppy last block cache flush error
 * PPC-specific: won't boot on 601 CPU's (powermac) (Andreas Tobler;
   Paul Mackerras has fix in PPC tree)
 * IRDA fixes (patches from Russell King sent to Linus and DAG)
  + IRDA calls get_random_bytes before random is set up 
  + Infinite loop in IrDA parameter code
  + Device name in /proc/net/irda/irias is not updated when
/proc/sys/net/irda/devname is written
  + IrDA Discovery slot allocation is not random
 * Splitting a posix lock causes an infinite loop (Stephen Rothwell)
 * Many network device drivers don't call MOD_INC_USE_COUNT in
   dev->open. (Paul Gortmaker has patches)
 * 2.4.0-test8 has a BUG at ll_rw_blk:711. 

Centralising the duplicated do_profile functions

[Graham Stoney]

Hi gang,

I'd like to submit a patch to Alan which removes the duplication of identical
'do_profile' functions in the 2.2 kernel, and adds the missing call to make
kernel profiling work on the PPC architecture.  Once 2.2 is done, I'll look at
2.4, which currently suffers the same problem, only with more architectures
and hence more duplication :-(.

Could some of you who are still working with the 2.2 kernel please try out the
patch, and verify that kernel profiling (i.e. readprofile) still works for you:
http://members.nbci.com/greyhams/linux/patches/2.2/profile.patch

Please let me know what architecture you're working on.

Thanks,
Graham
-- 
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Mike Galbraith]

On Tue, 12 Sep 2000, Jeff V. Merkey wrote:

> 
> Ted,
> 
> I am looking at these sources as well.  One thing I went back and looked
> at was related to a comment from Mike G. I believe regarding drivers
> conflicts with int 0x13 requests potentially hosing the IDE driver.  In

Hmm.. must be a different Mike G.  (can't be from me.. I don't even know
what conflicts you're refering to:)

-Mike

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

Re: 2.2.18pre* CONFIG_AGP=Y compile problem

[Arjan van de Ven]

In article <[EMAIL PROTECTED]> you wrote:

> Hello !

> There is error during "make bzImage" 2.2.18pre(3,4,5) with CONFIG_AGP=Y.
> I have it on both Slackware 7.0 and 7.1.
> Error message follows.

[snip]
> init/main.o: In function `do_basic_setup':
> init/main.o(.text.init+0xe02): undefined reference to `agp_initialize'
> init/main.o(.data.init+0x144): undefined reference to `agp_setup'
> make: *** [vmlinux] Error 1

Could you try the patch below?

Greetings,
  Arjan van de Ven

--- /mnt/raid/1/2.2/linux-2.2.18p6/init/main.c  Tue Sep 12 21:11:23 2000
+++ linux/init/main.c   Tue Sep 12 21:43:34 2000
@@ -401,8 +401,7 @@
 #endif
 
 #ifdef CONFIG_AGP
-extern int agp_initialize (void);
-extern void agp_setup(char *str, int *ints);
+extern int agp_init (void);
 #endif
 
 /*
@@ -1059,9 +1058,6 @@
 #ifdef CONFIG_BLK_CPQ_DA
{ "smart2=", cpqarray_setup },
 #endif
-#ifdef CONFIG_AGP
-   { "agp_try_unsupported=", agp_setup},
-#endif
{ 0, 0 }
 };
 
@@ -1559,7 +1555,7 @@
nubus_init();
 #endif
 #ifdef CONFIG_AGP
-   agp_initialize ();
+   agp_init();
 #endif
 
/* Networking initialization needs a process context */ 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Bug in block device read/write!

[tytso]

   Date:Fri, 08 Sep 2000 03:41:27 +0100
   From: Anton Altaparmakov <[EMAIL PROTECTED]>

   I have been trying to get the linear md driver to work with NTFS volumes 
   for several months and it never worked. - I was suspecting the NTFS driver 
   (after having fixed linear md and verified that at least that worked fine) 
   but today I finally found why it doesn't work:

   There is a bug in reading/writing to block devices. - It manifests itself 
   in the form that partitions are too small by exactly one sector!

   Even though a cfdisk shows that a partition has a certain number of 
   sectors, you can never seek + read and/or write to the last sector (doing 
   file i/o using read/write(2) [also tried fread/fwrite(3), same result]. - 
   Last sector doesn't seem to exist. However reading the actual hd (/dev/hdb 
   or /dev/sda, ie. affects both IDE and SCSI) instead of the partition 
   (/dev/hdb7 or whatever) the sector does exist and contains the expected 
   information!

This isn't a bug.  The last sector is used by the md device to store the
md superblock.  

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

Re: Signal handling different for root and others

[Dan Kegel]

jury gerold <[EMAIL PROTECTED]> wrote:
> When i create a connection (telnet a.b.c.d port) the signal is 
> delivered depending  on the user that does the telnet. 
> If root creates the socket, then only root or another machine 
> is able to trigger the signal by connecting to the socket. 
> Normal users are only able to create a SIGIO signal when connecting. 
> 
> If a normal user runs the program, then any user, as well as root 
> is able to trigger the realtime signal.  No SIGIO is delivered. 
[ minimal test program snipped ]

Didn't look at the program too closely, but I ran it on vanilla 2.2.16,
and reproduced the problem.  I'm not sure F_SETSIG and friends
are supposed to work properly on 2.2.x, though; isn't 2.4.x when
they're supposed to be fully functional?
(cf. http://www.kegel.com/c10k.html#nb.sigio )

It's wierd - for some reason, if the client is on the
same machine as the server, the server's behavior really
differs based on whether the client is root or not.

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

Re: Booting into /bin/bash

[Ion Badulescu]

In article <[EMAIL PROTECTED]> you wrote:

> I like this idea a lot (the latter - making /dev/console controlling
> tty).  On an old SunOS 4 machine I once worked with, a Ctrl-C during the
> execution of rc.sysinit would sent it terminate signals.  So when the
> NFS was hanging on mount because of a f***ed up network (or changed ip
> address of server) you could hit ctrl-c during the rc script and the
> mount would be sent the ctrl-c and would terminate, then the rest of the
> rc script would continue (regular shell script behavior if I'm not
> mistaken).

If you look at the sysvinit code, you'll see that rc.sysinit does get
a controlling tty, but the init code blocks all "user" signal (such as
SIGINT) before executing it. I assume this is done to prevent some
security problems, though I question its utility -- it's certainly
useful to ctrl-c out of a screwed up rc.sysinit, and the script can
block those signals itself if it wishes to.


Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18pre4

[Ion Badulescu]

In article 8pmnfc$6p1$[EMAIL PROTECTED]> you wrote:

> Think Alan has made that clear.  The way I read things the nfsv2 stuff needs
> to be split out, into sets of small independent patches.  This lets Alan 
> audit and control any bad patches easily.  The nfsv3 changes should not 
> effect anything unless they are selected in the kernel build.
> 
> Comments?

Are you volunteering to do it? No? I thought so.

Personally, I'd rather let Trond spend his precious little spare time on
useful things like improving the code and fixing whatever problems are
left, then have him waste it on such a useless thing. If this means we
have to keep patching each 2.2 release in order to get usable NFS,
so be it.

And, just to make things clear: Alan has *never* said what you imply.
It was Jeff Garzik's suggestion.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

byte order of IDE identify data on ppc, sparc etc

[Andries Brouwer]

While designing some disk utilities, I found it rather
inconvenient that what the kernel gives back with the
HDIO_GET_IDENTITY ioctl differs in obscure architecture-
dependent ways from what one reads directly from disk.

Looking at the kernel code, I find 26kB of byteswapping
source code just for IDE identify data.

If I am not mistaken one can save 25kB by using
a single boolean that describes whether the
disk controller stores the data (256 shorts)
with high or with low order byte first.

Maybe for all architectures this is low order byte first,
and if this is true we can declare hd_driveid as
unsigned char [512], and no architecture-dependent
byteswapping is required anymore.

(Provided that one picks up the values in a decent way,
not by typecasting, but just by computing p[0]+(p[1]<<8).)

I write this mainly in the hope to get some feedback
from ppc people. The current code is very messy, with
separate per-model identify_drive_data_byteswap routines.
Moreover, I believe that the current code is broken
(where the current struct hd_driveid has chars).
Who wrote this code? Is there a special reason
for these complications?

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

Re: 2.2 Backport Terminated ...

[Mike Castle]

On Tue, Sep 12, 2000 at 04:31:07PM -0700, Andre Hedrick wrote:
> Do to limits in personal bandwidth and other projects that need to get
> done, I can no longer keep up the back port of the ATA code.

Bummer.

The 2.2.17 ide code doesn't work for me.

I used to use 2.2.15pre15 with ide.  With 2.2.17+ide, I have problems.
2.2.17 standard works however (if a little slower, I think).

I haven't had time to work out all of the specifics, but this is what I
saw.

The motherboard I'm using is a Spacewalker/Shuttle HOT-557 v1.5 with
latest BIOS.  This motherboard is 430VX chipset based (not the best, but
hey, it was free).  I've also just recently added an old SoundBlaster AWE32
as a 3rd ide to throw on an old cdrom and another harddrive:

I'm currently running 2.2.17+raid, though not using the raid yet (just
starting to play with it, which is why the upgrade from 2.2.15pre15 to
2.2.17 anyway).  So the follow collections of information (dmesg output and
find /proc/pci -type f | xargs pr) is for both 2.2.17+raid and
2.2.17+ide+raid.  If need it without raid, I can do it.  Just will take a
while.

===
Linux version 2.2.17raid (root@thune) (gcc version 2.95.2 19991024 (release)) #4 Wed 
Sep 6 13:56:49 CDT 2000
Detected 233226 kHz processor.
Console: colour VGA+ 80x28
Calibrating delay loop... 465.31 BogoMIPS
Memory: 79668k/81920k available (760k kernel code, 412k reserved, 1028k data, 52k init)
Dentry hash table entries: 16384 (order 5, 128k)
Buffer cache hash table entries: 131072 (order 7, 512k)
Page cache hash table entries: 32768 (order 5, 128k)
CPU: Intel Pentium MMX stepping 03
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
Checking for popad bug... OK.
Intel Pentium with F0 0F bug - workaround enabled.
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfb000
PCI: Using configuration type 1
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 131072 bhash 65536)
Initializing RT netlink socket
Starting kswapd v 1.5 
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Real Time Clock Driver v1.09
PIIX3: IDE controller on PCI bus 00 dev 39
PIIX3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
hda: Maxtor 91303D6, ATA DISK drive
hdb: Maxtor 53073U6, ATA DISK drive
hdc: Maxtor 93652U8, ATA DISK drive
hdd: Maxtor 92048U8, ATA DISK drive
hdg: probing with STATUS(0x00) instead of ALTSTATUS(0x80)
hdg: HITACHI CDR-7930, ATAPI CDROM drive
hdh: probing with STATUS(0x50) instead of ALTSTATUS(0xd0)
hdh: Maxtor 53073H6, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide3 at 0x168-0x16f,0x36e on irq 10
hda: Maxtor 91303D6, 12427MB w/512kB Cache, CHS=12624/32/63, (U)DMA
hdb: Maxtor 53073U6, 29311MB w/2048kB Cache, CHS=59554/16/63, (U)DMA
hdc: Maxtor 93652U8, 34837MB w/2048kB Cache, CHS=4441/255/63, (U)DMA
hdd: Maxtor 92048U8, 19470MB w/2048kB Cache, CHS=39560/16/63, (U)DMA
hdh: Maxtor 53073H6, 29311MB w/2048kB Cache, CHS=59554/16/63
md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12
raid5: measuring checksumming speed
raid5: MMX detected, trying high-speed MMX checksum routines
   pII_mmx   :   342.900 MB/sec
   p5_mmx:   393.573 MB/sec
   8regs :   244.602 MB/sec
   32regs:   195.453 MB/sec
using fastest function: p5_mmx (393.573 MB/sec)
md.c: sizeof(mdp_super_t) = 4096
Partition check:
 hda: hda1 hda2 hda3 hda4
 hdb: hdb1 hdb2 hdb3
 hdc: hdc1 hdc2 hdc3
 hdd: hdd1 hdd2 hdd3 hdd4
 hdh: hdh1 hdh2 hdh3
autodetecting RAID arrays
autorun ...
... autorun DONE.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 52k freed
NET4: Unix domain sockets 1.0 for Linux NET4.0.
Adding Swap: 66016k swap-space (priority 1)
Adding Swap: 131504k swap-space (priority 1)
Adding Swap: 65988k swap-space (priority 1)
hdc: timeout waiting for DMA
hdc: irq timeout: status=0xd0 { Busy }
hdc: DMA disabled
hdd: DMA disabled
ide1: reset: success
hdb: timeout waiting for DMA
hdb: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hda: status timeout: status=0xd0 { Busy }
hda: DMA disabled
hdb: DMA disabled
hda: drive not ready for command
ide0: reset: success
(read) hdh3's sb offset: 131456 [events: ]
md: invalid raid superblock magic on hdh3
md: hdh3 has invalid sb, not importing!
could not import hdh3!
autostart hdh3 failed!
tulip.c:v0.91g-ppc 7/16/99 [EMAIL PROTECTED]
eth0: Lite-On 82c168 PNIC rev 32 at 0x6400, 00:A0:CC:26:67:40, IRQ 11.
eth0:  MII transceiver #1 config 3100 status 7829 advertising 01e1.
eth1: Lite-On PNIC-II rev 37 at 0x6800, 00:A0:CC:E4:8C:F6, IRQ 12.
Serial driver version 4.27 with no serial options enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 

Re: Linux 2.2.18pre4

[Ed Tomlinson]

Horst von Brand wrote:

> OK, OK, OK. It is by now abundantly clear that NFSv3 is a high-priority
> item for lots of people out there. But just complaining about it not being
> in the kernel just generates ill will.

Think Alan has made that clear.  The way I read things the nfsv2 stuff needs
to be split out, into sets of small independent patches.  This lets Alan 
audit and control any bad patches easily.  The nfsv3 changes should not 
effect anything unless they are selected in the kernel build.

Comments?

Ed Tomlinson <[EMAIL PROTECTED]>

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

Re: Linux 2.2.18pre4

[Horst von Brand]

Alan Cox <[EMAIL PROTECTED]> said:
> Subject: Re: Linux 2.2.18pre4
> 
> Return-Path: [EMAIL PROTECTED]
> Delivery-Date: Tue Sep 12 20:33:05 2000
> Return-Path: <[EMAIL PROTECTED]>
> In-Reply-To: <[EMAIL PROTECTED]> from "Paul 
>  ***Jakma" at Sep 12, 2000 05:12:33 PM
> > What are the issues with updating NFS code that do not exist with
> > other drivers, filesystems, etc... in 2.2 for which updates are
> > accepted?

> They exist in the same way. You update stuff in controlled careful steps
> and you change troublesome drivers very early in a patch release - eg
> never touching tulip except early on

So it could be in 2.2.19? Anything interested parties could/should do to
help?
-- 
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile   +56 32 672616



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

Re: Booting into /bin/bash

[Ion Badulescu]

On Tue, 12 Sep 2000, Ion Badulescu wrote:

> Maybe I'll play with main.c and see what happens if I force /dev/console
> to become the controlling tty for init. Hmm... That could be dangerous for
> init. Maybe a better idea would be to hack init so that it gives any
> program started from inittab /dev/console as the controlling tty.
> 
> You're the sysvinit maintainer, right? :) What do you think of this idea?

... and init already does the above. :-) Except for one case: the
emergency shell doesn't get a controlling tty. The first mini-patch below
takes care of that problem.

This still doesn't solve the original problem, i.e. init (or whatever you
pass as init) still doesn't get a controlling tty from the kernel.
However, since init appears to be safe from these issues, it it fairly
trivial to fix this in the kernel; the second patch below takes care of
it. The patch is against 2.2.17 but will apply against pretty much any 2.2
and 2.4 kernel. It's is for i386 only, but the fixup for other
architectures is extremely obvious.


Ion

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


--- sysvinit-2.78/src/init.c.orig   Tue Sep 12 04:31:47 2000
+++ sysvinit-2.78/src/init.cTue Sep 12 04:15:10 2000
@@ -88,7 +88,7 @@
 CHILD *newFamily = NULL;   /* The list after inittab re-read */
 
 CHILD ch_emerg = { /* Emergency shell */
-  0, 0, 0, 0, 0,
+  WAITING, 0, 0, 0, 0,
   "~~",
   "S",
   3,


--- tmp/linux-2.2.17/include/asm-i386/unistd.h  Wed Jan 20 11:06:24 1999
+++ linux-2.2.17/include/asm-i386/unistd.h  Tue Sep 12 17:56:07 2000
@@ -301,6 +301,7 @@
 static inline _syscall1(int,_exit,int,exitcode)
 static inline _syscall3(pid_t,waitpid,pid_t,pid,int *,wait_stat,int,options)
 static inline _syscall1(int,delete_module,const char *,name)
+static inline _syscall3(int,ioctl,int,d,int,request,long,argp)
 
 static inline pid_t wait(int * wait_stat)
 {
--- tmp/linux-2.2.17/init/main.cWed Sep  6 12:40:14 2000
+++ linux-2.2.17/init/main.cTue Sep 12 18:44:02 2000
@@ -1607,6 +1604,7 @@
 static int init(void * unused)
 {
lock_kernel();
+   setsid();
do_basic_setup();
 
/*
@@ -1622,7 +1620,9 @@
 
(void) dup(0);
(void) dup(0);
-   
+   if (ioctl(0, TIOCSCTTY, 1) < 0)
+   printk("Error while establishing a controlling tty.\n");
+
/*
 * We try each of these until one succeeds.
 *

Question about Bind Souce Code

[Pan Renzi]

Hi,all:
    I was confused when I read Bind Source 
Code(9.0.0rc5).
    It was in lib/isc/include/isc/types.h,line 
62,said like below:
    "typedef struct isc_mem 
isc_mem_t;"
 but I cant find any information about 
"struct isc_mem" anywhere,What's wrong?Is there anyone could give me some 
idea?
    Best Regard.
    
    
    

Re: elevator code

[Martin Dalecki]

"Jeff V. Merkey" wrote:
> 
> Martin,
> 
> I'm glad you are not still mad at me. :-)  I hope this info was
> helpful.

Yes it was in fact this one of the more interresting posts in this
thread. Thanks for the excellent reading. (However much of it
sounded very familiar... maybe they learned the same lessons at Sun or
Berkeley? ;-)

The most important fact is that there is no misconception of blocks like
there is currently under Linux. Linux is basically using FOUR different
block 
concepts in case of the block device handling:

1. Filesystem iduced blocks.
2. physical block size.
3. buffer block size.

Where in fact there should be only two:

1. FS block
2. physical block size.

Merging 2. and 3. should be handled on the driver level.
Interrestingliy enough the driver writers do it "intuitively"
very freqeuntly indeed (ATAPI cd or mcdx for example). However they get
beaten by the fact that sometimes the dividing
line even between 1. and 2. isn't clean unter linux ;-)... insead of
just
basing anything on a basic buffer block size like 512 bytes.

Interrestingly there is the same overgranulation in the concept of
read-ahead under linux:

1. VFS read write - ahead.
1b. FS specific read write ahead.
2. Driver read write -ahead.
3. Physical device cache read write -ahead.

Once again at least one point too much and then you could see
the elevator as even just

4. some kind of wired variable block write/read-ahead...

In fact most of the read aheads above are just foo due to the fact
that the one enumerated as 3. is aleviating them.

However due to "code impedancy", in esp. driver code impedancy I doubt
seriously this will get ever cleaned up.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Test 8 Kernel Unable to get the password prompt?

[Gerhard Mack]

That's not correct .. the latest until-linux does not appear to fix the
problem and there seems to be the same problem with PAM.

Gerhard


On Tue, 12 Sep 2000, Steven Walter wrote:

> 
> If you're logging in as root, this is probably a result of the VT not
> being named in /etc/securetty.  Devfsd mucks up the names, so you can
> either include "1," which would allow root logins from pseudo-terminals
> and other insecure places, or upgrade your util-linux to a newer
> version; I'm not sure what is new enough. 
> 
> On Mon, Sep 11, 2000 at 09:32:37PM -0700, Miles Lane wrote:
> > 
> > 
> > On Mon, 11 Sep 2000, David Freedom wrote:
> > 
> > > I tried configuring the kernel to the least amount of
> > > configured options to almost none and I still cannot
> > > get the password prompt.
> > > 
> > > My system hangs and is unable to do anything. 
> > > unfortunetly the only thing I can do is power down my
> > > PC the incorrect and most unfortunate way leading to
> > > filesys errors upon reboot to an older saved kernel
> > > image.
> > 
> > Are you getting both the username and password prompts
> > and then getting nothing after entering the password?
> > This is a behavior I am seeing on a laptop Pentium II.
> > In my case, I can CTRL-ALT-F[1-6] to get to another
> > VT.  All attempts to log in any VT display meet the same
> > fate.  Also, attempting to log in using GDM fail in
> > this way.  In my case, the UI GDM continues to respond.
> > 
> > Lastly, trying to CTRL-ALT-DEL to initiate a shutdown
> > does cause the TERM and KILL signals to be sent to
> > all processes.  Then the shutdown process locks up
> > after a message is printed about unloading the 
> > keyboard driver.
> > 
> > Interestingly, if I boot in single mode ("linux single"
> > at the boot prompt), and then load GDM, I am able to 
> > log on with no trouble.
> > 
> > I have sent a message to the maintainer of the 
> > shadow-utils package, but have gotten no response.
> > 
> > I suspect this problem has to do with a fsck-up on
> > my part in getting util-linux configured properly when
> > I built it.  I rebuilt util-linux with the sources
> > pointed to by Changes several development kernel 
> > revisions ago (~2.4.0-test7).
> > 
> > Miles
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > Please read the FAQ at http://www.tux.org/lkml/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

--
Gerhard Mack

[EMAIL PROTECTED]

<>< As a computer I find your faith in technology amusing.

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

Re: [ANNOUNCE] Darkstar Development Project

[Keith Owens]

CC: trimmed to just l-k.

On Tue, 12 Sep 2000 10:02:59 +0200, 
Ralf Baechle <[EMAIL PROTECTED]> wrote:
>From some random Linux source tree's .hdepend:
>
>/usr/people/ralf/src/linux/linux/include/asm/sn/sn0/ip27.h: \
>   /usr/people/ralf/src/linux/linux/include/asm/mipsregs.h \
>   /usr/people/ralf/src/linux/linux/include/asm/sn/addrs.h
>@touch /usr/people/ralf/src/linux/linux/include/asm/sn/sn0/ip27.h
>[...]
>
>Linux, born to be CVS worst case ...

FWIW, this will be fixed by the Makefile redesign for 2.5.  The kernel
source tree will become read only (for various reasons) so nothing will
touch .h files anymore.

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

Re: Using Yarrow in /dev/random

[Theodore Y. Ts'o]

   Date:Wed, 13 Sep 2000 01:23:30 +0200 (CEST)
   From: Igmar Palsenberg <[EMAIL PROTECTED]>

   > No, not true.  The mixing into the entropy pool uses a twisted LFSR, but
   > all outputs from the pool (to either /dev/random or /dev/urandom)
   > filters the output through SHA-1 as a whitener.  The key here, though,
   > and what makes this fundamentally different from yarrow, is that since
   > we're feeding the entire (large) entropy pool through SHA-1, even if the
   > SHA-1 algorithm is very badly broken (say as in what's been happening
   > with MD5), as long as there's sufficient entropy in the pool, the
   > adversary can define but minimal information about the pool, since the
   > 8192 -> 160 bit transform has to lose information by definition.

   Broken ?? Please explain.

This is old news.  Hans Dobbertin, in about 10 hours of CPU time on a
Pentium system, can generate hash collions in MD5.  This is not
something which you're supposed to be able to do with crypto checksums,
so effectively MD5 is "broken", and shouldn't be used in new
applications where a crypto checksum is required.  His break is probably
not exploitable for existing uses of MD5, so some people might claim
that MD5 hasn't been "broken" yet, but merely severly bent.  At some
level this is just a matter of semantics.

Regardless, the use of MD5 for new protocols/applications is not
recommend.

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

Re: Reorg raid5 block xor routines

[Richard Henderson]

On Wed, Sep 13, 2000 at 12:26:39AM +0100, Russell King wrote:
> If its 15K, and you're compiling raid as modules, why can't this code
> also be compiled as a module in the architecture tree?  Last time I
> looked, modprobe handled dependencies between modules.

With the code as-is, you'd have half the module would be under
arch/foo/lib/ and the other half in drivers/block/xor.c.  I can't
think of a non-fragile way to create a composite module from objects
in two different directories.

This implies that we either need to give up on sharing the code
in xor.c (bad) or use multiple modules (ok).  Now, modprobe cannot,
to my knowledge, handle circular dependancies, and even if it could
relying on such would be bad design.  So we need to have some straight
line ordering from raid5.o -> xor.o -> xor_alpha.o
or raid5.o -> xor_alpha.o -> xor.o.

By itself, this isn't too bad.  One solution is to have xor.o depend
on a definition for `xor_active_template' which it gets from xor_alpha.o,
which contains the set of routines to use.  The only questionable part
is that constructor for xor_alpha.o needs to call back into xor.o to
figure out which routine is fastest.

But what to do about ports that don't define custom xor routines?
The obvious place to put this sort of thing is in lib/, but we've
never built modules out of there before.  And even if we did, we'd
have to prevent them from being built on systems that do define
their own xor routines, since the module dependancy scheme requires
that only one module satisfy the request for xor_active_template.
Further, i386 defines custom xor routines that can only be used on
late model hardware; if you're running on a 486, you fall back to
the generic routines.  So we can't really leave the generic bits
out, but have to figure out how to get them built differently on
different architectures (without and without defining xor_active_template).

So the only way I can think to get things built without massive code
replication is to #include xor.c code into arch/foo/lib/xor_foo.c.
Any arch that does not implement custom xor routines will have to have
an entry in its arch/foo/lib/Makefile to build a module from source
living in lib/.  I'm not fond of this notion.



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

Re: 2.2 Backport Terminated ...

[Bartlomiej Zolnierkiewicz]

I will maintain 2.2 backport on (maybe) regular basis...

On Tue, 12 Sep 2000, Andre Hedrick wrote:
>
> Greetings All,
>
> Do to limits in personal bandwidth and other projects that need to get
> done, I can no longer keep up the back port of the ATA code.
>
> Things that are before me are :
>
>   Finish Stablity of 2.4.0
>   Finish CASCADE for 2.4.0 and introduction @ ALS
>   8 drives per channel, or 16 drives per card.
>   Finish ORBS Castlewood for 2.4.0
>   Finish ARCO-IDE RAID for 2.4.0
>   Finish ONION-BUG fix without TASKFILE IOCTL for 2.4.0
>   Parse 48-bit LBA for 2.4.0/2.5.0
>
>   Finish TASKFILE for 2.5.0
>   Prep for SerialATA SuperSets for 2.5.0
>
>   Finish Drive Certification Model and test Suite.
>
>   Stop pissing Linus off on a regular basis ;-)
>
> Cheers,
>
> Andre Hedrick
> The Linux ATA/IDE guy
>
> PS.  If you do not get a reply or a late one you now know why.
> PS.  If BKZ is up to it, he will begin to handle the back-ports again.
>

Andre, are you going to modularize UDMA drivers for 2.5 ?

--
Bartlomiej Zolnierkiewicz
<[EMAIL PROTECTED]>

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

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Mitchell Blank Jr]

Alan Cox wrote:
> > time, but remember that there are two things measured in time here:
> >   A. The time for the whole queue of requests to run (this is what Rik is
> >  proposing using to throttle)
> >   B. The time an average request takes to process.
> 
> Your perceived latency is based entirely on A.

Yes, but "how hard is it reasonable for the kernel to try" is based on
both items.  A good first order approximation is number of requests.

> > If we limit on the depth of queue we're (to some level of approximation)
> > making our decision based on A/B.  It's still a magic constant, but at
> 
> I dont suggest you do queue limiting on that basis. I suggest you do order
> limiting based on time slots

It's still a queue - the queue of things we're going to take on this
elevator swipe, right?  And the problem is one of keeping a sane
watermark on this queue - not too many requests to destroy latency
but enough to let the elevator do some good.

> > Well, actually just about any communications protocol worth its salt
> > uses some sort of windowing throttle based on the amount of data
> 
> Im talking about flow control/traffic shaping

...where the user sets a number exlpicitly for what performance they
want.  Again, if we're going to make the user set this latency
variable for each of their devices, then doing it based on time will
work great.

> > There's too many orders of magnatude difference between even just SCSI
> > disks (10 yr old drive?  16-way RAID?  Solid state?) to make
> > supplying any sort of default with the kernel impractical.  The end
> 
> The same argument is equally valid for the current scheme, and I think you'll
> find equally bogus

There will always need to be tunables - and it's fine to say "if you've
got oddball hardware and/or workload and/or requirements then you should
twiddle this knob".  But it seems to me that the current scheme works
well for a pretty big range of devices.  If you do the setting based
on time, I think it'll be a lot more sensitive since there's nothing
that will scale based on the speed of the device.

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

Re: elevator code

[Jeff V. Merkey]

Martin,

I'm glad you are not still mad at me. :-)  I hope this info was
helpful.  

:-)

Jeff

Martin Dalecki wrote:
> 
> "Jeff V. Merkey" wrote:
> 
> > lessons learned in live customer accounts.  In NetWare, requests are
> > merged at A) the boundry between the File Cache and the I/O subsystem,
> > and B) in the drivers themselves and NOT THE ELEVATOR.
> 
> Yes that's the proper place to do this. The generic elevator on a
> *single* queue
> makes not much sense. Once ago I have just disabled it entierly and on a
> system with swap on a separate disk and controller this was a
> performance *win*.
> 
> Some of the FS code in esp. the ISO9660 does even under linux something
> *very*
> much like this. Many of the prop. cd-rom device drivers are basically
> emulating 512k block devices by reading ahead and throwing away data.
> There is really plenty of room for improvement here.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Martin Dalecki]

Hans Reiser wrote:
> 
> I really think Rik has it right here.  In particular, an MP3 player needs to be able 
>to say, I have
> X milliseconds of buffer so make my worst case latency X milliseconds.  The number 
>of requests is
> the wrong metric, because the time required per request depends on disk geometry, 
>disk caching, etc.
> 

No the problem is that an application should either: 

1. Take full controll of the underlying system.
2. Don't care about selftuning the OS.

Becouse that's what operating systems are for in first place: Letting
the
applications run without care of the underlying hardware.

Linux is just mistaken by desing that there should be a generic elevator
for any block device sitting on a single queue for any kind of attached
device. Only device drivers know best how to handle queueing and stuff
like
this. The upper layers should only car about semanticall correctness of
the
request orders not about optimization of them.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Alan Cox]

> time, but remember that there are two things measured in time here:
>   A. The time for the whole queue of requests to run (this is what Rik is
>  proposing using to throttle)
>   B. The time an average request takes to process.

Your perceived latency is based entirely on A.

> If we limit on the depth of queue we're (to some level of approximation)
> making our decision based on A/B.  It's still a magic constant, but at

I dont suggest you do queue limiting on that basis. I suggest you do order
limiting based on time slots

> Well, actually just about any communications protocol worth its salt
> uses some sort of windowing throttle based on the amount of data

Im talking about flow control/traffic shaping

> If we move to a "length of queue in time" as Rik suggests then we're
> going to have to MAKE the user set it manually for each device.

No

> There's too many orders of magnatude difference between even just SCSI
> disks (10 yr old drive?  16-way RAID?  Solid state?) to make
> supplying any sort of default with the kernel impractical.  The end

The same argument is equally valid for the current scheme, and I think you'll
find equally bogus

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

Re: elevator code

[Martin Dalecki]

"Jeff V. Merkey" wrote:
 
> lessons learned in live customer accounts.  In NetWare, requests are
> merged at A) the boundry between the File Cache and the I/O subsystem,
> and B) in the drivers themselves and NOT THE ELEVATOR.

Yes that's the proper place to do this. The generic elevator on a
*single* queue
makes not much sense. Once ago I have just disabled it entierly and on a
system with swap on a separate disk and controller this was a
performance *win*.

Some of the FS code in esp. the ISO9660 does even under linux something
*very*
much like this. Many of the prop. cd-rom device drivers are basically
emulating 512k block devices by reading ahead and throwing away data.
There is really plenty of room for improvement here.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18pre6

[Tom Leete]

Alan Cox wrote:
>
[AH>>]
> > larger ide-patch.  What is it going to take to just accept it?
> 
> I'd prefer to do it bit by bit, driver by driver without touching the core
> and picking the important and stable drivers first.

On one machine, I have applied ide-2.2.17.all.2904.patch
just to get the core effect of CONFIG_IDEDISK_MULTI_MODE=y
in drivers/block/ide-disk.c.

I can't use any of the specific ide drivers, but it is very
good to be free of hda lost interrupt followed by system
death. Record uptime for that machine in 2.2.x is about 40
hours.

Andre, I'd be glad to extract that portion if there is a
chance it will be accepted.

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

2.2.18pre6

[Bob Lorenzini]

Alan I don't know if you received my message about ATI Mach64/FB but
if not 2.2.17pre14 was the last working kernel for me. FYI only, I can
live with pre14. :-)

Bob

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

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Mitchell Blank Jr]

Alan Cox wrote:
> > Now, I see people trying to introduce the concept of elapsed time into
> > that fix, which smells strongly of hack. How will this hack be cobbled
> 
> Actually my brain says that elapsed time based scheduling is the right thing
> to do.

No, Andrea is right here.  The argument that everyone is using ("Our target -
latency - is measured in time") is utterly bogus.  Yes, it's measured in
time, but remember that there are two things measured in time here:
  A. The time for the whole queue of requests to run (this is what Rik is
 proposing using to throttle)
  B. The time an average request takes to process.

If we limit on the depth of queue we're (to some level of approximation)
making our decision based on A/B.  It's still a magic constant, but at
least it's scaled to take into account the speed of the drive.  And
underneath, it's still based on time.

> It certainly works for networks

Well, actually just about any communications protocol worth its salt
uses some sort of windowing throttle based on the amount of data
outstanding, not the length of time it's been in the queue.  Which
is why TCP works well over both GigE and 28.8. [*]  Now substitute
"big fiberchannel RAID" for GigE and "360K floppy" for 28.8 and
you've got the same problem.

*  -- Yes, for optimal TCP over big WAN pipes you may want to use a
  larger buffer size, but that's a matter of the bandwidth
  delay product, which isn't relavent for talking about storage

If we move to a "length of queue in time" as Rik suggests then we're
going to have to MAKE the user set it manually for each device.
There's too many orders of magnatude difference between even just SCSI
disks (10 yr old drive?  16-way RAID?  Solid state?) to make
supplying any sort of default with the kernel impractical.  The end
result might be a bit better behaved, but only just slightly.
If people absolutely need this behavior for some reason, the current
algorithm should stay as the default.

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

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Martin Dalecki]

Andrea Arcangeli wrote:
> 
> On Tue, 12 Sep 2000, Martin Dalecki wrote:
> 
> >First of all: In the case of the mp3 player and such there is already a
> >fine
> >proper way to give it better chances on getting it's job done smooth -
> >RT kernel sceduler priorities and proper IO buffering. I did something
> >similiar
> >to a GDI printer driver...
> 
> Take 2.2.15, set a buffer of 128mbyte (of course assume your mp3 is larger
> than 128mbyte :) and then run in background `cp /dev/zero .` in the same
> fs where your mp3 file out of cache is living. Then you'll see why a large
> buffer is useless if there's none kind of I/O fair scheduling into the
> elevator. Repeat the same test in 2.2.16 then.
> 
> The I/O latency Hans was taking about for the mp3 player, is the time it
> takes for the buffer to become empty.

I was talking about *proper* buffering not necessary *big* buffers.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.2 Backport Terminated ...

[Andre Hedrick]

Greetings All,

Do to limits in personal bandwidth and other projects that need to get
done, I can no longer keep up the back port of the ATA code.

Things that are before me are :

Finish Stablity of 2.4.0
Finish CASCADE for 2.4.0 and introduction @ ALS
8 drives per channel, or 16 drives per card.
Finish ORBS Castlewood for 2.4.0
Finish ARCO-IDE RAID for 2.4.0
Finish ONION-BUG fix without TASKFILE IOCTL for 2.4.0
Parse 48-bit LBA for 2.4.0/2.5.0

Finish TASKFILE for 2.5.0
Prep for SerialATA SuperSets for 2.5.0

Finish Drive Certification Model and test Suite.

Stop pissing Linus off on a regular basis ;-)

Cheers,

Andre Hedrick
The Linux ATA/IDE guy

PS.  If you do not get a reply or a late one you now know why.
PS.  If BKZ is up to it, he will begin to handle the back-ports again.

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

Re: 2.4.0-test8 and ssh (OpenSSH_2.1.1): error: socket: Address family not supported by protocol

[Gregory T. Norris]

It looks like this one's a ssh issue.  If you haven't already gotten it
resolved, take a look at ... there's a
patch which should take care of it.

 PGP signature

Re: More on 2.2.18pre2aa2 (summary of elevator ideas)

[Jeff V. Merkey]

One important point on remirroring I did not mention in my post.  In
NetWare, remirroring scans the disk BACKWARDS (n0) to prevent
artificial starvation while remirring is going on.  This was another
optimization we learned the hard way by trying numerous approaches to
the problem.

Jeff

Ed Tomlinson wrote:
> 
> Hi,
> 
> Geez, A simple comment on IRC can _really_ generate lots of feedback.
> (There were over 50 messages about this in my queue - did not help
> that some were duplicated three times ).
> 
> I made the comment because I remember back when the discussion was current
> on linux kernel.  I thought Jeff Merkey's, message was to the point.  Para-
> phrasing from memory, it was something to the effect that novell had
> tried many elevators.  All had problems with some loads.  The best they
> had found was the 'close the door' idea.  I do not remember if the door
> was based on requests or time.  Another point to remember is that the
> netware people came up with a what they considered a good solution.  From
> Jeff's comment they arrived at this solution by experiments and bitter
> experience.  Maybe we can learn something from their research?
> 
> Here is what I glean from the thread:
> 
> >From all the discussion I find this suggestion from Alan to make lots of
> sense.  Think it can be made to work with number of request almost as easily
> as with time...
> 
> >When you do the scan to decide where to insert the entry you dont consider
> >insertion before the time. Also you keep two queue heads the real and the
> >insert head. Whenever you walk from the insert head and find it points to
> >a 'too old' entry you update the insert_head.
> 
> And this suggestion from Rik should counter most of Andrea's time vs requests
> vs slow block devices issues.  We just have to be sure to close the door after
> atleast n request or m time.  However, as pointed out by Chris Evan, later we
> may not have to do this - there are stats that can give a good idea of a
> device's latency.
> 
> >Not really. What about just using something like
> >"half a second, but at least 10 requests liberty to
> >reorder" ?
> 
> >It's simple, should be good enough for the user and
> >allows for a little bit of reordering even on very
> >slow devices ...
> 
> As Andrea points out its easy enought to do some sort of test with
> the current code.
> 
> >Well changing that is very easy, you only have to change the unit of
> >measure w/o changing one bit in the algorithm that is just implemented
> >indeed.
> 
> >How
> 
> >Just assume the req->elevator_sequence to be calculate in jiffy and in
> >elevator.c change the check for `!req->elevator_sequence' to
> >`time_before(req->elevator_sequence, jiffies)'. Then of course change the
> >initialization of req->elevator_sequence to be done with `jiffies +
> >elevator->read_latency'. Then also elvtune will talk in jiffies and not in
> >requests.
> 
> I wonder if using a wandering insert pointer, as Alan suggests, would give
> lower overhead than the current implementation (and would it really help)?
> 
> Again from Alan,
> 
> Andrea> Now, I see people trying to introduce the concept of elapsed time
> Andrea> that fix, which smells strongly of hack. How will this hack be cobbled
> >
> > Actually my brain says that elapsed time based scheduling is the right
> > thing to do. It certainly works for networks
> 
> And from Chris Evans,
> 
> >Interesting, I'll try and run with this. The mention of networks reminds
> >me that any "max service time" variable is a tunable quantity depending on
> >current conditions..
> 
> >.. and sct's block device I/O accounting patches give us the current
> >average request service time on a per-device basis. Multiply that up a bit
> >and maybe you have your threshold for moving things to the head of the
> >queue.
> 
> So we could end up using a figure that builds in both number of request and
> time on a per device level without to much effort...
> 
> And Alan sums up the whole thing nicly with:
> 
> Andrea> Why do you say it's not been fixed? Can you still reproduce hangs long
> Andrea> a write(2) can write? I certainly can't.
> 
> >I cant reproduce long hangs. Im not seeing as good I/O throughput as before
> >but right now Im quite happy with the tradeoff. If someone can make it better
> >then Im happier still
> 
> If the idea works, lead to simpler code, a more reponsive system maybe with
> better benchmarks then its a winner.  Only way we can be sure is to try it.
> 
> Thanks,
> 
> Ed Tomlinson <[EMAIL PROTECTED]> (ontadata on IRC)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Reorg raid5 block xor routines

[Richard Henderson]

On Mon, Sep 11, 2000 at 08:48:24AM -0700, Linus Torvalds wrote:
>  - Please split this up the same way the checksums were split up:
>make the xor routine be an architecture-dependent library thing, with
>the "generic" slow one possibly just a regular library thing.

This is simple enough to do when compiling this code into the kernel,
but becomes much trickier when trying to load it as a module.  I'll
spare your queasy stomach descriptions of the possible solutions that
I've thought of.

So, unless you have non-gross, non-fragile ideas, I only see two
acceptible solutions: (1) compile it in staticly, or (2) leave things
where they are.

I know you're not thrilled about nr 2, but the question is whether it
is acceptible to add 15k code on the chance that someone will want to
do raid5.  At present all the distributions ship modular /dev/md, 
since it has no appreciable impact until the personalities are loaded.



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

OOPS: [Fwd: 2.4.0-test8 oops in ll_rw_blk.c:711]

[Nadeem Riaz]

Whoops, sent this to the old adress by accident



Hi,

[1.]  Kernel oops while using netscape in X

[2.]The following oops occured as netscape messenger was attempting
to read my INBOX. Normal X usage (a few xterms,  netscape, emacs, xmms),

[3.] kernel ll_rw_blk.c

[4.]  2.4.0-test8
Using 2.4.0-test6 at the momment, nothing really changed between
compiles, so this is /proc/version for 2.4.0-test6
Linux version 2.4.0-test6 ([EMAIL PROTECTED]) (gcc version
egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 Wed Aug 23 20:17:59
EDT 2000

[5.]

Sep 11 20:07:55 nut kernel: kernel BUG at ll_rw_blk.c:711!
Sep 11 20:07:55 nut kernel: invalid operand: 
Sep 11 20:07:55 nut kernel: CPU:0
Sep 11 20:07:55 nut kernel: EIP:0010:[__make_request+178/1576]
Sep 11 20:07:55 nut kernel: EFLAGS: 00010296
Sep 11 20:07:55 nut kernel: eax: 001f   ebx: c6316f80   ecx:
c4519a00   edx: 0009
Sep 11 20:07:55 nut kernel: esi: c6316f80   edi:    ebp:
c0351100   esp: cb155e94
Sep 11 20:07:55 nut kernel: ds: 0018   es: 0018   ss: 0018
Sep 11 20:07:55 nut kernel: Process netscape (pid: 15235,
stackpage=cb155000)
Sep 11 20:07:55 nut kernel: Stack: c0278a56 c0278d22 02c7 c6316f80
0002 000c  
Sep 11 20:07:55 nut kernel:0002 c0351110 001e8480 c0351118
c0351110  0002 
Sep 11 20:07:55 nut kernel: c017f914 00fe c0180524
c0351100 0001 c6316f80 c6316f80
Sep 11 20:07:55 nut kernel: Call Trace: [tvecs+107678/123252]
[tvecs+108394/123252] [blk_get_queue+52/72]
[generic_make_request+180/276] [ll_rw_block+367/484]
[writeout_one_page+53/76] [do_buffer_fdatasync+73/124]
Sep 11 20:07:55 nut kernel:[generic_buffer_fdatasync+29/56]
[writeout_one_page+0/76] [ext2_sync_file+50/168] [sys_write+139/160]
[sys_fsync+73/104] [system_call+51/56]
Sep 11 20:07:55 nut kernel: Code: 0f 0b 83 c4 0c 90 0f b6 46 15 0f b7 5e
14 8b 14 85 60 56 34

[6.]

[7.]  Redhat 6.1 -- x86 -- errata updated

[7.1.]
-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux nut.nut.dhs.org 2.4.0-test6 #2 Wed Aug 23 20:17:59 EDT 2000 i686
unknown
Kernel modules 2.3.14
Gnu C  egcs-2.91.66
Binutils   2.9.1.0.24
Linux C Library2.1.3
Dynamic linker ldd (GNU libc) 2.1.3
Procps 2.0.4
Mount  2.9u
Net-tools  1.53
Console-tools  1999.03.02
Sh-utils   2.0
Modules Loaded lm80 lm78 lm75 sensors i2c-piix4 i2c-isa i2c-core
ipt_MASQUERADE ipt_REDIRECT ip_nat_ftp iptable_nat ipt_unclean ipt_tos
ipt_state ipt_owner ipt_multiport ipt_mark ipt_mac ipt_limit ipt_TOS
ipt_REJECT ipt_MIRROR ipt_MARK ipt_LOG ip_queue ip_conntrack_ftp
ip_conntrack iptable_mangle iptable_filter ip_tables 3c509

[7.2.]
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 6
model name  : Celeron (Mendocino)
stepping: 0
cpu MHz : 334.095519
cache size  : 128 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr
bogomips: 666.83

[7.3.]

lm805588   0 (unused)
lm787184   0
lm753120   0
sensors 6012   0 [lm80 lm78 lm75]
i2c-piix4   3612   0 (unused)
i2c-isa 1160   0 (unused)
i2c-core   12428   0 [lm80 lm78 lm75 sensors i2c-piix4
i2c-isa]
ipt_MASQUERADE  1284   1
ipt_REDIRECT 956   0 (unused)
ip_nat_ftp  3336   0 (unused)
iptable_nat12448   1 [ipt_MASQUERADE ipt_REDIRECT
ip_nat_ftp]
ipt_unclean 6976   0 (unused)
ipt_tos  708   0 (unused)
ipt_state832   0 (unused)
ipt_owner   1300   0 (unused)
ipt_multiport908   0 (unused)
ipt_mark 716   0 (unused)
ipt_mac  872   0 (unused)
ipt_limit   1076   0 (unused)
ipt_TOS 1096   0 (unused)
ipt_REJECT  1944   0 (unused)
ipt_MIRROR  1080   0 (unused)
ipt_MARK 940   0 (unused)
ipt_LOG 3176   1
ip_queue4672   0 (unused)
ip_conntrack_ftp1976   0 (unused)
ip_conntrack   12860   3 [ipt_MASQUERADE ipt_REDIRECT ip_nat_ftp
iptable_nat ipt_state ip_conntrack_ftp]
iptable_mangle  1600   0 (unused)
iptable_filter  1916   0 (unused)
ip_tables  10488  20 [ipt_MASQUERADE ipt_REDIRECT
iptable_nat ipt_unclean ipt_tos ipt_state ipt_owner ipt_multiport
ipt_mark ipt_mac ipt_limit ipt_TOS ipt_REJECT ipt_MIRROR ipt_MARK
ipt_LOG iptable_mangle iptable_filter]
3c509   7352   1 (autoclean)

[7.4.]
-001f : dma1

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Albert D. Cahalan]

Trond Myklebust writes:

> Relying on the sub-second timing fields is a much more
> implementation-specific. It depends on the capabilities of both the
> filesystem and the server OS.
> Linux and the knfsd server code could easily be modified to provide
> such a service, but the problem (as I've stated before) is that you
> need to save the time somewhere on disk. I believe currently ext2
> provides only 32 bits of storage for mtime (though perhaps somebody
> else could comment on that).

Yes, ext2 has this limit.

It would not be reasonable to try extending ext2 to 64-bit times,
but milliseconds might be doable. You'd need 4 bytes to support
the 3 standard time stamps.

Going to microseconds would require 8 free bytes, which I don't
think we have. (but we do have more that one might think, due
to the unimplemented junk)

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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Andi Kleen]

On Tue, Sep 12, 2000 at 09:10:56PM +0200, Trond Myklebust wrote:
> Making mtime a true 64-bit cookie on Linux servers would be a solution
> that works on all clients.

Making mtime 64bit would also be useful for local parallel make runs, 
the current second resolution leads to race conditions on bigger SMP boxes.

Unfortunately the only FS that supports http://www.tux.org/lkml/

Re: More on 2.2.18pre2aa2 (summary of elevator ideas)

[Ed Tomlinson]

Hi,

Geez, A simple comment on IRC can _really_ generate lots of feedback. 
(There were over 50 messages about this in my queue - did not help 
that some were duplicated three times ).

I made the comment because I remember back when the discussion was current
on linux kernel.  I thought Jeff Merkey's, message was to the point.  Para-
phrasing from memory, it was something to the effect that novell had 
tried many elevators.  All had problems with some loads.  The best they
had found was the 'close the door' idea.  I do not remember if the door
was based on requests or time.  Another point to remember is that the 
netware people came up with a what they considered a good solution.  From
Jeff's comment they arrived at this solution by experiments and bitter
experience.  Maybe we can learn something from their research?

Here is what I glean from the thread:

>From all the discussion I find this suggestion from Alan to make lots of
sense.  Think it can be made to work with number of request almost as easily
as with time...

>When you do the scan to decide where to insert the entry you dont consider
>insertion before the time. Also you keep two queue heads the real and the
>insert head. Whenever you walk from the insert head and find it points to
>a 'too old' entry you update the insert_head.

And this suggestion from Rik should counter most of Andrea's time vs requests 
vs slow block devices issues.  We just have to be sure to close the door after
atleast n request or m time.  However, as pointed out by Chris Evan, later we
may not have to do this - there are stats that can give a good idea of a
device's latency.

>Not really. What about just using something like
>"half a second, but at least 10 requests liberty to
>reorder" ?

>It's simple, should be good enough for the user and
>allows for a little bit of reordering even on very
>slow devices ...

As Andrea points out its easy enought to do some sort of test with
the current code.

>Well changing that is very easy, you only have to change the unit of
>measure w/o changing one bit in the algorithm that is just implemented
>indeed.

>How

>Just assume the req->elevator_sequence to be calculate in jiffy and in
>elevator.c change the check for `!req->elevator_sequence' to
>`time_before(req->elevator_sequence, jiffies)'. Then of course change the
>initialization of req->elevator_sequence to be done with `jiffies +
>elevator->read_latency'. Then also elvtune will talk in jiffies and not in
>requests.

I wonder if using a wandering insert pointer, as Alan suggests, would give 
lower overhead than the current implementation (and would it really help)?

Again from Alan,

Andrea> Now, I see people trying to introduce the concept of elapsed time
Andrea> that fix, which smells strongly of hack. How will this hack be cobbled
>
> Actually my brain says that elapsed time based scheduling is the right
> thing to do. It certainly works for networks

And from Chris Evans,

>Interesting, I'll try and run with this. The mention of networks reminds
>me that any "max service time" variable is a tunable quantity depending on
>current conditions..

>.. and sct's block device I/O accounting patches give us the current
>average request service time on a per-device basis. Multiply that up a bit
>and maybe you have your threshold for moving things to the head of the
>queue.

So we could end up using a figure that builds in both number of request and
time on a per device level without to much effort...

And Alan sums up the whole thing nicly with:

Andrea> Why do you say it's not been fixed? Can you still reproduce hangs long
Andrea> a write(2) can write? I certainly can't.

>I cant reproduce long hangs. Im not seeing as good I/O throughput as before
>but right now Im quite happy with the tradeoff. If someone can make it better
>then Im happier still

If the idea works, lead to simpler code, a more reponsive system maybe with
better benchmarks then its a winner.  Only way we can be sure is to try it.

Thanks,

Ed Tomlinson <[EMAIL PROTECTED]> (ontadata on IRC)

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

Re: Test 8 Kernel Unable to get the password prompt?

[Andries Brouwer]

On Tue, Sep 12, 2000 at 03:34:22PM +, Steven Walter wrote:

> If you're logging in as root, this is probably a result of the VT not
> being named in /etc/securetty.  Devfsd mucks up the names, so you can
> either include "1," which would allow root logins from pseudo-terminals
> and other insecure places, or upgrade your util-linux to a newer
> version; I'm not sure what is new enough. 

login checks that /etc/securetty contains the terminal name,
where the latter is obtained (since util-linux 2.10h)
from ttyname(0) by deleting a leading "/dev/" if possible.
And ttyname(0) does a readlink("/proc/self/fd/0"), which will
return the pathname that was first used to open file descriptor 0.

Maybe no change of login is required if one has 2.10h or later,
provided one adapts /etc/securetty.

Andries


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

Re: Linux 2.2.18pre6

[Alan Cox]

> I see you parse-pieces for the 2.4 code as backports into 2.2 of the
> larger ide-patch.  What is it going to take to just accept it?

I'd prefer to do it bit by bit, driver by driver without touching the core
and picking the important and stable drivers first.

> I am considering the pull of the backport because I do not have time to do
> both directions.

If you can hand the backport on then I think that would be a good idea. Getting
2.4 stable is far far more important than the 2.2 backport, and getting taskfile
ready for 2.5 likewise.

You seem to have a new via maintainer perhaps you can interest him ?


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

Re: Linux 2.2.18pre4

[Jeff Garzik]

Paul Jakma wrote:
> alan seems to {want,prefer} small incremental/'obvious fix' patches.
> but that isn't practically possible anymore. It would mean the NFS
> guys would effectively have to redo the entire development cycle of
> code they have written over the last year.
[...]
> So it is now at the stage where we either:
> 
> 1. bite the bullet and sync stock nfs with nfs.sourceforge.net
> 
> or
> 
> 2. accept that stock 2.2 will never have decent NFS server
>functionality, and wait for 2.4 to get stable.

I don't think anybody has to redo a lot of development in order to
submit Alan small, focused patches.  So option #3, break up the big NFS
patch into small ones, still seems like the best option.

All this requires is a hacker, or hackers, who are interested enough in
2.2.x NFS to do something besides complaining :)

Jeff




-- 
Jeff Garzik  | Windows NT Performance,
Building 1024| on the next "In Search Of"
MandrakeSoft, Inc.   |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Recurring Oops in 2.2.12-20smp plus ext2_free_blocks.

[Alan Cox]

> If it was hardware, say one of the two processors was flaky, wouldn't I
> expect to see corrupted pointers being dereferenced in other sections
> of code or is the dcache data structure particular susceptible?

The dcache has long chains of pointers and tends to show up on things like
memory areas. It has a lot of potential for them it seems. if you are running
< 2.2.17 definitely give a newer kernel a go before assuming hardware related
things. There are _lots_ of bug fixes for stuff that could give the same 
result from software errors

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

Re: Linux 2.2.18pre6

[Andre Hedrick]

Alan,

I see you parse-pieces for the 2.4 code as backports into 2.2 of the
larger ide-patch.  What is it going to take to just accept it?

The ali-driver is straight out of 2.4 or ide-patch with parts of cmd646
taken to actively tune the drive and chipsets.

If it is the issue of the taskfile now in my patch, I will pull it if it
will prevent me from having to carry this monster around.

I am considering the pull of the backport because I do not have time to do
both directions.

Cheers,

Andre Hedrick
The Linux ATA/IDE guy

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

Re: Linux 2.2.18pre4

[Paul Jakma]

On Tue, 12 Sep 2000, Horst von Brand wrote:

> Better asK: What can _we_ do to assure Alan that NFS is up to snuff? 

even if it does suck - so what? it can't possibly suck as much as
current stock NFS. :) but the general view is that 2.2 with patches
is quite useable for NFS serving and as client.

> How can we help along?

the NFS patches (which are a backport of stock 2.4, which descended
from the original 2.2 NFS patches) are now too large and too
different from stock 2.2 to realistically be split up into small
little "this fixes this exact problem". The code is now so far ahead
of stock 2.2 that it is an effective rewrite (and with new, but
optional, NFSv3 client and server and NFS client over TCP code added
on).

alan seems to {want,prefer} small incremental/'obvious fix' patches.
but that isn't practically possible anymore. It would mean the NFS
guys would effectively have to redo the entire development cycle of
code they have written over the last year.

In lieu of a technical argument such as small patches, the only other
arguments are those based on the experiences of people who have tried
to get linux to work reliably as an NFS server and even client. I've
tried to cover those in a previous email, see: 
Message-ID: <[EMAIL PROTECTED]>

So it is now at the stage where we either:

1. bite the bullet and sync stock nfs with nfs.sourceforge.net

or

2. accept that stock 2.2 will never have decent NFS server
   functionality, and wait for 2.4 to get stable.

we await 2.219pre1 with much curiosity. :)

regards,
-- 
Paul Jakma  [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
Where you stand depends on where you sit.
-- Rufus Miles, HEW


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

Re: [ANNOUNCE] Darkstar Development Project

[Ralf Baechle]

On Mon, Sep 11, 2000 at 02:39:42PM -0700, Larry McVoy wrote:

> On the other hand, if you do a
> 
> find . -type f | xargs touch
> time cvs update .
> 
> it will melt down your DSL line for what seems forever.  I killed it after
> 20 minutes, I have better things to do with my bandwidth.   It's pretty
> clear that CVS is comparing timestamps so if your files get modified at
> all, it's going to transfer them to see what needs to be updated.  The
> same sort of "touch all, then update" operation in BK has no effect on
> performance, BK doesn't do its work that way.

>From some random Linux source tree's .hdepend:

/usr/people/ralf/src/linux/linux/include/asm/sn/sn0/ip27.h: \
   /usr/people/ralf/src/linux/linux/include/asm/mipsregs.h \
   /usr/people/ralf/src/linux/linux/include/asm/sn/addrs.h
@touch /usr/people/ralf/src/linux/linux/include/asm/sn/sn0/ip27.h
/usr/people/ralf/src/linux/linux/include/asm/sn/sn0/arch.h: \
   $(wildcard /usr/people/ralf/src/linux/linux/include/config/sgi/sn0/n/mode.h)
@touch /usr/people/ralf/src/linux/linux/include/asm/sn/sn0/arch.h
[...]

Linux, born to be CVS worst case ...

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

Re: Adding members to task_struct without recompling the kernel

[Keith Owens]

On Tue, 12 Sep 2000 18:17:48 -0400 (EDT), 
Michael Vines <[EMAIL PROTECTED]> wrote:
>I'm writing a kernel module that needs to keep track of a pointer to some
>custom module information for every task in the system.  Basically I want
>to add another member to task_struct but I don't want to have to
>recompile the kernel to do it.

Your module initialization gets the current maximum number of tasks,
allocates an array of the desired size and stores the size and address
of the array in the module.  Then store whatever you want in your
private data area.  If the max tasks value changes on the fly,
reallocate your private data.  Use a read/write to protect your private
data during resizing.

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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Jeff Epler]

On Tue, Sep 12, 2000 at 09:10:56PM +0200, Trond Myklebust wrote:
> > " " == Alan Cox <[EMAIL PROTECTED]> writes:
> 
>  > Providing everyone is careful to hold a lock I think it is
> 
>  > lockf() is a read barrier providing the local cache is flushed,
>  > the unlock is a write barrier providing the local cache is
>  > flushed first. Providing all users are using lockf for their
>  > I/O then it seems to be coherent
> 
> 
> Sure, but what happens if you're in a mixed client environment?
> If we have a purely Linux-specific hack to ensure cache coherency,
> that will still corrupt the cache on those *NIX clients that use
> ordinary cache coherency checking (i.e. checking mtime + file size)
> rather than cache invalidation.

We don't alter anything about what the other clients cache.  Sure, you can
connect to the same server with a client that doesn't have this fix, and
sure you might get different cached data on different clients at the same
time, but that's the current situation.  You don't make it *worse* for
anybody else, you make it *better* for Linux.

> There's nothing in the NLM+NFSv2+NFSv3 notes about this situation, but 
> on page 77 of the latest NFSv4 draft it states:
> 
>oFirst, when a client obtains a file lock for a particular
> region, the data cache corresponding to that region (if any
> cache data exists) must be revalidated.  If the change attribute
> indicates that the file may have been updated since the cached
> data was obtained, the client must flush or invalidate the
> cached data for the newly locked region.  A client might choose
> to invalidate all of non-modified cached data that it has for
> the file but the only requirement for correct operation is to
> invalidate all of the data in the newly locked region.

But "ctime and file size are the same" does not prove that the file is
unchanged.  That's the root of this problem, and why NFS_CACHEINV(inode) is
not enough to ensure coherency.

Furthermore, according to NFSv4, what I am suggesting is something that a
client "may choose" to do anyhow---i.e., it's at least permitted by the
spec, even if it's not required.

> Making mtime a true 64-bit cookie on Linux servers would be a solution
> that works on all clients.

Yes, but my solution works for all servers with a Linux client. (We've been
making this modification to NFS clients in several other unices for years,
we know it works and gives the guarantees we need)

> It also avoids a lot of unnecessary cache flushing. Imagine having to
> reread your entire mailbox every time you open the file whether or not
> a new message has arrived. Ugh...

It's better to get wrong results if you run a mail client at the same time
on two different machines, right?

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

Re: Notebook disk spindown

[Daniel Kobras]

On Tue, 12 Sep 2000, Jamie Lokier wrote:

> Dave Zarzycki wrote:
> > Personally speaking, I always thought it would be nice if the kernel
> > flushed dirty buffers right before a disk spins down. It seems silly to me
> > that a disk can spin down with writes pending.
> 
> Absolutely.  That allows more time spun down too.

Pavel Machek sent me a patch for noflushd to do exactly this. Need not be
a kernel issue either.

Regards,

Daniel.

-- 
GNU/Linux Audio Mechanics - http://www.glame.de
  Cutting Edge Office - http://www.c10a02.de
  GPG Key ID 89BF7E2B - http://www.keyserver.net

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

(reiserfs) Re: More on 2.2.18pre2aa2

[Andrea Arcangeli]

On Tue, 12 Sep 2000, Martin Dalecki wrote:

>First of all: In the case of the mp3 player and such there is already a
>fine
>proper way to give it better chances on getting it's job done smooth - 
>RT kernel sceduler priorities and proper IO buffering. I did something
>similiar
>to a GDI printer driver...

Take 2.2.15, set a buffer of 128mbyte (of course assume your mp3 is larger
than 128mbyte :) and then run in background `cp /dev/zero .` in the same
fs where your mp3 file out of cache is living. Then you'll see why a large
buffer is useless if there's none kind of I/O fair scheduling into the
elevator. Repeat the same test in 2.2.16 then.

The I/O latency Hans was taking about for the mp3 player, is the time it
takes for the buffer to become empty.

>device driver level, if at all. In fact you have already bad 
>interactions between strategies of low level drivers and the high
>level code in Linux - like for example the "get from top of queue" or 
>"don't get it from top of the IO queue" mess between
>IDE and SCSI middlelayers... (However this got a bit better recently.)

That's historic cruft, it's unrelated to controlling the elevator
algorithm per-task/per-file basis IMHO.

Andrea


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

Re: Notebook disk spindown

[Pavel Machek]

Hi!

> > On Sat, 9 Sep 2000 [EMAIL PROTECTED] wrote:
> > > Would it be possible to detect when the disk spins up, and do the flush then?
> > Yes if you had a continuious polling of power status wrt standby.
> 
> I think the following flushing policy would work almost as well, while
> remaining generic:
> 
>  - if there's a read that is not handled from the buffer cache, flush
>(write) all dirty buffers
>  - if we need to flush (write) one dirty buffers, flush all others too
> 
> This wouldn't catch cases like an explicit spin-up without data I/O,
> but I don't think this is much of a problem in real life.

noflushd works for me. It monitors "read/write" counters in
/proc/stat, and if it detects activity, it syncs(). If it detect idle
period, it syncs() then spins disk down.
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Alan Cox]

> Why do you say it's not been fixed? Can you still reproduce hangs long as
> a write(2) can write? I certainly can't.

I cant reproduce long hangs. Im not seeing as good I/O throughput as before
but right now Im quite happy with the tradeoff. If someone can make it better
then Im happier still

> 

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

Re: How to put something in /proc

[Giuliano Pochini]

> > On Sun, 10 Sep 2000, Giuliano Pochini wrote:
> > > I need to create a "file" in /proc to monitor some kernel
> > > variables from user space. How can I do ? / Where can I
> > > get docs ?  And how can I do time measurements from
> > > inside the kernel ?
> >
> > Search for proc_register() inside the kernel sources.
>
> _Don't_
>
> proc_register() is dead. Use create_proc_read_entry() instead.

Ok, tnx.

Bye.

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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Jeff Epler]

On Tue, Sep 12, 2000 at 07:08:09PM +0200, Trond Myklebust wrote:
> This is a known issue, and is not easy to fix. Neither of the
> solutions you propose are correct since they will both cause a cache
> invalidation. This is not the same as cache coherency checking.
> 
> 
> The correct solution in this case would be to add a 'sub-second time
> field' to ext2fs & friends. Both NFSv2 and NFSv3 pass a 64 bit field
[...]

Trond,
Thanks for your swift answer.  I sent a message a few months ago with
a much poorer solution which was perhaps rightly ignored

Is there any solution that's available today, and doesn't depend on
using Linux in the server?  I suspect that we will have to distribute
a modified nfs client with our app, and we're prepared to accept the
cache invalidation (and reduced performance it causes) for a technique
that will work with any NFS server and provide the level of guarantees
we need.

Is there a solution that would allow the kind of guarantee our software
wants with non-linux nfsds without the cache-blowing that the change I'm
suggesting causes?

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

Re: rocket port patch for 2.4

[tytso]

   Date: Tue, 5 Sep 2000 19:58:48 -0500
   From: Steven Critchfield <[EMAIL PROTECTED]>

   I have been playing with the rocket port driver in 2.4 trying to make 
   it work. It appears that the driver hasn't been modified in some time,
   as it did not work at all on the debian potato inbstall of 2.2.17, nor
   did it work under a fresh 2.4.0-test6 compile. 

Yeah, I need to get the latest Rocketport driver updated for 2.4.  I
think I have it working for 2.4 and devfs; I'd appreciate it if you
could test it for me.  You can get the driver at:

http://rocketport.sourceforge.net

Most of the users of the driver are still using Linux 2.2 (and they
usually get the driver from the manufacturer when they buy the card), so
the main maintenance happenss outside the kernel.  It's about time to
get an update folded into the Linux 2.2 and 2.4 trees, though.

   here is the diff against a 2.4.0-test6 kernel

   608c608
   < 
   ---
   >

For future reference, use the -u flag to diff to create unified diffs.
They contain a lot more context and are much more useful when sending
patches to authors.

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

(reiserfs) Re: More on 2.2.18pre2aa2

[Rik van Riel]

On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> On Tue, 12 Sep 2000, Rik van Riel wrote:
> 
> >Also, this possibility is /extremely/ remote, if not
> >impossible. Well, it could happen at one point in time,
> 
> It's not impossible. Think when you run a backup of you home
> directory while you're listening mp3. Both `tar` and `xmms` will
> read the same file that is out of cache.
> 
> `tar` will be the first one who will read the next out-of-cache
> data-page of the file. The I/O will be so issued with low prio
> but then, as soon as `tar` has issued the read I/O, also `xmms`
> will wait on the same page and it will skip the next deadline
> because the I/O is been issued with low prio.

Indeed, this could be an issue...

> To make it work right is not simple.

I don't know if we really have to care about this
case. The process queueing the IO is more than
likely a good guess, and a good guess is (IMHO)
better than not guessing at all and hoping things
will be ok.

regards,

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

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


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

Re: Masking out one page of RAM because of bit-errors.

[Jan Niehusmann]

On Tue, Sep 12, 2000 at 06:18:36PM +0200, Patrick Mau wrote:
> I have a bad SDRAM chip with exactly one bit error. Memtest86 shows
> that the bit error always occurs at the address 0x4eff508. I tried
> to calculate the page number and it should be 20223.

There is a patch on http://home.zonnet.nl/vanrein/badram/ to avoid using
bad ram pages. I didn't test it - my ram is good ;-) (at least the ram in
my computer - I'd like to see a port of this program to my own brain...)

Jan

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

(reiserfs) Re: More on 2.2.18pre2aa2

[Rik van Riel]

On Tue, 12 Sep 2000, Martin Dalecki wrote:

> Second: The concept of time can give you very very nasty
> behaviour in even cases. [integer arithmetic]

Point taken.

> Third: All you try to improve is the boundary case between an
> entierly overloaded system and a system which has a huge reserve
> to get the task done. I don't think you can find any
> "improvement" which will not just improve some cases and hurt
> some only slightly different cases badly. That's basically the
> same problem as with the paging strategy to follow. (However we
> have some kind of "common sense" in respect of this, despite the
> fact that linux does ignore it...)

Please don't ignore my VM work  ;)
http://www.surriel.com/patches/

> Firth: The most common solution for such boundary cases is some
> notion of cost optimization, like the nice value of a process or
> page age for example, or alternative some kind of choice between
> entierly different strategies (remember the term strategy
> routine) - all of them are just *relative* measures not
> absolute time constrains.

Indeed, we'll need to work with relative measures to
make sure both throughput and latency are OK. Some kind
of (very simple) self-tuning system is probably best here.

regards,

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

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


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

No Subject

[Jelmer Vernooij]

Hello,

I got this OOPS error. Ksymoops output is listed below. It occured when I
was starting named and gave the message the error occured in 'chgrp'.

OOPS: 
CPU: 0
EIP: 0010: []
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax:    ebx: c1b25f24 ecx: c1f46380 edx: 0004
esi:    edi: 0001 ebp:  esp: c1b25ed8
ds: 0018 es: 0018 ss: 0018
Process chgrp (pid: 153, stackpage=c1b25000)
Stack: c1b25f24   c0197f3b   c1b25f54 0016
   c1d98360 bca4 c1a2fc60 c1febed8 c1b25f2c c1b25f24 0004 c01395d8
   0001 ff86 c1f46380  c1a2fa20  c1a2fc60 c012f437
Call trace: [] [] [] [] [] 
[] []
Code: f6 46 34 40 74 07 31 c0 e9 f7 00 00 00 8b 56 48 85 d2 74 43

>>EIP; c019718b<=
Trace; c0197f3b 
Trace; c01395d8 
Trace; c012f437 
Trace; c013a3b1 <__user_walk+4d/58>
Trace; c012f48b 
Trace; c0120cb7 
Trace; c010acfb 
Code;  c019718b 
 <_EIP>:
Code;  c019718b<=
   0:   f6 46 34 40   testb  $0x40,0x34(%esi)   <=
Code;  c019718f 
   4:   74 07 je d <_EIP+0xd> c0197198 
Code;  c0197191 
   6:   31 c0 xorl   %eax,%eax
Code;  c0197193 
   8:   e9 f7 00 00 00jmp104 <_EIP+0x104> c019728f 
Code;  c0197198 
   d:   8b 56 48  movl   0x48(%esi),%edx
Code;  c019719b 
  10:   85 d2 testl  %edx,%edx
Code;  c019719d 
  12:   74 43 je 57 <_EIP+0x57> c01971e2 

Jelmer

ps. please send replies to my email address too, since I am not (yet) on
the kernel development list.



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

Re: Using Yarrow in /dev/random

[Igmar Palsenberg]

> No, not true.  The mixing into the entropy pool uses a twisted LFSR, but
> all outputs from the pool (to either /dev/random or /dev/urandom)
> filters the output through SHA-1 as a whitener.  The key here, though,
> and what makes this fundamentally different from yarrow, is that since
> we're feeding the entire (large) entropy pool through SHA-1, even if the
> SHA-1 algorithm is very badly broken (say as in what's been happening
> with MD5), as long as there's sufficient entropy in the pool, the
> adversary can define but minimal information about the pool, since the
> 8192 -> 160 bit transform has to lose information by definition.

Broken ?? Please explain.



Igmar

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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Trond Myklebust]

> " " == Alan Cox <[EMAIL PROTECTED]> writes:

 > Providing everyone is careful to hold a lock I think it is

 > lockf() is a read barrier providing the local cache is flushed,
 > the unlock is a write barrier providing the local cache is
 > flushed first. Providing all users are using lockf for their
 > I/O then it seems to be coherent


Sure, but what happens if you're in a mixed client environment?
If we have a purely Linux-specific hack to ensure cache coherency,
that will still corrupt the cache on those *NIX clients that use
ordinary cache coherency checking (i.e. checking mtime + file size)
rather than cache invalidation.

There's nothing in the NLM+NFSv2+NFSv3 notes about this situation, but 
on page 77 of the latest NFSv4 draft it states:

   oFirst, when a client obtains a file lock for a particular
region, the data cache corresponding to that region (if any
cache data exists) must be revalidated.  If the change attribute
indicates that the file may have been updated since the cached
data was obtained, the client must flush or invalidate the
cached data for the newly locked region.  A client might choose
to invalidate all of non-modified cached data that it has for
the file but the only requirement for correct operation is to
invalidate all of the data in the newly locked region.


---

Making mtime a true 64-bit cookie on Linux servers would be a solution
that works on all clients.
It also avoids a lot of unnecessary cache flushing. Imagine having to
reread your entire mailbox every time you open the file whether or not
a new message has arrived. Ugh...

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

Re: [RFC] Changes file [was Re: modules directory]

[Oliver Xymoron]

On Tue, 12 Sep 2000, Simon Huggins wrote:

> On Tue, Sep 12, 2000 at 01:41:45AM -0500, Oliver Xymoron wrote:
> > > > This is similar to my patch-names patch, which lets you add components
> > > > to uname too. IIRC, it was rejected because it made things easier.
> > > Erm?  Not really.  Not unless you want
> > > 2.2.x-requires-modutils-2.3.9-requires-pppd-x.y.z etc?
> > No, that's not it at all. It's more for doing things like
> > 2.4.0-pre8+ikd+xfs where ikd and xfs are patches you applied. With a
> > little Makefile magic, they become part of the uname.
> 
> Yes, you implied it solved what I was trying to solve being the people
> complaining on list about make modules_install no longer working when
> they hadn't read Documentation/Changes.

The thread had moved on by then to a trick for putting changelog entries
in patches. With my patch, you can put the changelog entries in the same
files that flag the uname additions.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 


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

Re: I/O statistics per process?

[Karim Yaghmour]

Try the Linux Trace Toolkit. This should provide you with most I/O 
information you need.

www.opersys.com/LTT

Hope it helps.

Samuli Kaski wrote:
> 
> I know about sar which can deliver what I want for disks and/or
> partitions. What about if I want to know how much I/O is caused by
> userspace programs?
> 
> Looking at the proc-interface in 2.2.xx the necessary bits aren't
> available. The BSD process accounting doesn't provide them either, the
> I/O fields are always 0 the way I read it. Looking at the task_struct, I
> can't see anything related there.
> 
> Is I/O caused by userspace processes accounted somewhere? And if it
> isn't is this intentional or are folks just waiting for someone to
> submit a patch? Thanks.
> 
> Samuli
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-- 
===
 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]
Please read the FAQ at http://www.tux.org/lkml/

Re: More on 2.2.18pre2aa2

[Andrea Arcangeli]

On Tue, 12 Sep 2000, Jamie Lokier wrote:

>Sure the global system is slower.  But the "interactive feel" is faster.
>If I type "find /" I want it to go quickly.  But I still want Emacs to

You always want it to go quickly. But when you're in the blockdevice
layer you lost all the semantics of such I/O request. You have no idea if
somebody is running a background `cp` or if it's your `find` that's doing
the I/O.

>start up in a reasonable time, even if that means the overall time for
>both processes is slower.

And you as well want your `cp` not to run two times slower, right?

Then you have to choose. And you can choose with elvtune. (currently you
have to choose per blockdevice basis, maybe in the future you'll be able
to choose per 'struct file' basis)

That's not a matter of the algorithm. The only difference between the "in
function of time latency" and "in function of blocksize latency" is that
in kernel space we don't need to know the internal timings of the
hardware. If you know the timings and you want a 2 second latency
(assuming your harddisk write 1 block in less than 2 seconds) that do the
calc in userspace and run the blkelvset ioctl and you're almost happy. You
won't be completly happy because as said the elevator will give a two
seconds latency also to requests that are at the end of the queue, but
this is a matter of the algorithm, not really of the unit of measure of
the latency in kernel space.

The current unit of measure allows us to use the same latency settings for
most devices out there and still providing a good throughput (and avoiding
huge stalls). That's why I prefer it. But you can convert it easily in
userspace (or even you can change the unit in kernel but I don't see the
advantage, I'd rather prefer elvtune to do the conversion and to talk in
function of time instead of putting the timing stuff into the kernel).

Andrea

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

Re: (reiserfs) Re: More on 2.2.18pre2aa2

[Andrea Arcangeli]

On Tue, 12 Sep 2000, Chris Evans wrote:

>the elevator code. Keep it to a queue management system, and suddenly it
>scales to slow or fast devices without any gross device-type specific
>tuning.

Yep, that was the object.

Andrea

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

Re: [PATCH] for PAS16 functionality for 2.4

[Thomas Molina]

On Sun, 10 Sep 2000, Michael Elizabeth Chastain wrote:

> I have written documentation on Rules.make and the interface between
> Rules.make and Makefiles.  It's here:
> 
>   ftp://ftp.shout.net/pub/users/mec/kbuild/x-Dkm-9.diff
> 
> I would really like to see this documentation in the kernel.  I've sent
> it to Linus three times, and he's ignored it three times.  I will try
> some more after the release of 2.4.0.

Thanks for a very lucid docfile.  I would really urge it be included.  I
have just one metacomment.  You have a number of sections (marked with
===) in the body of the text.  Could we have those lines duplicated at
the top in an "intro" section? (Sort of like This file covers the
following topics...), perhaps with section designators.  That would
allow the reader to quickly search to the specific part he/she was
interested in.  I can produce a patch if you'd like.

> Anyways ... I'd appreciate it if a couple of people would try this patch
> so that I can submit it.
> diff -u -r -N linux-2.4.0-test8/Rules.make linux/Rules.make
> --- linux-2.4.0-test8/Rules.makeSun Aug 13 12:55:51 2000
> +++ linux/Rules.makeSun Sep 10 14:06:02 2000
> @@ -190,7 +190,7 @@
>  #
>  ifdef CONFIG_MODULES
>  
> -SYMTAB_OBJS = $(LX_OBJS) $(OX_OBJS) $(MX_OBJS) $(MIX_OBJS)
> +SYMTAB_OBJS := $(sort $(LX_OBJS) $(OX_OBJS) $(MX_OBJS) $(MIX_OBJS))
>  
>  ifdef CONFIG_MODVERSIONS
>  ifneq "$(strip $(SYMTAB_OBJS))" ""

I tried the patch and it works for me!  Thanks again.

I'm also going to take a look at integrating sb functionality into
pas2_card.c as Mr. Hellwig suggested, unless someone thinks that is a
bad idea.  That'll be later this week after I slog through integration
of partial fractions (yuk).


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

Re: Masking out one page of RAM because of bit-errors.

[John Levon]

On Tue, 12 Sep 2000, Patrick Mau wrote:

> Dear list-readers,
> 
> I have a bad SDRAM chip with exactly one bit error. Memtest86 shows
> that the bit error always occurs at the address 0x4eff508. I tried
> to calculate the page number and it should be 20223.
> 

You should try Rik van Rein's BadRam patch. Link as always from
http://kernelnewbies.org

john

-- 
"People understand me so little that they do not even understand me when I
 complain of being misunderstood."
   - Kierkegaard 

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

(reiserfs) Re: More on 2.2.18pre2aa2

[Andrea Arcangeli]

On Tue, 12 Sep 2000, Rik van Riel wrote:

>But you don't. Transfer rate is very much dependant on the
>kind of load you're putting on the disk...

Transfer rate means `hdparm -t` in single user mode. Try it and you'll see
you'll get always the same result.

>Throughput really isn't that relevant here. The problems are

Thoughput is relevant. Again, how do you get a 1msec latency out of a
blockdevice that writes 1 request every two seconds?

>With equally horrible results for most machines I've
>seen. For a while I actually thought the bug /must/
>have been somewhere else because I saw processes
>'hanging' for about 10 minutes before making progress
>again ...

As said in my earlier email the current 2.4.x elevator scheduler is
_disabled_. I repeat: you should change include/linux/elevator.h and set
the read and write latency to 250 and 500 respectively. You won't get
latency as good as in test1, but it won't hang for 10 minutes.

I and Jens sent a patch to Linus to reenable that push fixing some other
problem of the blkdev merging reported by Giuliano Pochini, plus wake-one
flow control, plus I fixed the DMA_CHUNK_SIZE thing that was buggy and
it's still buggy in the sparc64 case (I didn't fixed sparc64 in my patch,
the DMA_CHUNK_SIZE should limit the segments to
max(64,SHpnt->sg_tablesize) and not to 64 as now), plus it allowed 512K
sized SCSI commands, plus some other minor thing but it didn't get merged.

>Not really. What about just using something like
>"half a second, but at least 10 requests liberty to
>reorder" ?

I doesn't make sense.

Andrea


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

(reiserfs) Re: More on 2.2.18pre2aa2

[Andrea Arcangeli]

On Tue, 12 Sep 2000, Rik van Riel wrote:

>Why do you always come up with impossible examples?

That's not impossible. impossible != unlikely.

A more regular case is when you have an extremely fast device, were a 1/2
second latency is too much, using 100msec could be just enough to provide
good tiotest numbers and you would get better latency with the current
elevator than with the 1/2 second hardwired value.

>What I'd like to see is an elevator where the settings set
>by the user have a direct influence in the behaviour observed.

I can see direct influence. (more in the past but also now)

>Doing time-based request sorting should give us that behaviour
>and a default of say 1/2 second would work fine for all the
>hard disks and cdrom drives I've seen in the last 6 years.

Well changing that is very easy, you only have to change the unit of
measure w/o changing one bit in the algorithm that is just implemented
indeed.

Just assume the req->elevator_sequence to be calculate in jiffy and in
elevator.c change the check for `!req->elevator_sequence' to
`time_before(req->elevator_sequence, jiffies)'. Then of course change the
initialization of req->elevator_sequence to be done with `jiffies +
elevator->read_latency'. Then also elvtune will talk in jiffies and not in
requests.

>Of course you can dream up an imaginary device where it won't
>work, but in that case there's always the possibility of tuning
>the elevator (like we do right now) ...

I don't like having to tune things by hand for the unlikely case. Note
that also the unit of bytes thing that we have now may have to be tuned
for some case, but it's even less unlikely that you have to do that to get
good throughput.

Andrea


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

Re: Booting into /bin/bash

[David Mansfield]

Ion Badulescu wrote:
> 
> 
> Maybe I'll play with main.c and see what happens if I force /dev/console
> to become the controlling tty for init. Hmm... That could be dangerous for
> init. Maybe a better idea would be to hack init so that it gives any
> program started from inittab /dev/console as the controlling tty.
> 

I like this idea a lot (the latter - making /dev/console controlling
tty).  On an old SunOS 4 machine I once worked with, a Ctrl-C during the
execution of rc.sysinit would sent it terminate signals.  So when the
NFS was hanging on mount because of a f***ed up network (or changed ip
address of server) you could hit ctrl-c during the rc script and the
mount would be sent the ctrl-c and would terminate, then the rest of the
rc script would continue (regular shell script behavior if I'm not
mistaken).

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

Re: Duplicate messages

[Andreas Dilger]

Vern writes:
> Today, I received duplicate messages as posted by Rik van Riel to this
> list.  Here are the headers from both messages.  Other than identical
> Message-ID's, I can't discern where the duplicate originated.

> Subject: Re: More on 2.2.18pre2aa2

> Subject: (reiserfs) Re: More on 2.2.18pre2aa2

Notice the different subject lines?  I somehow thought that I had
been subscribed to the reiserfs mailing list...

> Received: ([EMAIL PROTECTED]) by vger.kernel.org
>   id ; Tue, 12 Sep 2000 03:29:53 -0400
> Received: from 1Cust104.tnt1.santa-fe.nm.da.uu.net ([63.30.216.104]:7693 "EHLO
>   junior.ournet.home") by vger.kernel.org with ESMTP
>   id ; Tue, 12 Sep 2000 03:29:25 -0400
> Received: from root by junior.ournet.home with scanned_ok (Exim 3.16 #1)
>   id 13YkWv-0001LY-00; Tue, 12 Sep 2000 01:30:57 -0600
> Received: from hackvan.com ([206.80.31.242] ident=qmailr)
>   by junior.ournet.home with smtp (Exim 3.16 #1)
>   id 13YkWt-0001L3-00
>   for [EMAIL PROTECTED]; Tue, 12 Sep 2000 01:30:55 -0600
> Received: (qmail 11161 invoked by uid 530); 12 Sep 2000 07:30:01 -
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Delivered-To: mailing list [EMAIL PROTECTED]
> Received: (qmail 11152 invoked from network); 12 Sep 2000 07:29:55 -
> X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs

It sure looks like the second email was delivered to the reiserfs mailing
list and then resent out to the kernel mailing list.  Either it is an
issue at the reiserfs mailing list, or a problem at "[EMAIL PROTECTED]"
which is a real domain, despite the name.

Cheers, Andreas

PS - this note has been CC'd to [EMAIL PROTECTED]
-- 
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]
Please read the FAQ at http://www.tux.org/lkml/

Re: Q: sock output serialization

[kuznet]

Hello!

> Yes, I see. I did not realize before that the lock_sock and the
> sk->backlog framework are not two independent things. They really
> seem to be designed for team work only.  Did I get this right?

Yes.

Actually, in 2.4 lock_sock() is also semaphore and in some cases
(f.e. for stateless datagram sockets) it is used as pure semaphore.


> applied seems to make socket propgramming as easy as in the old cli()/sti()
> days again. 

What??? 8)8)

No, it makes it much easier. 8)

By the way:

1. lock_sock() is not much younger than cli()/sti().
2. cli()/sti() is not used by attended parts of networking for looong time,
   they are deprecated not yesterday too.

> tcp also seems to use some additional protocol-global spinlocks

Of course.


> (like tcp_portalloc_lock).

And this is redundant, to be honest. 8)


> the spinlock. In that case, beeing preemptable would make a very essential
> difference.

Yes, of course.


> Anyway, it seems that I can already make use the lock_sock() infrastructure
> for fixing the output serialization, even without making the whole
> protocol stack SMP-aware at once.

Actually, the last task is not a rocket science as well.

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

Re: Linux 2.2.18pre4

[Alan Cox]

> What are the issues with updating NFS code that do not exist with
> other drivers, filesystems, etc... in 2.2 for which updates are
> accepted?

They exist in the same way. You update stuff in controlled careful steps and
you change troublesome drivers very early in a patch release - eg never touching
tulip except early on

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

Re: Linux 2.2.18pre4

[Paul Jakma]

On Tue, 12 Sep 2000, Alan Cox wrote:

> > ..so it should be at least as well tested as the USB backport in 2.2.18preX, 
> > if not more so?  Or so is implied. :)
> 
> This is the big clue most people are missing
> 
> 2.2.17-   USB devices do not work
> 2.2.18-   USB=n  no kernel change USB devices still do not work
>   USB=m  USB works for most people
> 
> USB cant make things any worse than now because you can compile it out.
> 

I see where you are coming from, but the {"stock 2.4","2.2 patch"} NFS
code is well tested, lots of bug fixes for NFSv2 and the 'new' code ->
NFSv3 client/server is a compile yes/no option, just like the USB
backport.

2.2 without patches -   NFS has performance/reliability problems
2.2 with patches-   NFSv2 provided with lots of bugfixes
NFSv3 is compile time optional

I have not heard of anyone that prefers stock 2.2 NFS over
patched/2.4. Anecdotal evidence[1] suggests:

- stock 2.2 has 'issues' with NFS, serving in particular. Bad enough
  that linux users would consider switching to another *nix for NFS
  serving.

- 2.2 + NFS patches does not have issues (or very few), and would even
  appear to work quite well, definitely for NFSv2 and seemingly for
  the optional v3[2]. Certainly you need the patches for
  interoperability.

- all the NFS developers are working the 2.4 code and backporting to
  2.2. So issues wrt to the current 2.2 NFS codebase will not get
  fixed. Issues wrt to the 2.4 backport do get fixed.

So the anecdotal evidence suggests we don't have anything to lose but
a not very good NFS server, and everything to gain.

What are the issues with updating NFS code that do not exist with
other drivers, filesystems, etc... in 2.2 for which updates are
accepted?

what is there to lose?

--paulj

[1]. as gathered from posts to this thread, to the nfs sourceforge
lists and my experience of stock NFS as of over a year ago and the NFS
patches since then.

[2]. linux v3 works flawlessly against IRIX 6.2 + ONC3 updates, both
as client and server, for me.

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

Re: files bigger than 2 GB

[Matti Aarnio]

On Tue, Sep 12, 2000 at 05:15:52PM +0200, Arnaud Installe wrote:
> First of all, thanks to all of you for your responses.  :-)  I was under
> the impression 2.4 still didn't have large file support, as I seem to
> recall ssize_t still was 32 bits.

The LFS specification defined  loff_t for 64-bit offset value.
The   ssize_t  will not change.

> On Tue, Sep 12, 2000 at 04:25:02PM +0200, Andreas Jaeger wrote:
> > > Arnaud Installe writes:
> > 
> >  > Hello,
> >  > I need support for files larger than 2GB.  What's the status for that ?  
> >  > AFAIK neither 2.2 nor 2.4-test support that out of the box.  Can anyone
> >  > point me to a good link for patches ?  Apart from the kernel, does
> >  > anything else need changes for large file support ?
> > 
> > 2.4.0test7 has all the LFS (large file support) in it.  It will work
> > on ext2 - but e.g. not on NFSv2.
> 
> So how about ReiserFS ?  And Coda ?

ReiserFS: Propably works
EXT2: works
Coda: Not (local cache issues, protocol is ok.)
UFS:  works (although not complete vs. O_LARGEFILE flag use.)
NFSv2:protocol is limited to 2G-1
NFSv3:protocol is ok, not sure of Linux implementation status.
SAMBA:works (but linux kernel SMBFS might be another story)

> Ok, thanks.
> 
> -- 
> Arnaud Installe [EMAIL PROTECTED]
> 
> "If you own a machine, you are in turn owned by it, and spend your time
>  serving it..."
> -- Marion Zimmer Bradley, _The Forbidden Tower_

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

Re: [patch] VIA IDE driver v2.3

[Andre Hedrick]

Vojtech,

How about putting the old credits list back in because if the code base
that you started with, please.

Andre Hedrick
The Linux ATA/IDE guy

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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Trond Myklebust]

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

 > Is there any solution that's available today, and doesn't
 > depend on using Linux in the server?  I suspect that we will
 > have to distribute a modified nfs client with our app, and
 > we're prepared to accept the cache invalidation (and reduced
 > performance it causes) for a technique that will work with any
 > NFS server and provide the level of guarantees we need.

 > Is there a solution that would allow the kind of guarantee our
 > software wants with non-linux nfsds without the cache-blowing
 > that the change I'm suggesting causes?

If you ensure that the file length is changed each time it is written
to, then the cache coherency checking will detect that, and a cache
invalidation is guaranteed to occur. That is something that will
normally work on all NFS implementations.

Relying on the sub-second timing fields is a much more
implementation-specific. It depends on the capabilities of both the
filesystem and the server OS.
Linux and the knfsd server code could easily be modified to provide
such a service, but the problem (as I've stated before) is that you
need to save the time somewhere on disk. I believe currently ext2
provides only 32 bits of storage for mtime (though perhaps somebody
else could comment on that).
UFS does provide a 64-bit storage space for mtime. It would surprise
me if the other *NIX implementations aren't using this to improve NFS
cache consistency.

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

Re: Linux 2.2.18pre4

[Paul Jakma]

On Tue, 12 Sep 2000, Alan Cox wrote:

> They exist in the same way. You update stuff in controlled careful
> steps and you change troublesome drivers very early in a patch
> release - eg never touching tulip except early on
> 

true. as i said before i'm glad we have such a 'tight' stable kernel
maintainer. :)

the problem is, NFS updates /never/ make it in - well once, but even
then not the complete NFSv2 update.

as for tulip, i know what you mean. however, i think in this case
you'd be very hard pressed to find anyone for whom the patches are
anything but a vast improvement.

anyway... i've gone hoarse now. better stop. :)

regards,

Paul Jakma

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

Re: Test 8 Kernel Unable to get the password prompt?

[FORT David ou popo]

Miles Lane wrote:
On Mon, 11 Sep 2000, David Freedom wrote:
> I tried configuring the kernel to the least amount of
> configured options to almost none and I still cannot
> get the password prompt.
>
> My system hangs and is unable to do anything.
> unfortunetly the only thing I can do is power down my
> PC the incorrect and most unfortunate way leading to
> filesys errors upon reboot to an older saved kernel
> image.
Are you getting both the username and password prompts
and then getting nothing after entering the password?
This is a behavior I am seeing on a laptop Pentium II.
In my case, I can CTRL-ALT-F[1-6] to get to another
VT.  All attempts to log in any VT display meet the same
fate.  Also, attempting to log in using GDM fail in
this way.  In my case, the UI GDM continues to respond.
Lastly, trying to CTRL-ALT-DEL to initiate a shutdown
does cause the TERM and KILL signals to be sent to
all processes.  Then the shutdown process locks up
after a message is printed about unloading the
keyboard driver.
Interestingly, if I boot in single mode ("linux single"
at the boot prompt), and then load GDM, I am able to
log on with no trouble.
I have sent a message to the maintainer of the
shadow-utils package, but have gotten no response.
I suspect this problem has to do with a fsck-up on
my part in getting util-linux configured properly when
I built it.  I rebuilt util-linux with the sources
pointed to by Changes several development kernel
revisions ago (~2.4.0-test7).
    Miles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Hum, i used to have such problems, they seems to disappear when i stopped
including
ACPI support.
hope, it helped...
-- 
%--IRIN->-Institut-de-Recherche-en-Informatique-de-Nantes-%
% FORT David, %
% 7 avenue de la morvandière 0240726275   %
% 44470 Thouare, France  [EMAIL PROTECTED] %
% ICU:54999224   AIM: enlighted popo [EMAIL PROTECTED] %  
%--LINUX-HTTPD-PIOGENE%
%  -datamining    |   .~. %
%  -networking    |   /V\    L  I  N  U  X    %
%  -opensource    |  // \\ >Fear the Penguin< %
%  -GNOME/enlightenment/GIMP  | /(   )\   %
%   feel enlighted    |  ^^-^^    %
%-%
.
 

Re: [PATCH][RFC] check fib6_lookup_1 return in fib6_lookup_1

[kuznet]

Hello!

>   fib6_lookup_1 can return NULL, please consider applying.

Arnaldo, if you decided to play with subtrees, BEWARE!

I never debugged this code and commented out it exactly because
of this reason.

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

Re: 2.2.18pre2aa2 and patches for 2.2.18pre3

[lamont]

On Mon, 11 Sep 2000, Andrea Arcangeli wrote:
> On Fri, 8 Sep 2000, Matthew Hawkins wrote:
> >Something between bigmem and his big VM changes makes reiserfs
> >uncompilable. [..]
> 
> It's due LFS. Chris should have a reiserfs patch that compiles on top of
> 2.2.18pre2aa2, right? (if not Chris, I can sure find it because the server
> that was reproducing the DAC960 SMP lock inversion was running
> 2.2.18pre2aa2+IKD on top of an huge reiserfs fs)
 
the LFS patch is also incompatible with the NFSv3 patches.  

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

(reiserfs) Re: More on 2.2.18pre2aa2

[Alan Cox]

> That problem: the original elevator code did not schedule I/O particularly
> fairly under certain I/O usage patterns. So it got fixed.

No it got hacked up a bit.

> Now, I see people trying to introduce the concept of elapsed time into
> that fix, which smells strongly of hack. How will this hack be cobbled

Actually my brain says that elapsed time based scheduling is the right thing
to do. It certainly works for networks


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

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Trond Myklebust]

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

 > But "ctime and file size are the same" does not prove that the
^ mtime
 > file is unchanged.  That's the root of this problem, and why
 > NFS_CACHEINV(inode) is not enough to ensure coherency.

Yes, but I just demonstrated that messing around with the client is a
hack, not a solution to this situation.
It's a hack because it is not compatible with the expected behaviour
of NFS clients. The NFSv4 draft demonstrates what the expected
behaviour is, and illustrates what we have to implement for a generic
fix (one that works on all clients -- not hacked Linux ones).

This is why I'm saying the correct solution is to get the server to
change mtime. To use the 'microseconds' field that is supported by the
NFS protocol, and that we currently set to 0.

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

Re: Using Yarrow in /dev/random

[Sandy Harris]

"Theodore Y. Ts'o" wrote:
> 
>Date: Tue, 12 Sep 2000 09:56:12 +
>From: Pravir Chandra <[EMAIL PROTECTED]>
> 
>i agree that the yarrow generator does place some faith on the crypto
>cipher and the accumulator uses a hash, but current /dev/random
>places faith on a crc and urandom uses a hash.
> 
> No, not true.  The mixing into the entropy pool uses a twisted LFSR, but
> all outputs from the pool (to either /dev/random or /dev/urandom)
> filters the output through SHA-1 as a whitener.  The key here, though,
> and what makes this fundamentally different from yarrow, is that since
> we're feeding the entire (large) entropy pool through SHA-1, even if the
> SHA-1 algorithm is very badly broken (say as in what's been happening
> with MD5), as long as there's sufficient entropy in the pool, the
> adversary can define but minimal information about the pool, since the
> 8192 -> 160 bit transform has to lose information by definition.

It seems clear that /dev/random's twisting and large pool do a far better
job of the entropy collection stage than Yarrow's simple hash and tiny
pool. Methinks the Yarrow developers would argue that their mechanism is
enough, but I'm not convinced of that.

Even if I were, I would see no reason to change that part of /dev/random.
We have a working entropy collector
based on apparently sound design principles
that has been fairly heavily analyzed
that fits cleanly into the kernel
Why even consider replacing it with one something new that is clearly
weaker?

Adding a second stage along Yarrow-ish lines is much more plausible.
That is the area where Yarrow (or my proposed stuff based on Rijndael,
or the second pool added in the 2.4 driver) seems to have some clear
advantages.  

>i also agree that the entropy pools are small, but the nature of the
>hash preserves the amount of entropy that has been uses to create the
>state of the pools. basically, if the pool size is 160 bits (hash
>output) its state can be built by more than 160 bits of entropy, its
>just that adding entropy after that increases the unguessability
>(conventional attacks) of the state but brute forcing the state is
>still 2^160.

One problem with that is that both the entropy inputs and the output loads
may be quite bursty, so you need a substantial buffer to smooth things
out. Consider a server that does little all night then gets heavy demand
around 9 AM. With /dev/random's 4K bit pool and a bit of luck, it may
have enough entropy tucked away by morning to cope well. If the design
limits the entropy it can store to 160 bits, then there may be a problem.

> Which is just another way of saying that yarrow is only a cryptographic
> random number generator whose maxmum entropy storage is 160 bits.

As I see it, /dev/random handles entropy collection better but likely
has things to learn (or already has in 2.4) from the Yarrow design on
the output side.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

[Alan Cox]

> If we have a purely Linux-specific hack to ensure cache coherency,
> that will still corrupt the cache on those *NIX clients that use
> ordinary cache coherency checking (i.e. checking mtime + file size)
> rather than cache invalidation.

Its what Solaris implements and what SunOS back down to 3.x implements. I
wouldnt be suprised if others do likewise ?

> It also avoids a lot of unnecessary cache flushing. Imagine having to
> reread your entire mailbox every time you open the file whether or not
> a new message has arrived. Ugh...

Interesting point.

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

Re: Availability of kdb

[Jeff V. Merkey]

Ted,

I am looking at these sources as well.  One thing I went back and looked
at was related to a comment from Mike G. I believe regarding drivers
conflicts with int 0x13 requests potentially hosing the IDE driver.  In
MANOS, since DOS is resident underneath the OS, I instrumented the code
a lot like was done in earlier versions of Windows and NT.  I hook the
MSDOS disk interrupts and reprogram the PIC to move the first PIC
interrupt mappings to start at entry 0x28 
in the IDT tables instead of overlaying the first 16 exception entries
which is how DOS leaves them by default.  When I call into DOS, I
restore the previous PIC1 mappings to their previous DOS settings and
restore the DOS IVT to allow the DOS BIOS drivers to service the disk. 
In the MANOS case, DOS has enough smarts to reset the IDE chipset to
it's default values.  I am looking  over the BIOS int 0x13 code, and it
looks like it may be possible to co-host an int 0x13 ext2 driver and the
Linux IDE driver as is done in NetWare today.  I know this is possible
because I do it in MANOS now, and NetWare also supports mutiple IDE
drivers (DOS and NetWare) to share the chipset.

:-)

Jeff

"Theodore Y. Ts'o" wrote:
> 
>Date: Mon, 11 Sep 2000 17:51:20 -0600
>From: "Jeff V. Merkey" <[EMAIL PROTECTED]>
> 
>I support source level in the kernel.  Based on Andi Klein's review, I
>have grabbed ext2utils and am looking at a minimal int 0x13 interface to
>load files into memory.  hardest problem here for Linux is having a tiny
>FS that won't deadlock to load source files.
> 
> You may also want to take a look at libext2fs which is part of
> e2fsprogs.  It has a I/O abstraction which isolates the raw disk I/O
> from the rest of the library.  (There's a unix_io.c and an nt_io.c; in
> fact, there's even a dos_io.c which uses the int 0x13 interface,
> although it'll probably require some reworking of the code to translate
> it away from TurboC.)
> 
> In libext2fs, look at the fileio.c module; once you open the ext2
> filesystem, you open, read, seek, etc. individual ext2 files in the ext2
> filesystem.  I'm not sure the file write code works if it needs to
> extend the file; and it's been the least tested of all of the functions,
> but you wouldn't need this for a kernel debugger anyway.
> 
> - Ted
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Test 8 Kernel Unable to get the password prompt?

[Steven Walter]

If you're logging in as root, this is probably a result of the VT not
being named in /etc/securetty.  Devfsd mucks up the names, so you can
either include "1," which would allow root logins from pseudo-terminals
and other insecure places, or upgrade your util-linux to a newer
version; I'm not sure what is new enough. 

On Mon, Sep 11, 2000 at 09:32:37PM -0700, Miles Lane wrote:
> 
> 
> On Mon, 11 Sep 2000, David Freedom wrote:
> 
> > I tried configuring the kernel to the least amount of
> > configured options to almost none and I still cannot
> > get the password prompt.
> > 
> > My system hangs and is unable to do anything. 
> > unfortunetly the only thing I can do is power down my
> > PC the incorrect and most unfortunate way leading to
> > filesys errors upon reboot to an older saved kernel
> > image.
> 
> Are you getting both the username and password prompts
> and then getting nothing after entering the password?
> This is a behavior I am seeing on a laptop Pentium II.
> In my case, I can CTRL-ALT-F[1-6] to get to another
> VT.  All attempts to log in any VT display meet the same
> fate.  Also, attempting to log in using GDM fail in
> this way.  In my case, the UI GDM continues to respond.
> 
> Lastly, trying to CTRL-ALT-DEL to initiate a shutdown
> does cause the TERM and KILL signals to be sent to
> all processes.  Then the shutdown process locks up
> after a message is printed about unloading the 
> keyboard driver.
> 
> Interestingly, if I boot in single mode ("linux single"
> at the boot prompt), and then load GDM, I am able to 
> log on with no trouble.
> 
> I have sent a message to the maintainer of the 
> shadow-utils package, but have gotten no response.
> 
> I suspect this problem has to do with a fsck-up on
> my part in getting util-linux configured properly when
> I built it.  I rebuilt util-linux with the sources
> pointed to by Changes several development kernel 
> revisions ago (~2.4.0-test7).
> 
>   Miles
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Recurring Oops in 2.2.12-20smp plus ext2_free_blocks.

[Ralph Corderoy]

Hi,

Alan Cox wrote:
> > I'd like to find more detail of the rare corruption so I can see if
> > it matches what we're experiencing, is it more likely with an SMP
> > machine, etc.  Is there an archive of patches that go into a
> > particular version anywhere?
> 
> No but all pre releases can be found in
> pub/linux/kernel/people/alan/..
> 
> There are a lot of other ways you can see stuff that results in
> dcache corruption that isnt the cause - everything from hardware to
> scribbles by drivers

If it was hardware, say one of the two processors was flaky, wouldn't I
expect to see corrupted pointers being dereferenced in other sections
of code or is the dcache data structure particular susceptible?


Ralph.

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

Re: [PATCH *] VM and scheduler patch

[Rik van Riel]

On Tue, 12 Sep 2000, Rui Sousa wrote:
> Rik van Riel wrote:

> > The second patch is a new version of the VM patch, [snip]
> > http://www.surriel.com/patches/
> 
> Gave your patch a try, only the vm one. I applied it against
> 2.4.0-test8 (final) with some warnings so the bug report may not
> be valid. I got this Oops when slightly stressing the system:

Juan Quintela gave me a warning about this patch
earlier today and I have already released a fixed
version on my web page ;)

regards,

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

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

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

Re: [PATCH *] VM and scheduler patch

[Rui Sousa]

Rik van Riel wrote:
> 
> Hi,
> 
> last night I made a few new patches. For one there's a
> quick scheduler patch which makes the scheduler consider
> CPU usage on a somewhat longer term as well as on the
> short term, giving CPU time away a bit more fairly when
> a process sleeps for a few timeslices.
> 
> The second patch is a new version of the VM patch, packed
> with suggestions from Davem (thanks Dave). The __alloc_pages()
> function has been cleaned up and drop_behind() might actually
> work now.
> 
> The balance between clean and dirty pages has also been changed
> a bit and I can run a fairly smooth system even when there's
> disk write IO going on...
> 
> The patches are available at the usual place:
> 
> http://www.surriel.com/patches/
> 

Gave your patch a try, only the vm one. I applied it against 2.4.0-test8 (final)
with some warnings so the bug report may not be valid.
I got this Oops when slightly stressing the system:

kernel: Unable to handle kernel NULL pointer dereference at virtual address 00ab 
kernel:  printing eip: 
kernel: c012a4b5 
kernel: *pde =  
kernel: Oops:  
kernel: CPU:0 
kernel: EIP:0010:[__alloc_pages+125/580] 
kernel: EFLAGS: 00010202 
kernel: eax: 0246   ebx: 0007   ecx: c01f2dac   edx: c29b1e5c 
kernel: esi: 0001   edi: c01f3148   ebp:    esp: c2ecbec0 
kernel: ds: 0018   es: 0018   ss: 0018 
kernel: Process mozilla-bin (pid: 11556, stackpage=c2ecb000) 
kernel: Stack:  c2ecbf58 c1abb900 c31d9300 0007 0001 c01f3134 c012a690 
 
kernel:c013b1e3 c2677360 c1abb900 0145 1000 c01bad24 c1abb900 c31d9300 
 
kernel:c2ecbf58 c1abb900 c1abb900 c018f44f c1abb900 c31d92e4 c2ecbf58  
 
kernel: Call Trace: [__get_free_pages+20/32] [__pollwait+51/140] [unix_poll+36/148]
[sock_poll+31/36] [do_select+287/520] [sys_select+1078/1448] [system_call+51/56]  
kernel: Code: 83 bb a4 00 00 00 00 75 19 68 52 01 00 00 68 bf a2 1c c0 68  

Maybe you cleanned __alloc_pages() to much...

The machine is a UP Celeron 366Mhz with 64Mb (no SMP or HIGHMEM configured)
 
Rui Sousa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Signal handling different for root and others

[Andi Kleen]

On Tue, Sep 12, 2000 at 03:09:40PM +0200, jury gerold wrote:
> Andi Kleen wrote:
> > 
> > On Tue, Sep 12, 2000 at 11:33:31AM +0100, Alan Cox wrote:
> > > > > Normal users are only able to create a SIGIO signal when connecting.
> > > >
> > > > That's very unlikely. TCP does not propagate gid/uid information over sockets,
> > > > not even over localhost.
> > >
> > > However if something is looking at current-> and the test is on localhost
> > > then it starts to become quite believable
> > 
> > The SIGIO is on the receiving side, not on the sending. current is always
> > the same.
> > 
> > -Andi
> 
> I know, the description was not very clear.
> But the attached program is very easy to compile and start.
> I tried to extract only what's necessary from the involved code.
> There are no hidden trojans inside, i promise.

Never mind I found it.  send_siginfo indeed checks current and it is called
via sock_wake_async from net_bh. Sorry for dismissing your report at first,
I have no other excuse as that it was very late yesterday night.

The reason for the problem is that asm/siginfo.h messes up between
user signals and kernel queued signals. SI_SIGINFO is defined as a 
user signal, but it is really a kernel signal (should be >= 0).

Thus SI_FROMUSER returns true for SI_SIGINFO, which leads to the signal
function checking checking current for credentials, which leads to the
weird behaviour of the SIGIO dependent on the sending process (or a random
process that just happens to run while the packet is processed)
[Stephen, I think that will explain many random queued SIGIO failures in the
past]

Here is an cheap workaround. it'll break programs that pass SI_SIGINFO
to sigqueue(). I don't think this is a problem.
I only fixed i386, other architectures may have the same
problem.

The patch should fix the problem, could you try it ? 

--- kernel/signal.c-o   Tue Sep 12 17:43:28 2000
+++ kernel/signal.c Tue Sep 12 17:53:40 2000
@@ -820,7 +820,7 @@
 
/* Not even root can pretend to send signals from the kernel.
   Nor can they impersonate a kill(), which adds source info.  */
-   if (info.si_code >= 0)
+   if (!SI_FROMUSER())
return -EPERM;
info.si_signo = sig;
 
--- include/asm-i386/siginfo.h-oTue Sep 12 17:55:00 2000
+++ include/asm-i386/siginfo.h  Tue Sep 12 17:56:37 2000
@@ -89,8 +89,8 @@
 #define SI_ASYNCIO -4  /* sent by AIO completion */
 #define SI_SIGIO   -5  /* sent by queued SIGIO */
 
-#define SI_FROMUSER(siptr) ((siptr)->si_code <= 0)
-#define SI_FROMKERNEL(siptr)   ((siptr)->si_code > 0)
+#define SI_FROMUSER(siptr) ((siptr)->si_code <= 0 && (siptr)->si_code!=SI_SIGIO)
+#define SI_FROMKERNEL(siptr)   ((siptr)->si_code > 0 || (siptr)->si_code==SI_SIGIO)
 
 /*
  * SIGILL si_codes



-Andi

















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

Re: files bigger than 2 GB

[Andreas Jaeger]

> Arnaud Installe writes:

 > First of all, thanks to all of you for your responses.  :-)  I was under
 > the impression 2.4 still didn't have large file support, as I seem to
 > recall ssize_t still was 32 bits.
off64_t is the type you want to look at.

 > On Tue, Sep 12, 2000 at 04:25:02PM +0200, Andreas Jaeger wrote:
>> > Arnaud Installe writes:
>> 
>> > Hello,
>> > I need support for files larger than 2GB.  What's the status for that ?  
>> > AFAIK neither 2.2 nor 2.4-test support that out of the box.  Can anyone
>> > point me to a good link for patches ?  Apart from the kernel, does
>> > anything else need changes for large file support ?
>> 
>> 2.4.0test7 has all the LFS (large file support) in it.  It will work
>> on ext2 - but e.g. not on NFSv2.

 > So how about ReiserFS ?  And Coda ?
The 2.2 version of ReiserFS as distributed with SuSE 7.0 doesn't
support LFS.  The 2.4 should - but better ask on the list.  You need
to find out for every file system.  I have no information about coda.

Andreas
[...]
-- 
 Andreas Jaeger
  SuSE Labs [EMAIL PROTECTED]
   private [EMAIL PROTECTED]
http://www.suse.de/~aj
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Signal handling different for root and others

[gerold]

Andi Kleen wrote:
> 
> Never mind I found it.
> 
> The patch should fix the problem, could you try it ?
> 
> -Andi

It work's now.
Nothing is broken at least on this machine.
That was quick.

2.4.0-x does not have the problem.

Thanks

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

2.2.17 & VM: do_try_to_free_pages failed / eepro100

[octave klaba]

Hello,
On a high load server, kernel has some errors:

VM: do_try_to_free_pages failed for httpd...
VM: do_try_to_free_pages failed for httpd...
eth0: Too much work at interrupt, status=0x4050.
eth0: Too much work at interrupt, status=0x4050.

is there somewhere the new version of driver for eepro100 
to make a test ?

Thanks
octave

Linux version 2.2.17 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux 
(egcs-1.1.2 release)) #1 Tue Sep 5 11:21:35 CEST
2000
Detected 467735 kHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 933.89 BogoMIPS
Memory: 128284k/131008k available (772k kernel code, 412k reserved, 1496k data, 44k 
init)
Dentry hash table entries: 16384 (order 5, 128k)
Buffer cache hash table entries: 131072 (order 7, 512k)
Page cache hash table entries: 32768 (order 5, 128k)
VFS: Diskquotas version dquot_6.4.0 initialized
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Celeron (Mendocino) stepping 05
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED])
PCI: PCI BIOS revision 2.10 entry at 0xf0720
PCI: Using configuration type 1
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0 for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 131072 bhash 65536)
Starting kswapd v 1.5 
Serial driver version 4.27 with no serial options enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
pty: 256 Unix98 ptys configured
RAM disk driver initialized:  16 RAM disks of 4096K size
loop: registered device at major 7
PIIX4: IDE controller on PCI bus 00 dev 21
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xb400-0xb407, BIOS settings: hda:DMA, hdb:pio
keyboard: Too many NACKs -- noisy kbd cable?
keyboard: Too many NACKs -- noisy kbd cable?
hda: IBM-DPTA-372050, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: IBM-DPTA-372050, 19574MB w/1961kB Cache, CHS=39770/16/63, UDMA
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
eepro100.c:v1.09j-t 9/29/99 Donald Becker 
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin 
<[EMAIL PROTECTED]> and others
eth0: Intel PCI EtherExpress Pro100 82557, 00:E0:18:A8:B6:EB, I/O at 0xb800, IRQ 10.
  Board assembly 668081-002, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0x24c9f043).
  Receiver lock-up workaround activated.
eepro100.c:v1.09j-t 9/29/99 Donald Becker 
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin 
<[EMAIL PROTECTED]> and others
Partition check:
 hda: hda1 hda2 < hda5 hda6 hda7 >
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 44k freed
Adding Swap: 131504k swap-space (priority -1)

Amicalement,
oCtAvE 

"Peu importe ce qu'il y a de l'autre côté.
Tout ce qu'on laisse ici n'est qu'une histoire
dont on se souviendra ou pas."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

elevator code

[Rik van Riel]

Hi Jeff,

since I vaguely remember an email from you describing how
you spent  tweaking and changing
the disk IO elevator in Netware, and since we might want
to improve the Linux elevator sort a bit, could you give
us some hints on what to do and where not to waste our
time? ;)

thanks,

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

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

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

Re: [linux-audio-dev] Ingo's lowlatency-test7-A0 excellent latencies (<1msec), but kernel filesync problems ...

[Chris Baugher]

On Wed, 13 Sep 2000, Benno Senoner wrote:
> Hi folks,
> I benchmarked Ingo's  lowlatency-2.4.0-test7-A0  kernel
> (http://people.redhat.com/mingo/lowlatency-patches/lowlatency-2.4.0-test7-A0)
> 
> I can only say that it looks VERY promising ( < 1msec latencies !)
> But there seems to be problems with the kernel disk sync code:
> After the disk stress test, I call the "sync" command, but unfortunately
> the sync process hangs and eats 100% of the CPU (but no kernel crash)

I also had similar problems with with not being able to complete the tests
because of the sync call hanging. The tests that did finish looked really
good though!

> 
> see the graph here:
> http://www.linuxdj.com/latency/2.4.0-test7-lowlatency-A0/2048.html

Looks alot like the graphs I got.


> (disk copy and disk read tests are missing because, of the hanging sync)
> 
> Is this perhaps related to the truncate bug fixed in -test8 ?
> 
> Ingo, any ideas what the cause of the hang could be ?
> (let us know please when you port the patch to test8)

Yes, definitely!

Chris|

> 
> Anyway if the remaining bugs can be fixed, then I think that that
> all low latency needs of 2.4 users will be satisfied.
> (my reference mark is being able to stay below 1.5 - 2msec, which
> is needed for perceptually delayfree realtime audio processing) 
> 
> PS: looking at the results Chris posted,
> http://cygnus.ipal.org/results-2.4.0t8-ll/3x256.html
> Andrew's minimalistic approach looks promising too and seems to
> be able to guarantee <5msec latencies under high load. 
> 
> cheers,
> Benno.
> 

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

does anyone have a minimal opendir/readdir/closedir implementation?

[Felix von Leitner]

For my project "dietlibc" (http://www.fefe.de/dietlibc/) I am looking
into implementing directory access now.

The kernel interface seems to be:

  * supply an O_DIRECTORY flag to open()
  * a getdents system call

You don't read on the fd in readdir, you call getdents.
getdents reads n struct dirents.  You can't say how many you want, you
can only limit the bytes it copies.  Oh, and that's a kernel struct
dirent, which is subtly different from the glibc one (it does not
contain the d_type field).

So a "natural" approach would be to have opendir call getdents on a
"big" buffer to get all the records and then have readdir return each
one.  But... how do I know how much space to reserve?  lseek can find
out the file size, but directories under /proc have a size of 0.

glibc seems to handle this by defining an elaborate buffer data structure.



As the name implies, dietlibs seeks to implement functions with minimal
code size.  Speed is also important, but not as much as code size.
Strict POSIX compliance is nice if it doesn't increase the code size
much.

How am I to implement these functions small and efficiently?  There
surely is a better way than having a buffer management and translating
data structures, right?  Since this is not a kernel issue in the strict
sense, please reply directly and not to the mailing list.

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

Plug-in Schedulers for Linux

[Scott Rhine]

A prototype of Plug-in Schedulers for Linux as loadable modules
(for 3 Linux versions), white paper, and a sample implementation of
plug-in "processor sets" utilities and documents available at :

http://resourcemanagement.unixsolutions.hp.com/WaRM/schedpolicy.html

Try it out + tell us what you think!

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

Duplicate messages

[Vern Hoxie]

Cc; [EMAIL PROTECTED]

Today, I received duplicate messages as posted by Rik van Riel to this
list.  Here are the headers from both messages.  Other than identical
Message-ID's, I can't discern where the duplicate originated.

Good Luck.

First message 

Received: (from uucp@localhost)
by zebra.alphacdc.com (8.9.1/8.9.1) id CVH25066
for [EMAIL PROTECTED]; Tue, 12 Sep 2000 02:01:09 -0600
Received: from vger.kernel.org (vger.kernel.org [199.183.24.194])
by scicom.alphacdc.com (8.9.3/8.9.3-SCICOM) with ESMTP
id BAA04261 for <[EMAIL PROTECTED]>; Tue, 12 Sep 2000 01:32:21 -0600 
(MDT)
Received: ([EMAIL PROTECTED]) by vger.kernel.org via listexpand
id ; Tue, 12 Sep 2000 03:29:33 -0400
Received: ([EMAIL PROTECTED]) by vger.kernel.org
id ; Tue, 12 Sep 2000 03:29:12 -0400
Received: from brutus.conectiva.com.br ([200.250.58.146]:38126 "EHLO
duckman.distro.conectiva") by vger.kernel.org with ESMTP
id ; Tue, 12 Sep 2000 03:29:08 -0400
Received: from localhost (riel@localhost)
by duckman.distro.conectiva (8.10.2/8.10.2) with ESMTP id e8C7N5001859;
Tue, 12 Sep 2000 04:23:05 -0300
X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs
Date:   Tue, 12 Sep 2000 04:23:05 -0300 (BRST)
From: Rik van Riel <[EMAIL PROTECTED]>
X-Sender: [EMAIL PROTECTED]
To: Matthew Hawkins <[EMAIL PROTECTED]>
cc: Chris Mason <[EMAIL PROTECTED]>, Andrea Arcangeli <[EMAIL PROTECTED]>,
Ed Tomlinson <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: More on 2.2.18pre2aa2
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [EMAIL PROTECTED]
Precedence: bulk
X-Mailing-List: [EMAIL PROTECTED]

Second message 

>From [EMAIL PROTECTED]  Tue Sep 12 02:01:10 2000
Received: (from uucp@localhost)
by zebra.alphacdc.com (8.9.1/8.9.1) id CVH25070
for [EMAIL PROTECTED]; Tue, 12 Sep 2000 02:01:10 -0600
Received: from vger.kernel.org (vger.kernel.org [199.183.24.194])
by scicom.alphacdc.com (8.9.3/8.9.3-SCICOM) with ESMTP
id BAA04265 for <[EMAIL PROTECTED]>; Tue, 12 Sep 2000 01:32:22 -0600 
(MDT)
Received: ([EMAIL PROTECTED]) by vger.kernel.org via listexpand
id ; Tue, 12 Sep 2000 03:30:03 -0400
Received: ([EMAIL PROTECTED]) by vger.kernel.org
id ; Tue, 12 Sep 2000 03:29:53 -0400
Received: from 1Cust104.tnt1.santa-fe.nm.da.uu.net ([63.30.216.104]:7693 "EHLO
junior.ournet.home") by vger.kernel.org with ESMTP
id ; Tue, 12 Sep 2000 03:29:25 -0400
Received: from root by junior.ournet.home with scanned_ok (Exim 3.16 #1)
id 13YkWv-0001LY-00; Tue, 12 Sep 2000 01:30:57 -0600
Received: from hackvan.com ([206.80.31.242] ident=qmailr)
by junior.ournet.home with smtp (Exim 3.16 #1)
id 13YkWt-0001L3-00
for [EMAIL PROTECTED]; Tue, 12 Sep 2000 01:30:55 -0600
Received: (qmail 11161 invoked by uid 530); 12 Sep 2000 07:30:01 -
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Delivered-To: mailing list [EMAIL PROTECTED]
Received: (qmail 11152 invoked from network); 12 Sep 2000 07:29:55 -
X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs
Date:   Tue, 12 Sep 2000 04:23:05 -0300 (BRST)
From: Rik van Riel <[EMAIL PROTECTED]>
X-Sender: [EMAIL PROTECTED]
To: Matthew Hawkins <[EMAIL PROTECTED]>
cc: Chris Mason <[EMAIL PROTECTED]>, Andrea Arcangeli <[EMAIL PROTECTED]>,
Ed Tomlinson <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: (reiserfs) Re: More on 2.2.18pre2aa2
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [EMAIL PROTECTED]
Precedence: bulk
X-Mailing-List: [EMAIL PROTECTED]

vern

-- 
Vernon C. Hoxie [EMAIL PROTECTED]
3975 W. 29th Ave.uucp: 303-455-2670
Denver, Colo., 80212voice: 303-477-1780
   Depression is merely anger without enthusiasm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[linux-audio-dev] Ingo's lowlatency-test7-A0 excellent latencies (<1msec), but kernel filesync problems ...

[Benno Senoner]

Hi folks,
I benchmarked Ingo's  lowlatency-2.4.0-test7-A0  kernel
(http://people.redhat.com/mingo/lowlatency-patches/lowlatency-2.4.0-test7-A0)

I can only say that it looks VERY promising ( < 1msec latencies !)
But there seems to be problems with the kernel disk sync code:
After the disk stress test, I call the "sync" command, but unfortunately
the sync process hangs and eats 100% of the CPU (but no kernel crash)

see the graph here:
http://www.linuxdj.com/latency/2.4.0-test7-lowlatency-A0/2048.html

(disk copy and disk read tests are missing because, of the hanging sync)

Is this perhaps related to the truncate bug fixed in -test8 ?

Ingo, any ideas what the cause of the hang could be ?
(let us know please when you port the patch to test8)

Anyway if the remaining bugs can be fixed, then I think that that
all low latency needs of 2.4 users will be satisfied.
(my reference mark is being able to stay below 1.5 - 2msec, which
is needed for perceptually delayfree realtime audio processing) 

PS: looking at the results Chris posted,
http://cygnus.ipal.org/results-2.4.0t8-ll/3x256.html
Andrew's minimalistic approach looks promising too and seems to
be able to guarantee <5msec latencies under high load. 

cheers,
Benno.