date:20010525




On Thu, 24 May 2001, Aaron Lehmann wrote:

 explicit about defining source code:
   The source code for a work means the preferred form of the work for
   making modifications to it.

Erm... May I point you to the sysdep/libm-ieee754/e_j0.c? There's a bunch
of constants of unknown origin. If you want to modify the implementation
you most certainly want more than numeric values.

Same goes for any tables that contain anything besides well-known constants.

Should we file bug reports against glibc?

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

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Aaron Lehmann


On Fri, May 25, 2001 at 02:34:05AM -0400, Alexander Viro wrote:
 Should we file bug reports against glibc?

invsqrtpi=  5.64189583547756279280e-01
Inverted square root of pi. Want to file a bug on Pi?

tpi  =  6.36619772367581382433e-01,
R0/S0 on [0, 2.00]

I'm not sure what R and S are, but the glibc developers probably are.
IMHO poorly documented code is different from binary-only code.
However, it appears to be a sketchy line.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ac15 and 2.4.5-pre6, pwc format conversion

2001-05-25 Thread Norbert Preining


Hi!

According to ac ChangeLog:
o   Rip format conversion out of the pwc driver (me)
| It belongs in user space..

This change is included in 2.4.5-pre6, but
drivers/usb/pwc-uncompress.c
still relies on this files:
gcc -D__KERNEL__ -I/usr/src/linux-2.4.5.6-packet/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=k6 
-DMODULE   -DEXPORT_SYMTAB -c pwc-uncompress.c
pwc-uncompress.c:25: vcvt.h: No such file or directory
pwc-uncompress.c: In function `pwc_decompress':
pwc-uncompress.c:158: warning: implicit declaration of function `vcvt_420i_rgb24'
pwc-uncompress.c:161: warning: implicit declaration of function `vcvt_420i_bgr24'
pwc-uncompress.c:164: warning: implicit declaration of function `vcvt_420i_rgb32'
pwc-uncompress.c:167: warning: implicit declaration of function `vcvt_420i_bgr32'
pwc-uncompress.c:171: warning: implicit declaration of function `vcvt_420i_yuyv'
pwc-uncompress.c:185: warning: implicit declaration of function `vcvt_420i_420p'

Best wishes

Norbert

PS: Please reply by email since I am not subscribed and I skim the
mailing list via the web archive.
THANKS.

-- 
ciao
norb

+---+
| Norbert Preining  http://www.logic.at/people/preining |
| University of Technology Vienna, Austria[EMAIL PROTECTED] |
| DSA: 0x09C5B094 (RSA: 0xCF1FA165) mail subject: get [DSA|RSA]-key |
+---+
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reg ramfs mkfs

2001-05-25 Thread SATHISH.J


Hi all,

Please excuse me if my doubt is silly but do help me in answering this.

I compiled the ramfilesystem under fs/ramfs and got the object file
inode.o.

1.Should I do insmod to insert this module. 
2.After inserting this module how can I use mkfs to make this file
system befor mounting it.

Please help with the answers as I am highly confused.

Thanks in advance,

Regards,
sathish.j

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

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h




On Thu, 24 May 2001, Aaron Lehmann wrote:

 On Fri, May 25, 2001 at 02:34:05AM -0400, Alexander Viro wrote:
  Should we file bug reports against glibc?
 
 invsqrtpi=  5.64189583547756279280e-01
 Inverted square root of pi. Want to file a bug on Pi?

Nope. Well-known constant.

 tpi  =  6.36619772367581382433e-01,
 R0/S0 on [0, 2.00]
 
 I'm not sure what R and S are, but the glibc developers probably are.
 IMHO poorly documented code is different from binary-only code.
 However, it appears to be a sketchy line.

It _is_ a sketchy line. In that case you can be damn sure that constants
had been derived from other form. And you need that other form to do any
modifications that wouldn't turn the thing into random junk.

Normally you don't need it, unless you feel that one you have in glibc is
not good enough for your needs or want to experiment with modifying it.
Or analise the thing.

It's pretty similar to the case in question. The only difference is that
information needed to implement Bessel functions from scratch is easier
to find. However, it will be reimplementing from scratch. It won't help
you to answer any questions about the accuracy of implementation in glibc,
etc.

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

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Andreas Jaeger


Aaron Lehmann [EMAIL PROTECTED] writes:

 On Fri, May 25, 2001 at 02:34:05AM -0400, Alexander Viro wrote:
  Should we file bug reports against glibc?
 
 invsqrtpi=  5.64189583547756279280e-01
 Inverted square root of pi. Want to file a bug on Pi?
 
 tpi  =  6.36619772367581382433e-01,
 R0/S0 on [0, 2.00]
 
 I'm not sure what R and S are, but the glibc developers probably are.

We have comments in the code that state how j0 is build, and R0/S0
come from some expansion:
 * Bessel function of the first and second kinds of order zero.
 * Method -- j0(x):
 *  1. For tiny x, we use j0(x) = 1 - x^2/4 + x^4/64 - ...
 *  2. Reduce x to |x| since j0(x)=j0(-x),  and
 * for x in (0,2)
 *  j0(x) = 1-z/4+ z^2*R0/S0,  where z = x*x;
 * (precision:  |j0-1+z/4-z^2R0/S0 |2**-63.67 )

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h




On 25 May 2001, Andreas Jaeger wrote:

 We have comments in the code that state how j0 is build, and R0/S0
 come from some expansion:
  * Bessel function of the first and second kinds of order zero.
  * Method -- j0(x):
  *1. For tiny x, we use j0(x) = 1 - x^2/4 + x^4/64 - ...
  *2. Reduce x to |x| since j0(x)=j0(-x),  and
  *   for x in (0,2)
  *j0(x) = 1-z/4+ z^2*R0/S0,  where z = x*x;
  *   (precision:  |j0-1+z/4-z^2R0/S0 |2**-63.67 )
 
 Andreas

Sure. However, the question about choosing the polynomials stands.
(And no, I'm not proposing to go and bugger glibc folks over that ;-)

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

[PATCH] lp486e.c: check region removal

2001-05-25 Thread pazke


Hi all,

patch for lp486e.c network driver attached. 
Changes: check_region() call removed, added missing __init and __exit.

Best regards.

-- 
Andrey Panin| Embedded systems software engineer
[EMAIL PROTECTED]| PGP key: http://www.orbita1.ru/~pazke/AndreyPanin.asc


diff -ur -X /usr/dontdiff linux.vanilla/drivers/net/lp486e.c 
/linux/drivers/net/lp486e.c
--- linux.vanilla/drivers/net/lp486e.c  Mon May 21 23:49:44 2001
+++ /linux/drivers/net/lp486e.c Fri May 25 22:23:22 2001
@@ -971,16 +971,17 @@
volatile struct i596_private *lp;
unsigned char eth_addr[6] = { 0, 0xaa, 0, 0, 0, 0 };
unsigned char *bios;
-   int i,j;
-   static int probed = 0;
+   int i, j;
+   int ret = -ENOMEM;
+   static int probed;
 
if (probed)
return -ENODEV;
probed++;
 
-   if (check_region(IOADDR, LP486E_TOTAL_SIZE)) {
-   printk(lp486e: IO address 0x%x in use\n, IOADDR);
-   return -ENODEV;
+   if (!request_region(IOADDR, LP486E_TOTAL_SIZE, dev-name)) {
+   printk(KERN_ERR lp486e: IO address 0x%x in use\n, IOADDR);
+   return -EBUSY;
}
 
/*
@@ -989,7 +990,7 @@
dev-mem_start = (unsigned long)
kmalloc(sizeof(struct i596_private) + 0x0f, GFP_KERNEL);
if (!dev-mem_start)
-   return -ENOMEM;
+   goto err_out;
dev-priv = (void *)((dev-mem_start + 0xf)  0xfff0);
lp = (struct i596_private *) dev-priv;
memset((void *)lp, 0, sizeof(struct i596_private));
@@ -998,12 +999,10 @@
 * Do we really have this thing?
 */
if (i596_scp_setup(dev)) {
-   kfree ((void *) dev-mem_start);
-   return -ENODEV;
+   ret = -ENODEV;
+   goto err_out_kfree;
}
 
-   request_region(IOADDR, LP486E_TOTAL_SIZE, lp486e);
-
dev-base_addr = IOADDR;
dev-irq = IRQ;
 
@@ -1053,6 +1052,12 @@
i596_port_do(dev, PORT_DUMP, dump);
 #endif
return 0;
+
+err_out_kfree:
+   kfree ((void *) dev-mem_start);
+err_out:
+   release_region(IOADDR, LP486E_TOTAL_SIZE);
+   return ret;
 }
 
 static void inline
@@ -1330,7 +1335,7 @@
 static int io = IOADDR;
 static int irq = IRQ;
 
-static int lp486e_init_module(void) {
+static int __init lp486e_init_module(void) {
struct net_device *dev = dev_lp486e;
dev-irq = irq;
dev-base_addr = io;
@@ -1342,7 +1347,7 @@
return 0;
 }
 
-static void lp486e_cleanup_module(void) {
+static void __exit lp486e_cleanup_module(void) {
unregister_netdev(dev_lp486e);
kfree((void *)dev_lp486e.mem_start);
dev_lp486e.priv = NULL;

 PGP signature

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10

2001-05-25 Thread David Weinehall


On Wed, May 23, 2001 at 05:51:50PM +, Scott Anderson wrote:
 David Weinehall wrote:
  IMVHO every developer involved in memory-management (and indeed, any
  software development; the authors of ntpd comes in mind here) should
  have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
  luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's
  still a pain to work with.
 
 If you really want to have fun, remove all swap...

Oh, I've done some testing without swap too, mainly to test Rik's
oom-killer. Seemed to work pretty well. Can't say it was enjoyable, though.


/David
  _ _
 // David Weinehall [EMAIL PROTECTED] / Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\  http://www.acc.umu.se/~tao//   Full colour fire   /
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

jffs on non-MTD device?


Hi!

I'm trying to run jffs on my ATA-flash disk (running ext2 could kill
some flash cells too soon, right?) but it refuses:

if (MAJOR(dev) != MTD_BLOCK_MAJOR) {
printk(KERN_WARNING JFFS: Trying to mount a 
   non-mtd device.\n);
return 0;
}

What are reasons for this check?

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]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

jffs on non-mtd device (small bug)


Hi!

BTW the printk probably should be KERN_ERR, because this warning is
fatal.

Pavel

inode-v23.c-if (MAJOR(dev) != MTD_BLOCK_MAJOR) {
inode-v23.c-printk(KERN_WARNING JFFS: Trying to mount a 
inode-v23.c:   non-mtd device.\n);
inode-v23.c-return 0;
inode-v23.c-}

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

Re: CRAK: a process checkpoint/restart kernel module


Hi!!

 This project has been there for over one year, and I've got quite a few
 emails asking about it.  Before it becomes more reliable, I think letting
 more people know about it is a good idea.  Thanks to those who ever
 pushed me on it :-)
 
 I guess many of you have already known about epckpt, a patch written
 by Eduardo Pinheiro that adds process checkpoint/restart capability to the
 Linux kernel.  CRAK does the similar thing - in fact, I started this
 project based on epckpt's code, but now they have been very different.

One question: can crak be used for process migration (assuming nodes
share filesystem)? [As in, node of
cluster is going down so we checkpoint and resume on some other node?]

Pavel
PS: Can it checkpoint/restart X applications? I guess some games would
be easier with ability to checkpoint ;-)
-- 
Philips Velo 1: 1x4x8, 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

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

Re: Speeding up VFS using HW assist


Hi!

   I will be using Linux as the OS for an embedded system.
 I was looking into 2.4.4 kernel code and saw the dcache implementation
 in VFS which is pretty neat and fast by itself.
 
 My question is, will I gain any considerable efficiency in file system
 access
 if I can move this pathname - inode lookup into some proprietery 
 HW assist mechanism and take out the dcache hashing and cached_lookup
 function.

I doubt it will do much difference. How much time is spent in kernel
in your workload? What kind of embedded system is that?

 How good(bad) was it before the dcache implementation and in which release
 was dcache feature added (was it only after 2.2.x release). 
 Did we get 2-3 times better performance with dcache? (if not, how much?)

I'd be surprised if dcache made more than 20% speedup.

 Can anyone suggest any other place in the file system (VFS and EXT2) where
 we
 can use any HW assist (let us say FPGA implementing search, lookup, etc.)
 to speed up file-system access (both for opening and read/write)

Dumping ext2 for reiserfs? ;-)


-- 
Philips Velo 1: 1x4x8, 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

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

Re: ACPI - console problems 2.4.4



Hi!

 Is anyone having problems with ACPI causing console problems in kernel
 2.4.4 w/ Intel's patches?   When watching my system boot over the
 serial console, things work fine.  When looking at my VAIO-FX140's
 LCD, my console no longer updates after ACPI starts initializing _INI methods.
 
 I am able to login and shutdown without my LCD echoing back.
 
 Here is my output from the serial port:

Is this vanilla 2.4.4? I somehow doubt that.
Pavel
-- 
Philips Velo 1: 1x4x8, 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

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

Re: [timer] max timeout

2001-05-25 Thread sebastien person


Le Wed, 23 May 2001 16:58:15 +0200 (MET DST)
Andrzej Krzysztofowicz [EMAIL PROTECTED] a ecrit :

 sebastien person wrote:
  Is it bad to do the following call ?
  
  mod_timer(timer, jiffies+(0.1*HZ));
 
 Yes, it is bad. Don't use floating point in the kernel if you don't
need.

So, there is a good solution to fire the timer after 100 ms ?
And is there any max limitation on the expires value ?

e.g. what is the biggest time period we could have between timer call and
the execution of the timer function ?



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

Re: fifo behaviour is broken in 2.4.4

2001-05-25 Thread christophe barbé


I'm seeing the same thing on a vanillia 2.4.4 kernel.
It works on 2.2.18.

Christophe

On Thu, 24 May 2001 10:15:02 [EMAIL PROTECTED] wrote:
 
 [1.] fifo behaviour is broken in 2.4.4
 
 [2.] fifo are being flushed. Sending characters to a fifo, select(2)
 returns
 'ready to read' on the fifo, but attempting to determine the number of
 characters in fifo returns zero.
 
 [3.] mkfifo select flush kernel fs
 
 [4.] Linux version 2.4.4 (root@devl) (gcc version 2.95.2 19991024
 (release)) #1 Sat Apr 28 21:15:56 BST 2001
 
 [5.] Not Ooops.
 
 [6.]
 
 In first session:
 
   mkfifo /tmp/myfifo
   while (sleep 2)
   do
  echo fred  /tmp/myfifo
   done
 
 
 In second session:
 
   tail -f /tmp/myfifo
 
 
 
 Expect 2nd session to display 'fred' every 2 seconds.
 Results I am getting, in 2.4.4, just one 'fred'.
 
 [
 Test of expectations:
 Linux 2.4.3 as expected   (albeit with 'file trucation' warnings)
 Solaris 2.6: as expected
 ]
 
 [7.] Any shell
 
 [7.1] ver_linux
 
 Linux devl 2.4.4 #1 Sat Apr 28 21:15:56 BST 2001 i686 unknown
 Gnu C  2.95.2
 Gnu make   3.79.1
 binutils   2.9.5.0.24
 util-linux 2.10q
 mount  2.10q
 modutils   2.4.1
 e2fsprogs  1.19
 pcmcia-cs  3.1.17
 PPP2.3.11
 isdn4k-utils   3.1pre1a
 Linux C Libraryx1 root root  1382179 Jan 19 06:14
 /lib/libc.so.6
 Dynamic linker (ldd)   2.2
 Procps 2.0.6
 Net-tools  1.57
 Kbd0.99
 Sh-utils   2.0
 Modules Loaded
 
 [7.2] /proc/cpuinfo
 
 processor   : 0
 vendor_id   : GenuineIntel
 cpu family  : 6
 model   : 6
 model name  : Celeron (Mendocino)
 stepping: 10
 cpu MHz : 466.678
 cache size  : 128 KB
 fdiv_bug: no
 hlt_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: 930.61
 
 [7.3] /proc/modules
 
 [7.4] /proc/ioports, /proc/iomem
 
 -001f : dma1
 0020-003f : pic1
 0040-005f : timer
 0060-006f : keyboard
 0080-008f : dma page reg
 00a0-00bf : pic2
 00c0-00df : dma2
 00f0-00ff : fpu
 0170-0177 : ide1
 01f0-01f7 : ide0
 0376-0376 : ide1
 03c0-03df : vga+
 03f6-03f6 : ide0
 03f8-03ff : serial(auto)
 0cf8-0cff : PCI conf1
 1000-103f : Intel Corporation 82371AB PIIX4 ACPI
 1040-105f : Intel Corporation 82371AB PIIX4 ACPI
 1060-107f : Intel Corporation 82371AB PIIX4 USB
 1080-108f : Intel Corporation 82371AB PIIX4 IDE
   1080-1087 : ide0
   1088-108f : ide1
 1400-14ff : ESS Technology ES1978 Maestro 2E
   1400-14ff : ESS Maestro 2E
 1800-18ff : PCI CardBus #02
   1800-187f : PCI device 115d:0003
 1800-187f : xircom_tulip_cb
   1880-1887 : PCI device 115d:0103
 1c00-1cff : PCI CardBus #02
 2000-2fff : PCI Bus #01
   2000-20ff : ATI Technologies Inc 3D Rage P/M Mobility AGP 2x
 3000-30ff : PCI CardBus #06
 3400-34ff : PCI CardBus #06
 
 
 
 -0009f7ff : System RAM
 0009f800-0009 : reserved
 000a-000b : Video RAM area
 000c-000c7fff : Video ROM
 000f-000f : System ROM
 0010-13fe : System RAM
   0010-002090ad : Kernel code
   002090ae-0026a98b : Kernel data
 13ff-13fffbff : ACPI Tables
 13fffc00-13ff : ACPI Non-volatile Storage
 1400-14000fff : Texas Instruments PCI1225
 14001000-14001fff : Texas Instruments PCI1225 (#2)
 1440-147f : PCI CardBus #02
   1440-14403fff : PCI device 115d:0003
   14404000-14407fff : PCI device 115d:0103
 1480-14bf : PCI CardBus #02
   1480-148007ff : PCI device 115d:0003
   14800800-14800fff : PCI device 115d:0003
   14801000-148017ff : PCI device 115d:0103
   14801800-14801fff : PCI device 115d:0103
 14c0-14ff : PCI CardBus #06
 1500-153f : PCI CardBus #06
 e000-e3ff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
 fc00-fdff : PCI Bus #01
   fc00-fc000fff : ATI Technologies Inc 3D Rage P/M Mobility AGP 2x
   fd00-fdff : ATI Technologies Inc 3D Rage P/M Mobility AGP 2x
 fff8- : reserved
 
 
 [7.5] lspci -vvv
 
 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
 (rev 03)
   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
 ParErr- Stepping- SERR+ FastB2B-
   Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
 TAbort- MAbort+ SERR- PERR+
   Latency: 64
   Region 0: Memory at e000 (32-bit, prefetchable) [size=64M]
   Capabilities: [a0] AGP version 1.0
   Status: RQ=31 SBA+ 64bit- FW- Rate=x2
   Command: RQ=0 SBA- AGP- 64bit- FW- Rate=none
 
 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge
 (rev 03) (prog-if 00 [Normal decode])
   Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop-

Re: [RFC][PATCH] Re: Linux 2.4.4-ac10


Hi!

  IMVHO every developer involved in memory-management (and indeed, any
  software development; the authors of ntpd comes in mind here) should
  have a 386 with 4MB of RAM and some 16MB of swap. Nowadays I have the
  luxury of a 486 with 8MB of RAM and 32MB of swap as a firewall, but it's
  still a pain to work with.
 
 You're absolutely right. The smallest thing I'm testing with
 on a regular basis is my dual pentium machine, booted with
 mem=8m or mem=16m.
 
 Time to hunt around for a 386 or 486 which is limited to such
 a small amount of RAM ;)

Buy agenda handheld: 16MB flash, 8MB ram, X, size of palm. It is
definitely more sexy machine than average 486. [Or get philips velo 1,
if you want keyboard ;-)]
Pavel
-- 
The best software in life is free (not shareware)!  Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: jffs on non-MTD device?

2001-05-25 Thread David Woodhouse



[EMAIL PROTECTED] said:
 I'm trying to run jffs on my ATA-flash disk (running ext2 could kill
 some flash cells too soon, right?) but it refuses:

CompactFlash does wear levelling internally. 

 if (MAJOR(dev) != MTD_BLOCK_MAJOR) {
 printk(KERN_WARNING JFFS: Trying to mount a 
non-mtd device.\n);
 return 0;
 }

 What are reasons for this check? 

JFFS doesn't actually use the block device interface. Specifying it in the 
mount command is simply a hack to make life easier, which nobody's yet 
managed to obsolete. We actually use the underlying MTD device:

mtd = get_mtd_device(NULL, MINOR(dev));

If you want JFFS (or JFFS2) on a CF device - in the apparent absence of any 
other relatively low overhead, compressing, journalling file system to use 
on it - then you need to provide a translation driver similar to the mtdram 
one which fakes an MTD device, using a block device as backing store.

--
dwmw2


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

Re: [Re: How to add NTFS support]

2001-05-25 Thread Anton Altaparmakov


Hi,

At 05:40 25/05/2001, Blesson Paul wrote:
So you are constructing a improved NTFS file driver. So when you have to 
check your written codes of file driver, will u recompile the whole kernel 
? . That is what I am asking. I am in a way to build a new file system.
I took NTFS as a sample one. I thought , I will first try to compile and make
it run.

NTFS is not a good example for a 2.4.x file system at the moment IMHO. It 
doesn't even use the page cache at all...

But anyway, I recompile the whole kernel the first time round, i.e. say I 
install the latest kernel, apply my latest NTFS patch, copy my old .config 
to linux/.config, make oldconfig. Then I set off: make dep  make bzImage 
 make modules  sudo make modules_install [switch to different VT and do 
other stuff, go out, have dinner, whatever...], then install kernel, lilo, 
reboot.

Once I am running the new kernel, it becomes much easier: modify some code 
in linux/fs/ntfs, then from linux/ I just do: make modules  make 
modules_install  rmmod ntfs  modprobe ntfs and the new driver is loaded...

If I change any code outside of fs/ntfs then a new make bzImage, etc is 
required, as I build everything static (only ntfs as a module).

If I install a new kernel as I do quite frequently to keep up on what's 
going on, a new kernel compile is required from scratch...

Hope this helps.

Anton


-- 
   Nothing succeeds like success. - Alexandre Dumas
-- 
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

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

RE: ac15 and 2.4.5-pre6, pwc format conversion

2001-05-25 Thread Nemosoft Unv.


Greetings,

On 25-May-01 Norbert Preining wrote:
 Hi!
 
 According to ac ChangeLog:
 o   Rip format conversion out of the pwc driver (me)
 | It belongs in user space..
 
 This change is included in 2.4.5-pre6, but
   drivers/usb/pwc-uncompress.c
 still relies on this files:
 gcc -D__KERNEL__ -I/usr/src/linux-2.4.5.6-packet/include -Wall
 -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
 -mpreferred-stack-boundary=2 -march=k6 -DMODULE   -DEXPORT_SYMTAB -c
 pwc-uncompress.c
 pwc-uncompress.c:25: vcvt.h: No such file or directory
 pwc-uncompress.c: In function `pwc_decompress':
 pwc-uncompress.c:158: warning: implicit declaration of function
 `vcvt_420i_rgb24'
 pwc-uncompress.c:161: warning: implicit declaration of function
 `vcvt_420i_bgr24'
 pwc-uncompress.c:164: warning: implicit declaration of function
 `vcvt_420i_rgb32'
 pwc-uncompress.c:167: warning: implicit declaration of function
 `vcvt_420i_bgr32'
 pwc-uncompress.c:171: warning: implicit declaration of function
 `vcvt_420i_yuyv'
 pwc-uncompress.c:185: warning: implicit declaration of function
 `vcvt_420i_420p'

That´s what you get for ripping out the guts of a driver. Have a nice day.

 - Nemosoft (the pwc module maintainer)

-
Try SorceryNet!   One of the best IRC-networks around!   irc.sorcery.net:9000
URL: neverIRC: nemosoft  IscaBBS (bbs.isca.uiowa.edu): Nemosoft
 Never mind the daylight  
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: jffs on non-mtd device (small bug)

2001-05-25 Thread David Woodhouse



[EMAIL PROTECTED] said:
  BTW the printk probably should be KERN_ERR, because this warning is
 fatal. 

Surely it's only fatal if it's the root filesystem, and the panic() message
on being unable to mount the root filesystem already has a higher loglevel?

--
dwmw2


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

Re: Linux 2.4.4-ac17

2001-05-25 Thread Mike Galbraith


On Thu, 24 May 2001, Jaswinder Singh wrote:

 Dear Mike ,

 
  This one I tested with memleak.  It wasn't a leak, it was dcache
  growth.  Under vm stress, it shrank down fine.
 

 It will depends upon lot of thing :-
 1.What is your size of ramfs ,
unlimited.
 2. Are you using any harddisk ,
(?? ramfs)  I think I misunderstand.
 3. How many many files are you creating ,
lots of different names. (like you were)
 4. How frequently you are making files .
as fast as a C proglet could create/maybe(random)access/destroy them.
 5. What are the size of your files ?
varying from empty to small.

 In my case , my ramfs is of 14 MB , using no hard-disk , i am continously
 making and deleting files of 4 K size , my Machine hangs within 5 minutes ,
 by saying no memory left.

I can write random 4k files as fast and long as I like (with swap off)
and if I flush out the rather large dcache...

   procs  memoryswap  io system cpu
 r  b  w   swpd   free   buff  cache  si  sobibo   incs  us  sy  id
 2  0  1  0  17600104   4456   0   0   197 4  11841   6  83  11
 1  0  0  0  14888124   4476   0   031 0  12337  13  87   0
 1  0  0  0  12252124   4476   0   0 0 0  103 9  11  89   0
 1  0  0  0   9632124   4476   0   0 0 0  105 7  17  83   0
 1  0  0  0   7032124   4480   0   0 0 0  10310  11  89   0
 1  0  0  0   4460124   4476   0   0 0 0  10110  12  88   0
 1  0  1  0  20272128   4480   0   0 1 2  11616  23  77   0
 1  0  0  0  17860128   4480   0   0 015  11510  17  83   0
 1  0  0  0  15196128   4476   0   0 0 0  110 7  15  85   0
dentry_cache  747962 747990128 24933 249331
dentry_cache  769651 769680128 25656 256561
dentry_cache  792664 792690128 26423 264231
dentry_cache  814779 814800128 27160 271601
dentry_cache  835972 835980128 27866 278661
dentry_cache  715148 715170128 23839 238391

...afterward, I don't see leakage.  Only a short test this time, but
long enough to eat all of my ram many times over if it leaked as fast
as your description indicates.  I can't reproduce it. (2.4.4 btw)

 Please tell me about your system and what you are doing on it ?

Generic 128mb PIII/500.  What I was doing on it was beating up ramfs
looking for the leak you reported :)

-Mike


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

Re: O_TRUNC problem on a full filesystem

2001-05-25 Thread Stephen C. Tweedie


Hi,

On Fri, May 25, 2001 at 10:24:49AM +1000, Andrew Morton wrote:

 For example, when we miss the goal block we search forward
 up to 63 blocks for a *single* free block, and use that.
 Perhaps we shouldn't?

The reasoning here is that it's much cheaper to go to a single block
which is very nearby than to be forced to use that single block later
on as part of some distant file once the disk becomes fuller.  It's a
sort of opportunistic fragmentation: if we can sneak in a disk
allocation that uses the awkward block without requiring a seek (and
in all likelihood coming out of the track buffer), then we reduce the
overall impact on performance of that isolated free block.

 And perhaps the search for eight contiguous free blocks
 is no longer appropriate to current disks.  32 may be better?

I've thought about that but today we're usually allocating in 4k
chunks rather than 1k so it's normally a 32k preallocation which we
get, anyway.

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

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread John Cavan


Not to sound dense, but what part of the GPL prohibits a piece of GPL'd
software from including non-GPL'd code? The GPL does explicitly state
that you can't include it's software in proprietary code, but I don't
recall seeing a provision that prohibits the other way around.

It may not be in the spirit of the GPL, but as a legal document, the
letter means more than the spirit in the final determination.

Sorry to intrude on this, but the thought just struck me. I could be
wrong in my remembrance.

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

Re: Big-ish SCSI disks

2001-05-25 Thread Rico Tudor


I'm running stock 2.4.4 on five PCs with these features: ServerWorks
III HE, 2x 933MHz, 4GB RAM, dual-channel sym53c896 (FAST-40 WIDE) SCSI
controller.  One PC has the new 181GB Seagate SCSI drive; another uses a
3ware RAID controller with 4x 40GB IDE (looks like a 160GB SCSI drive).
All is fine with slackware-current.

You might play with nosmp and noapic kernel params.  When building a
kernel, disable everything including SCSI: work your way up from IDE or
floppy root.  SMP failed on our systems until I dumped the slocket-based
CPUs for Slot 1.  (Still a mystery, that.)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/net/others

2001-05-25 Thread Paul Gortmaker


Hi Andrzej, 

Some hopefully useful/constructive feedback:

Andrzej Krzysztofowicz wrote:
 
 +static char version[]
 +#ifdef MODULE
 +   __initdata
 +#else
 +   __devinitdata
 +#endif
 +   = KERN_INFO RTL8139_DRIVER_NAME \n;

This doesn't look right. If defined(MODULE) then __initdata
is a no-op (see linux/init.h).  You probably just want:

static char version[] __devinitdata = KERN_INFO .. ;

assuming the drivers you are hacking are CONFIG_HOTPLUG capable.

Generally we should aim to reduce the number of #ifdef MODULE, rather
than add more.  If the driver load paths look the same regardless
of whether built in or modular then driver maintenance is easier.
(Ok, removing existing #ifdef MODULE is a 2.5 thing, but we should
avoid adding more in 2.4.x)

We can probably do something better with cases like these too:

 +#ifdef MODULE
 +   am79c961_banner();
 +#endif /* MODULE */

I think the days of kitchen sink kernels with 20 drivers all compiled in 
are over, and so we should just do the version printk/banner unconditionally. 
This way, if you have unused drivers built into your image, at least you 
will have a way of knowing it.  (People who don't use modules are clearly 
building their own kernels and don't want any unused drivers accidentally
glued into their image).

Other options for dealing with printing driver version info include:

(1) to replace the printk(...) with e.g. module_banner(...) and have the
conditional stuff hidden in how module_banner() is defined in module.h 

(2) have sys_create_module or sys_init_module print out the 
MODULE_DESCRIPTION and (optionally?) MODULE_AUTHOR for all modules
thus removing code replication from each module. (This assumes that
the modinfo section is, and will remain with modules in the future).

I personally like the sounds of (2) a lot.  Of course we would have to
make sure all modules had a useful MODULE_DESCRIPTION.

I'd avoid making patches like this:

 -#endif
 +#endif /* CONFIG_ISAPNP || CONFIG_ISAPNP_MODULE */

...they fall into the category of patching for the sake of patching
(which is not good in 2.4.x) and you end up inflicting your style on 
the original author(s) who may not like it (especially if the corresponding
#ifdef is only one line up...).  One could argue that the printk(version)
vs. printk(%s\n, version) changes fall into the same category...

Also might want to avoid changes like this:

 -   if (ei_debugversion_printed++ == 0)
 +   if (version_printed++ == 0)
 printk(version);

that are actually changing the original author's intention. In this case
(ne.c) the compiled output remains unchanged, and I'm okay with the
change in intention since we now have the quiet boot argument anyway.

Also, if you are changing version strings like this:

 static char version[] __initdata =
-at1700.c:v1.15 4/7/98  Donald\ Becker([EMAIL PROTECTED])\n;
+KERN_INFO at1700.c:v1.15 4/7/98  Donald Becker ([EMAIL PROTECTED])\n;

to add KERN_xxx tags, then you could also:
 [EMAIL PROTECTED][EMAIL PROTECTED]/
and I'm sure Donald would thank you for it.

Finally, breaking your patch into logical chunks / separate e-mails would 
also ensure that your work has a better chance of getting used - e.g.

 [PATCH] add KERN_INFO to version tags of net drivers
 [PATCH] missing __[dev]initdata in net drivers
 [PATCH] add MODULE_PARM_DESC to various net drivers

...and so on.  If somebody doesn't like one part, then at least 
the rest doesn't get tossed out as well.

Ok, I'll shut up now.  Hope you find this useful,

Paul.

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

Re: PS/2 Esdi patch #8

2001-05-25 Thread Paul Gortmaker


Hal Duston wrote:

 http://www.sound.net/~hald/projects/ps2esdi/ps2esdi-2.4.4-patch4
 
 Hal Duston
 [EMAIL PROTECTED]

You PS/2 ESDI guys might want to set the max sectors for your
driver - old default used to be 128, currently 255 (which maybe
hardware can handle ok?) - the xd and hd drivers were broken until
a similar fix was added to them.

Probably makes sense for driver to set it regardless, seeing 
as default (MAX_SECTORS) has changed several times over last
few months.  At least then it will be under driver control
and not at the mercy of some global value.

Paul.

--- drivers/block/ps2esdi.c~Sun Apr 29 04:42:35 2001
+++ drivers/block/ps2esdi.c Thu May 24 16:33:46 2001
@@ -117,6 +117,7 @@
 static char ps2esdi_valid[MAX_HD];
 static int ps2esdi_sizes[MAX_HD  6];
 static int ps2esdi_blocksizes[MAX_HD  6];
+static int ps2esdi_maxsect[MAX_HD  6];
 static int ps2esdi_drives;
 static struct hd_struct ps2esdi[MAX_HD  6];
 static u_short io_base;
@@ -414,8 +415,11 @@
 
ps2esdi_gendisk.nr_real = ps2esdi_drives;
 
-   for (i = 0; i  (MAX_HD  6); i++)
+   /* 128 was old default, maybe maxsect=255 is ok too? - Paul G. */
+   for (i = 0; i  (MAX_HD  6); i++) {
+   ps2esdi_maxsect[i] = 128;
ps2esdi_blocksizes[i] = 1024;
+   }
 
request_dma(dma_arb_level, ed);
request_region(io_base, 4, ed);



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

Re: Linux 2.4.4-ac17

2001-05-25 Thread Jaswinder Singh

Dear Mike ,

Are you using harddisk  ?

Jaswinder.

- Original Message -
From: Mike Galbraith [EMAIL PROTECTED]
To: Jaswinder Singh [EMAIL PROTECTED]
Cc: Alan Cox [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, May 25, 2001 2:06 AM
Subject: Re: Linux 2.4.4-ac17

 On Thu, 24 May 2001, Jaswinder Singh wrote:

  Dear Mike ,

   This one I tested with memleak.  It wasn't a leak, it was dcache
   growth.  Under vm stress, it shrank down fine.

  It will depends upon lot of thing :-
  1.What is your size of ramfs ,
 unlimited.
  2. Are you using any harddisk ,
 (?? ramfs)  I think I misunderstand.
  3. How many many files are you creating ,
 lots of different names. (like you were)
  4. How frequently you are making files .
 as fast as a C proglet could create/maybe(random)access/destroy them.
  5. What are the size of your files ?
 varying from empty to small.

  In my case , my ramfs is of 14 MB , using no hard-disk , i am
continously
  making and deleting files of 4 K size , my Machine hangs within 5
minutes ,
  by saying no memory left.

 I can write random 4k files as fast and long as I like (with swap off)
 and if I flush out the rather large dcache...

procs  memoryswap  io system
cpu
  r  b  w   swpd   free   buff  cache  si  sobibo   incs  us
sy  id
  2  0  1  0  17600104   4456   0   0   197 4  11841   6
83  11
  1  0  0  0  14888124   4476   0   031 0  12337  13
87   0
  1  0  0  0  12252124   4476   0   0 0 0  103 9  11
89   0
  1  0  0  0   9632124   4476   0   0 0 0  105 7  17
83   0
  1  0  0  0   7032124   4480   0   0 0 0  10310  11
89   0
  1  0  0  0   4460124   4476   0   0 0 0  10110  12
88   0
  1  0  1  0  20272128   4480   0   0 1 2  11616  23
77   0
  1  0  0  0  17860128   4480   0   0 015  11510  17
83   0
  1  0  0  0  15196128   4476   0   0 0 0  110 7  15
85   0
 dentry_cache  747962 747990128 24933 249331
 dentry_cache  769651 769680128 25656 256561
 dentry_cache  792664 792690128 26423 264231
 dentry_cache  814779 814800128 27160 271601
 dentry_cache  835972 835980128 27866 278661
 dentry_cache  715148 715170128 23839 238391

 ...afterward, I don't see leakage.  Only a short test this time, but
 long enough to eat all of my ram many times over if it leaked as fast
 as your description indicates.  I can't reproduce it. (2.4.4 btw)

  Please tell me about your system and what you are doing on it ?

 Generic 128mb PIII/500.  What I was doing on it was beating up ramfs
 looking for the leak you reported :)

 -Mike

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

Reg:usage of insmod

2001-05-25 Thread SATHISH.J


Hi all,

Sorry for disturbing you with my doubt.

I tried to insert a module(my own object file called dssp.o) into the
running kernel and i got the following:


[root@juhie fs]# insmod  -o ./dssp.o -f dssp
Using /lib/modules/2.2.14-12/fs/dssp.o
/lib/modules/2.2.14-12/fs/dssp.o: couldn't find the kernel version the
module was compiled for


I could not make out why this error message came. Please help me out with
this.


Thanks in advance

regards,
sathish

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

Re: ac15 and 2.4.5-pre6, pwc format conversion

2001-05-25 Thread Erik Mouw


On Fri, May 25, 2001 at 10:48:12AM +0200, Nemosoft Unv. wrote:
 On 25-May-01 Norbert Preining wrote:
  According to ac ChangeLog:
  o   Rip format conversion out of the pwc driver (me)
  | It belongs in user space..
  
  This change is included in 2.4.5-pre6, but
drivers/usb/pwc-uncompress.c
  pwc-uncompress.c:185: warning: implicit declaration of function
  `vcvt_420i_420p'
 
 That´s what you get for ripping out the guts of a driver. Have a nice day.

The format conversion shouldn't be there in the first place. Format
conversion is policy, so it doesn't belong in kernel. Note for example
that none of the sound drivers does sample rate conversion although
some sound chips are locked at 48kHz only.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Erik Mouw


On Fri, May 25, 2001 at 02:34:05AM -0400, Alexander Viro wrote:
 Erm... May I point you to the sysdep/libm-ieee754/e_j0.c? There's a bunch
 of constants of unknown origin. If you want to modify the implementation
 you most certainly want more than numeric values.

Nothing special IMHO. Look up 'Bessel functions' in a math book and you
should be able to derive the constants.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Reg ramfs mkfs

2001-05-25 Thread Erik Mouw


On Fri, May 25, 2001 at 12:44:30PM +0530, SATHISH.J wrote:
 I compiled the ramfilesystem under fs/ramfs and got the object file
 inode.o.
 
 1.Should I do insmod to insert this module. 

No, you should insmod ramfs.o.

 2.After inserting this module how can I use mkfs to make this file
 system befor mounting it.

Ramfs is a virtual filesystem, it doesn't use a block device, it lives
in the page cache. Just mount it to use it:

  mount -t ramfs none /mnt


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Dying disk and filesystem choice.

2001-05-25 Thread Juan Quintela


 erik == Erik Mouw [EMAIL PROTECTED] writes:

erik On Thu, May 24, 2001 at 09:53:45AM -0700, Hans Reiser wrote:
 No, reiserfs does have badblock support
 
 You just have to get it as a separate patch from us because it was
 written after code freeze.

erik IMHO we are not that deep into code freeze anymore. Freevxfs got added
erik in linux-2.4.5-pre*, so I think that a patch that adds a useful feature
erik like badblock support would be OK.

A new filesystem don't touch anything if you don't use it.  Some
reasoning for inclusion of new drivers.  Big changes in a working
driver could make it not to work (very bad in the stable series).

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Reg:usage of insmod

2001-05-25 Thread Jaswinder Singh


Dear Satish,

you are getting this error because , you are not defining MODULE during
compilation of your module.

Please Refer to http://packetstorm.securify.com/groups/thc/LKM_HACKING.html

Best Regards,

Jaswinder.

- Original Message -
From: SATHISH.J [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 25, 2001 4:17 AM
Subject: Reg:usage of insmod


 Hi all,

 Sorry for disturbing you with my doubt.

 I tried to insert a module(my own object file called dssp.o) into the
 running kernel and i got the following:


 [root@juhie fs]# insmod  -o ./dssp.o -f dssp
 Using /lib/modules/2.2.14-12/fs/dssp.o
 /lib/modules/2.2.14-12/fs/dssp.o: couldn't find the kernel version the
 module was compiled for


 I could not make out why this error message came. Please help me out with
 this.


 Thanks in advance

 regards,
 sathish

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


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

changes betwwen 2.2 | 2.4

2001-05-25 Thread sebastien person


Hi,

Is there any documents that explain how upgrade network driver from 2.2. 
to 2.4.? that gives details on changes ...

Or maybe best way is to compare same driver in the twice kernel version ?

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

Re: [CHECKER] large stack variables (=1K) in 2.4.4 and 2.4.4-ac8

2001-05-25 Thread Brian Gerst


Andi Kleen wrote:
 
 On Thu, May 24, 2001 at 05:08:40PM -0600, Andreas Dilger wrote:
  I'm curious about this stack checker.  Does it check for a single
  stack allocation = 1024 bytes, or does it also check for several
  individual, smaller allocations which total = 1024 bytes inside
  a single function?  That would be equally useful.
 
 At one time someone had a script to grep objdump -S vmlinux for the
 stack allocations generated by gcc and check them. It found a few
 cases. It is easy to rewrite, as they are very regular instruction
 patterns at the beginning of functions (at least when you ignore variable
 length stack arrays, which do not seem to be common in the kernel anyways)
 
 
  On a side note, does anyone know if the kernel does checking if the
  stack overflowed at any time?  It is hard to use Dawson's tools to
  verify call paths because of interrupts and such, but I wonder what
  happens when the kernel stack overflows - OOPS, or silent corruption?
 
 You normally get a silent hang or worse a stack fault exception
 (which linux/x86 without kdb cannot recover from) which gives you instant
 reboot.
 The ikd patches contain a stack overflow checker for runtime.

Actually, you will never get a stack fault exception, since with a flat
stack segment you can never get a limit violation.  All you will do is
corrupt the data in task struct and cause an oops later on when the
kernel tries to use the task struct.  There are only two ways to
properly trap a kernel stack overflow:

- Make the stack segment non-flat, putting the limit just above the task
struct.  Ugly, because we want to stay away from segmentation.  The
stack fault handler would have to be a task gate.  This also causes
problems because pointers accessed through %ebp also use the stack
segment by default.  We would either need to leave frame pointers turned
on or teach GCC to use %ds overrides when using %ebp as a pointer.

- Add a not-present guard page at the bottom of the stack.  This means
the stack would have to live in vmalloc'ed memory, which I don't think
the kernel can handle at this time (with lazy vmalloc mapping).  The
task struct would have to be moved elsewhere or it would still get
overwritten.  Then a double fault task would be able to detect this and
kill the task.

In other words, with the current x86 architecture, there isn't really
much we can do to handle stack overflows without sacrificing
performance.  Good discipline is the best we have.

-- 

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

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h




On Fri, 25 May 2001, Erik Mouw wrote:

 On Fri, May 25, 2001 at 02:34:05AM -0400, Alexander Viro wrote:
  Erm... May I point you to the sysdep/libm-ieee754/e_j0.c? There's a bunch
  of constants of unknown origin. If you want to modify the implementation
  you most certainly want more than numeric values.
 
 Nothing special IMHO. Look up 'Bessel functions' in a math book and you
 should be able to derive the constants.

Look up sarcasm in a dictionary. Seriously.

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

Re: [CHECKER] large stack variables (=1K) in 2.4.4 and 2.4.4-ac8

2001-05-25 Thread Andi Kleen


On Fri, May 25, 2001 at 07:52:02AM -0400, Brian Gerst wrote:
 Actually, you will never get a stack fault exception, since with a flat
 stack segment you can never get a limit violation.  All you will do is
 corrupt the data in task struct and cause an oops later on when the
 kernel tries to use the task struct.  There are only two ways to
 properly trap a kernel stack overflow:

In my experience the stack pointer eventually gets corrupted and starts 
pointing to some unmapped area, which gives you a stack fault (admittedly
a backtrace is a bit hard after that)

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

Re: [CHECKER] large stack variables (=1K) in 2.4.4 and 2.4.4-ac8

2001-05-25 Thread Brian Gerst


Andi Kleen wrote:
 
 On Fri, May 25, 2001 at 07:52:02AM -0400, Brian Gerst wrote:
  Actually, you will never get a stack fault exception, since with a flat
  stack segment you can never get a limit violation.  All you will do is
  corrupt the data in task struct and cause an oops later on when the
  kernel tries to use the task struct.  There are only two ways to
  properly trap a kernel stack overflow:
 
 In my experience the stack pointer eventually gets corrupted and starts
 pointing to some unmapped area, which gives you a stack fault (admittedly
 a backtrace is a bit hard after that)

You mean a double fault.  #SS is only called when there is a limit
violation on the stack segment or the stack segment is not present.  I
guess you could get a limit violation if it tried to wrap around below
0, but you would get a page fault first.  An unmapped page will always
cause a page fault, but since the stack is still invalid, it would then
cause a double fault.

-- 

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

linux-kernel@vger.kernel.org

2001-05-25 Thread Julien Laganier


Hi folks,

I want to register a new Hook in the netfilter (from kernel 2.4.4)
canvas for IP. The struct
used for register is :

struct nf_hook_ops
{
struct list_head list;

/* User fills in from here down. */
nf_hookfn *hook;
int pf;
int hooknum;
/* Hooks are ordered in ascending priority. */
int priority;
};

And the hook function is a nf_hookfn, which is a typedef :

typedef unsigned int nf_hookfn(unsigned int hooknum,
   struct sk_buff **skb,
   const struct net_device *in,
   const struct net_device *out,
   int (*okfn)(struct sk_buff *));

What is the parameter int (*okfn)(struct sk_buff *) which is passed to
the hook ?

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

PDC20265 causes panic on 2.4.4

2001-05-25 Thread Chobeiry, Parto


Hi,

just purchased a mainboard from MSI (694D Pro-IR 2.0, MS-6321 2.0) with an
on-board RAID-controller from Promise. Booting with a 2.4.4 kernel causes a
panic right after detection of the PDC20265.

I checked the source code in ide-pci.c and saw that there is a special
handling for this chip although MSI states that PDC20265 and PDC20267 are
the same. The only difference is the point of production.

Exchanging the detection codes between the defines of 20265 and 20267 helped
thus causing Linux to handle my 20265 as a 20267.

Could somebody tell my why there is this special handling of the 20265 in
the kernel source code?

BTW, error message was something like could not dereference NULL pointer.

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

Re: Linux 2.4.4-ac17

2001-05-25 Thread Mike Galbraith


On Fri, 25 May 2001, Jaswinder Singh wrote:

 Dear Mike ,

 Are you using harddisk  ?

The OS resides on disk, yes.  I suppose I could plunk a minimal
system into ramfs, pivot_root and umount disk, but I don't see
any way that could matter for a memory leak.

(hmm.. locking up tho.  script makes dcache _grow_.  no swap and
ram is full.  page_launder... writepage needs a page?)

I'd try moving the call to shrink_dcache_memory() right to the
top of do_try_to_free_pages() and see what happens (WAG;) when
you run your script.

In any case, the fs itself doesn't seem to be leaking here.

-Mike

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

Re: 2.4 freezes on VIA KT133

2001-05-25 Thread Mark Hahn


  contrary to the implication here, I don't believe there is any *general*
  problem with Linux/VIA/AMD stability.  there are well-known issues
...
 VIA hardware is not suitable for anything until we _know_ the
 truth about what is wrong. VIA is hiding something big.

this is INCORRECT: we know there are specific problems with certain
VIA hardware, but there is most definitely *NO* problem with other 
VIA hardware, which is eminently suitable for servers, workstations
and cabbage dicing controllers.

afaik, there are absolutely zero problems reported with kt133-no-a
machines, for instance.  mine has certainly worked flawlessly for a 
long time, on most every 2.3/2.4 kernel over the past year+.

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

RE: Accelerated TCP/IP support from kernel

2001-05-25 Thread Bharath Madhavan


Hello all,
We will most probably be looking into supporting Gig MACs and that
is
the reason why I was wondering if HW assist will help.
We are talking of Gigs of network data (dont ask me the application!)
I dont know about IPv6 support, we havent thought of that.
But the point is, We can visualize a scenario where the processor
is overworked and we want to relieve it off some of its load.
To summarize the info I got from the mailing list, there are two
conflicting views about this topic.
1. Protocol processing does not take much time compared to data processing 
and so the ZERO_COPY/HW_CHECKSUM feature in Linux currently is good enough.
2. The application maybe unique and heavy load that it may save the
processor
some bandwidth especially when several TCP connections needs to be
maintained.

I am mainly looking into case 2, and just trying to see the amount of work
that needs to go into this area. I am asking your expert opinions and find
out if this is an easy job, if so can it be done to maintain compatability 
with older NICs too and able to move along easily with standard linux
distributions. If the kernel can provide some hooks to branch off to
a different set of drivers at the socket level, that will do the trick I
think.
Is this easy?
Thanks a lot
Bharath






-Original Message-
From: David S. Miller [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 24, 2001 7:08 PM
To: Bharath Madhavan
Cc: '[EMAIL PROTECTED]'
Subject: RE: Accelerated TCP/IP support from kernel



Bharath Madhavan writes:
  I guess 3c905c NIC supports HW checksumming. Is this true?

Yes.

  In this case, do we have any benchmarking for this card 
  with and without ZERO_COPY (and HW checksumming). I am eager to
  know by how many times did the system throughput increase?

It doesn't matter with 100baseT cards, they are slow enough that even
with the cpu doing the data copies the link may be easily saturated.
What you will get is decreased CPU utilization.

You need to go to gigabit or faster link speeds to see any real
throughput improvement.

Later,
David S. Miller
[EMAIL PROTECTED]

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

[PATCH] arch/i386/kernel/bluesmoke.c: missing __init

2001-05-25 Thread pazke


Hi all,

this micropatch adds missing __init for winchip_mcheck_init() function.

Best regards.

-- 
Andrey Panin| Embedded systems software engineer
[EMAIL PROTECTED]| PGP key: http://www.orbita1.ru/~pazke/AndreyPanin.asc


diff -ur -X /usr/dontdiff /linux.vanilla/arch/i386/kernel/bluesmoke.c 
linux/arch/i386/kernel/bluesmoke.c
--- /linux.vanilla/arch/i386/kernel/bluesmoke.c Mon May 21 23:49:24 2001
+++ linux/arch/i386/kernel/bluesmoke.c  Fri May 25 22:58:31 2001
@@ -185,7 +185,7 @@
  * Set up machine check reporting on the Winchip C6 series
  */
  
-static void winchip_mcheck_init(struct cpuinfo_x86 *c)
+static void __init winchip_mcheck_init(struct cpuinfo_x86 *c)
 {
u32 lo, hi;
/* Not supported on C3 */

 PGP signature

Conference update: Linux Developers', UK, 29 Jun - 1 July

2001-05-25 Thread Alasdair Kergon


The confirmed talks for this year's UK Unix User Group Linux Developers' 
Conference in Manchester (Friday 29th June to Sunday 1st July) are now 
listed at:
  http://www.ukuug.org/events/linux2001/speakers.shtml
together with short biographies of the speakers (with some photos).

Topics covered by the programme include:
  vsyscalls, NUMA, zero copy, O_DIRECT, Sledgehammer port,
  JFFS, Dynamic Probes, Generalised Kernel Hooks Interface, 
  Powertweak, LVS, Heartbeat, DCE, Samba TNG, KDE Architecture, 
  Zope, Pymmetry, FlightGear  more

An extra attraction this year will be a demonstration of 'The Baby' 
(the world's first stored-program electronic digital computer) on
the Friday evening.

I'm sending this message now to remind those of you on this list who 
wish to attend (but aren't speaking) that to get into the conference 
at the cheapest price you need to make your booking by the end of next 
week.  The price is low this year because of financial support 
from IBM (who've been particularly generous) and Sistina Software.

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

2.4.4ac17 + LVM-0.9.1beta7: Oops on unmount initrd

2001-05-25 Thread Ville Herva


Whenever I try to boot with root on LVM (using initrd), I get an oops. The
oops happens right after (trying to) unmount old (initrd) root. It also
happens when I run it with root=/dev/sdb (which is a plain ext2fs with no
LVM involved, other than the lvmcreate_initrd-generated initrd).

I patched 2.4.4ac17 with LVM-0.9.1beta7; (the generated patch applied clean
other than that I had to add int get_hardblocksize(kdev_t) {} to fs/buffer.c
(seems to have been removed somewhere between 2.4.1 and 2.4.4). I also tried
2.4.4ac17 vanilla and 2.4.4ac15 vanilla with the same results.

Which is the recommended kernel/LVM version to be used at this time?

Below is the oops and the ksymoops output (gathered by hand, please excuse
possible typos):

(...)
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- found inactive volume group root-stripe
vgscan -- /etc/lvmtab and /etc/lvmtab.d succesfully created
vgscan -- WARNING: This program does not do a VGDA backup of your volume
group
vgchange -- volume group root-stripe successfully activated

VFS: Mounted root (ext2 filesystem).
Trying to unmount old root ... (1)Unable to handle kernel NULL pointer
dereferen
ce at virtual address 0013
  printing eip:
c01997f6
*pde = 
Oops: 
CPU:0
EIP:0010:[c02997f6]
EFLAGS: 00010202
eax: 0003   ebx: 1261  ecx:    edx: cfff3d78
esi:    edi: c15d3160  ebp:    esp: cfff3d58
ds: 0018  es: 0018  ss:  0018
Process swapper (pid: 1, stackpage cfff3000)
Stack: cfff2000  c15d3160 c0136447 cfff3d78  1261 
   c0258528 c017fec3 cfff3d94 cfff3d94  c0228769 cfffa320 c02b5e6c
   c02b5e6c c011b0f6 0001 c011b304 0001  c02a0100 

Call trace: [c0136447] [c017fec3] [c0118769] [c011b0f6] [c011b304]
[c011868c] [c0118596] [c011849b] [c010832f] [c0106f14] [c0199756]
[c01330d6] [c0131447] [c0122cf5] [c01416db] [c0142b81] [c0136641]
[c013484a] [c0134ab0] [c0105000] [c01177e6] [c0105000] [c01051da]
[c010520e] [c0105000] [c01056a6] [c0105200]

Code: 8b 40 10 83 f8 02 7e 62 b8 f0 ff ff ff eb 74 85 c9 b8 ea ff
 0Kernel panic: attempted to kill init!



ksymoops -o /lib/modules/2.4.4-ac17/ -m /usr/src/linux/System.map 
 -v ./vmlinux -K -L   /root/herkules-oops.txt
ksymoops 2.4.1 on i686 2.4.2-2.  Options used
 -v ./vmlinux (specified)
 -K (specified)
 -L (specified)
 -o /lib/modules/2.4.4-ac17/ (specified)
 -m /usr/src/linux/System.map (specified)

No modules in ksyms, skipping objects
Trying to unmount old root ... (1)Unable to handle kernel NULL pointer
dereferen
c01997f6
*pde = 
Oops: 
CPU:0
EIP:0010:[c02997f6]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 0003   ebx: 1261  ecx:    edx: cfff3d78
esi:    edi: c15d3160  ebp:    esp: cfff3d58
ds: 0018  es: 0018  ss:  0018
Stack: cfff2000  c15d3160 c0136447 cfff3d78  1261 
   c0258528 c017fec3 cfff3d94 cfff3d94  c0228769 cfffa320 c02b5e6c
   c02b5e6c c011b0f6 0001 c011b304 0001  c02a0100 
Call trace: [c0136447] [c017fec3] [c0118769] [c011b0f6] [c011b304]
[c011868c] [c0118596] [c011849b] [c010832f] [c0106f14] [c0199756]
[c01330d6] [c0131447] [c0122cf5] [c01416db] [c0142b81] [c0136641]
[c013484a] [c0134ab0] [c0105000] [c01177e6] [c0105000] [c01051da]
[c010520e] [c0105000] [c01056a6] [c0105200]
Code: 8b 40 10 83 f8 02 7e 62 b8 f0 ff ff ff eb 74 85 c9 b8 ea ff

EIP; c02997f6 __devices_1045+5a/a8   =
Trace; c0136447 ioctl_by_bdev+77/90
Trace; c017fec3 batch_entropy_process+b3/c0
Trace; c0118769 __run_task_queue+49/60
Trace; c011b0f6 update_wall_time+16/50
Trace; c011b304 timer_bh+24/250
Trace; c011868c bh_action+1c/60
Trace; c0118596 tasklet_hi_action+36/60
Trace; c011849b do_softirq+5b/80
Trace; c010832f do_IRQ+9f/b0
Trace; c0106f14 ret_from_intr+0/20
Trace; c0199756 rd_make_request+d6/100
Trace; c01330d6 try_to_free_buffers+f6/140
Trace; c0131447 getblk+e7/100
Trace; c0122cf5 truncate_list_pages+145/170
Trace; c01416db destroy_inode+1b/20
Trace; c0142b81 iput+121/130
Trace; c0136641 blkdev_put+71/a0
Trace; c013484a kill_super+da/100
Trace; c0134ab0 do_umount+e0/f0
Trace; c0105000 do_linuxrc+0/e0
Trace; c01177e6 sys_waitpid+16/20
Trace; c0105000 do_linuxrc+0/e0
Trace; c01051da prepare_namespace+fa/120
Trace; c010520e init+e/140
Trace; c0105000 do_linuxrc+0/e0
Trace; c01056a6 kernel_thread+26/30
Trace; c0105200 init+0/140
Code;  c02997f6 __devices_1045+5a/a8
 _EIP:
Code;  c02997f6 __devices_1045+5a/a8   =
   0:   8b 40 10  mov0x10(%eax),%eax   =
Code;  c02997f9 __devices_1045+5d/a8
   3:   83 f8 02  cmp$0x2,%eax
Code;  c02997fc __devices_1045+60/a8
   6:   7e 62 jle6a _EIP+0x6a c0299860
__devices_104a
+c/20
Code;  c02997fe __devices_1045+62/a8
   8:   b8 f0 ff ff ffmov$0xfff0,%eax

Re: Big-ish SCSI disks

2001-05-25 Thread Mark Frazer


Greg Johnson [EMAIL PROTECTED] [01/05/25 08:51]:
 Have you experienced any issues like this?
 Have you successfuly built a kernel that booted on these machines?

I'm also a user of the machine Scott mentioned.  We're booting it off
of a smaller scsi disk, not the 76G disks.

The disks are partitioned as
[mjfrazer@pyle mjfrazer]$ cat /proc/partitions 
major minor  #blocks  name rio rmerge rsect ruse wio wmerge wsect wuse running use 
aveq

   8 08969493 sda  381817 450620 6656780 2095010 544380 197071 5968764 
25617960 0 3648250 27741440
   8 1  40131 sda1 68 382 900 680 58 23 164 5210 0 5780 5890
   8 2  1 sda2 1 0 2 0 0 0 0 0 0 0 0
   8 56835626 sda5 378536 446124 6597282 2077550 543908 194587 5945600 
25601060 0 3635020 27707080
   8 62088418 sda6 3211 4114 58594 16790 414 2461 23000 11750 0 17190 28540
   816   71687369 sdb  5644131 6544183 97506292 29459090 4734971 25903242 
245412336 901326350 0 38801430 931623210
   817   71681998 sdb1 5644130 6544183 97506290 29459520 4734971 25903242 
245412336 901326750 0 38801290 931623950
   832   71687369 sdc  5647535 6545287 97542738 29398000 4707634 25931186 
245412336 931729050 0 39181580 962005610
   833   71681998 sdc1 5647534 6545287 97542736 29398380 4707634 25931186 
245412336 931729530 0 39181540 962005420
   9 0   71681920 md0  0 0 0 0 0 0 0 0 0 0 0
[mjfrazer@pyle mjfrazer]$ 

-mark

 Quoth Scott Murray:
  
  I set up a machine at work a few months ago with two Seagate 73GB
  Ultra160 drives (model ST173404LW) using the Adaptec AIC-7899 adapter
  on board a ServerWorks LE chipset based motherboard.  Everything has
  been working fine using the stock RedHat 7.0 2.2.16-22smp kernel.  I
  also played with some 2.4.1-ac kernels to try out ReiserFS, and also
  had no problems using the disks.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PS/2 Esdi patch #8

2001-05-25 Thread Jens Axboe


On Thu, May 24 2001, Paul Gortmaker wrote:
 Hal Duston wrote:
 
  http://www.sound.net/~hald/projects/ps2esdi/ps2esdi-2.4.4-patch4
  
  Hal Duston
  [EMAIL PROTECTED]
 
 You PS/2 ESDI guys might want to set the max sectors for your
 driver - old default used to be 128, currently 255 (which maybe
 hardware can handle ok?) - the xd and hd drivers were broken until
 a similar fix was added to them.
 
 Probably makes sense for driver to set it regardless, seeing 
 as default (MAX_SECTORS) has changed several times over last
 few months.  At least then it will be under driver control
 and not at the mercy of some global value.

You might want to assign that max_sect array too, otherwise it's just
going to waste space :-)

Take a look at how ps2esdi handles requests -- always processing just
the first segment. Alas, it doesn't matter how big the request is.

-- 
Jens Axboe

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

Re: DVD blockdevice buffers

2001-05-25 Thread Eric W. Biederman


Stephen C. Tweedie [EMAIL PROTECTED] writes:

 Hi,
 
 On Wed, May 23, 2001 at 01:01:56PM -0700, Linus Torvalds wrote:
  
  On Wed, 23 May 2001, Stephen C. Tweedie wrote:
that the filesystems already do. And you can do it a lot _better_ than the
 
current buffer-cache-based approach. Done right, you can actually do all
IO in page-sized chunks, BUT fall down on sector-sized things for the
cases where you want to.
  
   Right, but you still lose the caching in that case.  The write works,
   but the cache becomes nothing more than a buffer.
  
  No. It is still cached. You find the buffer with page-buffer, and when
  all of them are up-to-date (whether from read-in or from having written
  to them all), you just mark the whole page up-to-date.
 
 It works, but *only* if the application writes a whole page worth of
 data.  From the previous emails I had the understanding that this
 application is writing small data items in random 512-byte blocks.  It
 is not writing the rest of the page.  The page never becomes uptodate.
 That in itself isn't a problem, but readpage() can't tell the
 underlying layers that only a part of the page is wanted, so there's
 no way to tell readpage that the page is in fact partially uptodate.
 
 And just telling the application to write the rest of the page too
 isn't going to cut it, because the rest of the page may contain other
 objects which aren't in cache so we can't write them without first
 reading the page.  The only alternative is to change the on-disk
 layout, forcing a minimum PAGESIZE on the IO chunks.
 
  This _works_. Try it on ext2 or NFS today.
 
 Not for this workload.  Now, maybe it's not an interesting workload.
 But shifting the uptodate granularity from buffer to page sized _does_
 impact the effectiveness of the cache for such an application. 
 
  So in short: the page cache supports _today_ all the optimizations.
 
 For write, perhaps; but for subsequent read, generic_read_page
 doesn't see any of the data in the page unless the whole page has been
 written.

generic_read_page???

block_read_full_page seems to handle this correctly.  At least
with respect to keeping the data around, and not doing the I/O
on data we already have.  But it still reads in the unpopulated
parts of the page even if it is unnecessary.

The case we don't get quite right are partial reads that hit cached
data, on a page that doesn't have PG_Uptodate set.  We don't actually
need to do the I/O on the surrounding page to satisfy the read
request.  But we do because generic_file_read doesn't even think about
that case.

For the small random read case we could use a 
mapping-a_ops-readpartialpage 
function that sees if a request can be satisfied entirely 
from cached data.  But this is just to allow generic_file_read
to handle this, case. 

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

Disabling interrupts before block device request call

2001-05-25 Thread Alexandr Andreev


Hi, list
In ll_rw_block.c, before calling block device specific request function 
( i mean do_hd_request, do_ftl_request, ... ) the io_request_lock is 
locking, and all interrupts are disabling. I know, that request handler 
routine have to be atomic, but when we read data from a flash device ( 
for example ) we use a timeouts. Where do we have to enable timer 
interrupts, or should we disable all interrupts?

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

Re: [CHECKER] free bugs in 2.4.4 and 2.4.4-ac8

2001-05-25 Thread Jeff Hartmann


Alan Cox wrote:

 
  return;
 
/u2/engler/mc/oses/linux/2.4.4-ac8/drivers/char/drm/gamma_dma.c:573:gamma_dma_send_buffers:
 ERROR:FREE:561:573: WARN: Use-after-free of last_buf! set by 'drm_free_buffer':561
  DRM_DEBUG(%d running\n, current-pid);
 
 
 Left for the XFree folk
 

This is a false positive, drm_free_buffer doesn't free any memory 
associated with a buffer.  This code construct is fine.

-Jeff

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

RE: changes betwwen 2.2 | 2.4

2001-05-25 Thread Dunlap, Randy


See http://www.firstfloor.org/~andi/softnet/

~Randy
---

 From: sebastien person [mailto:[EMAIL PROTECTED]]
 
 Is there any documents that explain how upgrade network 
 driver from 2.2. to 2.4.? that gives details on changes ...
 
 Or maybe best way is to compare same driver in the twice 
 kernel version ?

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

RE: ac15 and 2.4.5-pre6, pwc format conversion

2001-05-25 Thread Dunlap, Randy


 From: Erik Mouw [mailto:[EMAIL PROTECTED]]
 
 On Fri, May 25, 2001 at 10:48:12AM +0200, Nemosoft Unv. wrote:
  On 25-May-01 Norbert Preining wrote:
   According to ac ChangeLog:
   o   Rip format conversion out of the pwc driver (me)
   | It belongs in user space..
   
   This change is included in 2.4.5-pre6, but
 drivers/usb/pwc-uncompress.c
   pwc-uncompress.c:185: warning: implicit declaration of function
   `vcvt_420i_420p'
  
  That´s what you get for ripping out the guts of a driver. 
 Have a nice day.
 
 The format conversion shouldn't be there in the first place. Format
 conversion is policy, so it doesn't belong in kernel. Note for example
 that none of the sound drivers does sample rate conversion although
 some sound chips are locked at 48kHz only.

Once upon a time there was an agreement (understanding ?) that this
was to be a major 2.5 change (moving video conversion from kernel
drivers to user space) and that lots of apps would need to be
changed for this to be successful.

~Randy

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

Re: Busy on BLKFLSBUF w/initrd

2001-05-25 Thread Maciek Nowacki


On Fri, May 25, 2001 at 01:20:00AM -0400, Scott Murray wrote:
 On Thu, 24 May 2001, Maciek Nowacki wrote:
 
  This method depends on the change_root() mechanism which I had assumed is
  becoming obsolete. It works, and there is no need to mess with
  /proc/sys/kernel/real_root_dev if the root is specified on the command line.
  Trying to use only pivot_root did not work as /dev/rd/0 could never be
  flushed (see previous messages in this thread).
 
 I was having similiar problems a few months back.  I was also trying
 to pivot_root out of an initial ramdisk and then unmount it.  I got it
 working, but kept forgetting to post one of the fixes that I found
 necessary to make it work when using auto-mounted devfs.

 [patch to init/main.c]

Cool, that did it. change_root doesn't occur anymore and BLKFLSBUF clears
things out of memory without any muckage. I will add this one to my patch
directory. Thanks!

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

Re: [CHECKER] large stack variables (=1K) in 2.4.4 and 2.4.4-ac8

2001-05-25 Thread Keith Owens


On Fri, 25 May 2001 08:31:24 -0700 (PDT), 
dean gaudet [EMAIL PROTECTED] wrote:
another possibility for a debugging mode for the kernel would be to hack
gcc to emit something like the following in the prologue of every function
(after the frame is allocated):

IKD already does that, via the CONFIG_DEBUG_KSTACK, CONFIG_KSTACK_METER
and CONFIG_KSTACK_THRESHOLD options.  No need to hack gcc.

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

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Doug Ledford


Adam J. Richter wrote:

 On the question of whether this is nothing more than
 aggregation,

Yes, on that very question, I would argue it is a mere aggregation.

 the firmware works intimately with the device driver to
 produce a unitary result.

Irrelevant.  All drivers work with some sort of firmware on their respective
targets to produce a unitary result, even if that firmware is implemented with
silicon (as a ROM BIOS that loads the proper firmware code, or as
microcode/state hardware built into the chip(set) itself).  As a closely
similar device, think about the 1542 SCSI controller.  It has a BIOS that must
load firmware before the card will work.  The only difference between it and
the device you are arguing about is *how* the firmware gets loaded, and by
what program, not whether the firmware gets loaded or whether the firmware is
required for the device to be in the least bit usefull as a computer
component.

  The part of the driver that runs in the
 device and the CPU side speak a mutually agreed upon protocol, and the
 unitary result is that you do not have to preload the firmware as
 earlier versions of the driver required.

Again, irrelevant.  This has always been done.  In the past, it was done by a
user land program.  Now it's done as part of the kernel.  So, the code now
knows how to speak load the firmware language to the chipset.  This is a
feature of the driver that is, in fact, not in the least bit related to the
firmware itself.  The driver could load garbage to the device and this code
would be working properly.  The choice of what data to upload to a device is
distinctly different from the ability to upload data.

  You actually have to do some
 kernel development to remove the code.

That's because you are assuming that uploading garbage to the device is not an
option.  This is incorrect.  You can in fact remove the firmware and upload
garbage.  The result would be that the device would not work as expected. 
Would this be because of a bug in the firmware loading code?  No.  It would be
because you uploaded garbage.  You could likewise make a much smaller
modification to the driver so that it would allow you to specify whether or
not to upload the code, then tell it not to upload the code, and preload the
firmware as before and things would work without removing the ability to
upload code from the driver.  You could also modify the driver to pass the
firmware to the driver via an initrd or some such and have this code work
without having the .h file included in the .o archive.

  It's not simply the case that
 you could just skip distribution of an extra file and have the rest of
 the functionality work. 

That is exactly the case.  The only change that must be made to remove that .h
file from the driver source is to tell the driver where the *new* location of
the correct firmware is.  This does not constitute a dependancy on having the
firmware included in the driver, it merely constitutes a hard coded, expected
location of the firmware that must be updated whenever the firmware is moved.

 In fact, even if you zeroed out the
 microcode, you would still not get the result of having the driver
 work (e.g., if you had loaded the code originally).  Instead, the
 driver would fill the device with all zeroes.

And thank you for making my point.  The upload code would in fact work, it
would just upload a bogus firmware.  Bad data is bad data.  However, stating
that providing a driver with bad data makes it fail is a non-issue and proves
nothing.  I could write all 0's to the PCI bridge in my system and it wouldn't
work properly.  Du.who would expect it to?

  Greg Kroah-Hartman has
 already said he thinks removal is complicated enough that he does not
 want to voluntarily do it in 2.4.

Aka, he doesn't want to correct/work around the fact that the driver has the
location of the firmware data hard coded right now.  He doesn't have to remove
all the upload code to remove the firmware file, he merely has to teach the
driver to find the firmware code elsewhere or to not upload garbage when it
doesn't know where the firmware is.

  For these reasons, this situation
 is not just shipping two works next to each other (mere aggregation).

Your reasons are bogus, it's a mere aggregation.

 I hope it should be clear now that the GPL can and does
 prohibit #include'ing this and that it is not mere aggregation.
 
 I also hope that people understand that while I think the
 stability argument for not including my fix in 2.4 (which everyone
 seems to like technically) is BS, I would be satisfied if the
 keyspan_usa drivers were now released under GPL-compatible copying
 conditions.  However, it has now been weeks this has not been done.
 
 Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
 [EMAIL PROTECTED] \ /  San Jose, California 95129-1034
 +1 408 261-6630 | g g d r a s i l   United States of America
 fax +1

Re: SyncPPP Generic PPP merge

2001-05-25 Thread Jeff Mcadams


Also sprach Paul Mackerras
Jeff Mcadams writes:
 Indeed.  And let me just throw out another thought.  A clean
 abstraction of the various portions of the PPP functionality is
 beneficial in other ways.  My personal pet project being to add L2TP
 support to the kernel eventually.  A good abstraction of the framing
 capabilities and basic PPP processing would be rather useful in that
 project.

That is exactly what ppp_generic.c is intended to do - it abstracts out
the framing and encapsulation and low-level transport of PPP frames
into ppp channels (see for example ppp_async.c, ppp_synctty.c) while
ppp_generic.c does the basic PPP processing (compression, multilink,
handling the network interface device etc.).

You should be able to write an L2TP channel to work with ppp_generic -
all your code would need to know about is how to take a PPP frame and
encapsulate and send it, and how to receive and decapsulate PPP frames.

[Note to myself: send in a Documentation/ppp_generic.txt which
describes the interface between ppp_generic.c and the channels.]

That's all well and good...and useful...and I'll probably take advantage
of it...but I think you missed my point (although I have no doubt that
my point was not at all clear!)

L2TP potentially has to convert a PPP frame that is given to it to or
from async or sync framing.  ppp_async.c has a ppp_async_encode()
function that would be useful to me in L2TP...it'd kinda suck to have to
duplicate that functionality.  Although it looks like the corresponding
decoding funcationality is tied up in ppp_async_input() which kinda
sucks a bit as well.

Anyway...the idea being that it would be nice to be able to have easy
access to some of the functionality that's part of the channels
currently, but could conceivably be abstracted out even further.

The question, I guess, then becomes whether its worth it to do this
extra layer of abstraction and adding another layer of interaction
between modules for the benefit that it provides.  I certainly wouldn't
squabble if the general concensus was that it wasn't worth it.  :)

Oh, and before anyone points this out, yes, L2TP changing the framing of
the PPP frame above is definitely a violation of layering...if you'd
like, I can point out plenty of other places where L2TP violates
layering principles.  :)

 I would agree that such a project would be 2.5 material.

Do it today if you like, I can't see that adding a new PPP channel
could break anything else, it would be like adding a new driver.

Well...L2TP support is 2.5 material as far as I'm concerned because I'm
not much of a programmer in general, and have never done any kernel
programming...so I'm still getting up to speed on things, and it'll
probably take me until fairly well into 2.5 to even really consider
unleashing a kernel-level creation of my own onto the world.  :)
-- 
Jeff McAdamsEmail: [EMAIL PROTECTED]
Head Network Administrator  Voice: (502) 966-3848
IgLou Internet Services(800) 436-4456
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Big-ish SCSI disks

2001-05-25 Thread Joel Jaeggli


75GB 80GB 180GB all work fine...

your issues are:

location of kernel, below 8GB until you have the chance to turn on lba32
in your lilo.conf...

2GB  filesize limit bites people who use large disks more often (well at
least in my app), use reiserfs.

joelja

On Fri, 25 May 2001, Greg Johnson wrote:

 Hi kernel poeple,

 Can anyone out there say for certain that 76GB SCSI disks should
 just work with kernel versions 2.2 and/or 2.4? We need to get some
 big disk space and have heard reports of problems with disks
 bigger than 30GB under linux.

 Thanks.

 Greg.



-- 
--
Joel Jaeggli   [EMAIL PROTECTED]
Academic User Services   [EMAIL PROTECTED]
 PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.


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

Dedicated Interrupt handling on SMP

2001-05-25 Thread Randy


I'm trying to find the easiest way to to deidcate one CPU to responding
to a specific Interrupt request.
That CPU should only listen for that request while all other CPU should
ignore the interrupt.

Any suggestions? Do I have to muck with the IO_APIC or is there a
simpler way which I just missed?

Any help would be appreciated!

Thank you!

Randy Schumm
Please CC: answer to [EMAIL PROTECTED]


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

Re: Dying disk and filesystem choice.

2001-05-25 Thread Chris Mason




On Friday, May 25, 2001 09:21:42 AM -0700 Hans Reiser [EMAIL PROTECTED]
wrote:
 No, our policy is strictly in sync with and reflective of that of the
 rest of the linux-kernel.  Since the ac series has a different policy, we
 can be different in regards to the ac series.  

Not really, our policy has been much more restrictive than the rest of the
kernel.  Look at the patches we didn't send in.

 
 And I don't begin to comprehend your not sending in the lost disk space
 after crash bug fix (I assume it is what you mean when you refer to lost
 files after a crash, because I know of no lost files after a crash bug,
 please phrase things more carefully), and it really annoys me and the
 users, frankly.  Why you consider that a feature is beyond me.

The patch is a _huge_ change to the way files are deleted and truncated, to
what happens during mount, and to the way transactions work.  It is
effectively a format extension, and must be verified against both 2.2.x
kernels and 2.4.x kernels, in both disk formats.

Before I even consider introducing a change of this size, I want to be as
sure as I can the rest of the code is stable.  It is the only way we can
debug it and stay sane.  Even after I release the code, I won't want it in
an ac series for a while.  It does much more harm than good if it somehow
ruins compatibility with an older kernel, especially in 2.4.x.  

Yes, it is a bug fix.  But, it is a very different kind of bug fix than
something that corrupts files at random, or something that doesn't get
buffers to disk at the right time.  

I won't pretend the fix isn't important, but I won't allow larger changes
to ruin the progress we've made so far.

-chris

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

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Adam J. Richter


Doug Ledford wrote:
Adam J. Richter wrote:

 On the question of whether this is nothing more than
 aggregation,

Yes, on that very question, I would argue it is a mere aggregation.

 the firmware works intimately with the device driver to
 produce a unitary result.

Irrelevant.

The 1991 Abridged 6th Edition of _Black's Law Dictionary_
defines aggregation thusly (unfortunately, talking in terms of
patent law, but it is the most authoratitive definition I have found
so far):

Aggregation: The combination of two or more elements in patent claims,
each of which is unrelated and each of which performs separately and
without cooperation , where combination does not define a composite
integrate mechanism.  Term means that the elements of a claimed
combination are incapabile of co-operation to produce a unitary
result, and in its true sense does not need prior art patents to
support it.


If you want to argue that a court will use a different definition
of aggregation, then please explain why and quote that definition.  Also,
it's important not to forget the word mere.  If the combination is anything
*more* than aggregration, then it's not _merely_ aggregation.  So,
if you wanted to argue from the definition on webster.com:

1 : a group, body, or mass composed of many distinct parts
or individuals
2 a : the collecting of units or parts into a mass or whole
  b : the condition of being so collected

You have to argue that absolutely nothing more than this
is being done.  For example, the code the parts are not working
together.

All drivers work with some sort of firmware on their respective
targets to produce a unitary result, even if that firmware is implemented with
silicon (as a ROM BIOS that loads the proper firmware code, or as
microcode/state hardware built into the chip(set) itself).  As a closely
similar device, think about the 1542 SCSI controller.  [...]

Yes.  It would also be illegal to distribute a GPL'ed driver
.o that #include'd that proprietary firmware.

  You actually have to do some
 kernel development to remove the
 [proprietary firmware from the keyspan_usa drivers].


That's because you are assuming that uploading garbage to the device is not an
option.

No.  If I you change the driver to upload garbage, your
userland loader that just looks for the unitialized device ID will
not be able to get to the uninitialized device before the device
driver claims the interface and trashes it.  So, your supposed act of
disaggregation by zeroing out the effected bytes did not fully
restore the old functionality.

By the way, I'm pretty sure that the situation is even
worse.  The modified driver would not just load garbage to the
ezusb device.  It would tell the ezusb device to jump to it, so
you would not be able to talk to it after that point, other than
by telling the kernel to reset the hub port that the ezusb device
is connected to, in which case, the keyspan_usa driver will again
grab the device and trash it.

I would also argue that searching for a lengthy bit string
in file format and carefully zeroing it out is enough complexity
so that the connection between the two pieces of information (the
firmware integrated in the .o and the rest of the .o) are more
than just aggregation.

I'm not denying that you could imagine a case that is a gray
area where the FSF's understood intention in writing the GPL as
interpreted by a judge from the GPL _and other evidence_ under the
four corner's rule may have been to allow it, but I don't think
we're anywhere near it.  But I agree that one could find some
point where it's a judgement call.  If you get sued and the judge
agrees with the plaintiff, you can lose your house, you life's savings,
etc.  in statutory damages at, I believe, $50k per act of copying.
If the judge agrees with you, well, then you have the satisfaction
of winning that argument.  I hope you appreciate the asymmetry of
the risk and have similarly calibrate your standards for caution,
at least when you advocate exposing others to these kinds of risks.

 you could just skip distribution of an extra file and have the rest of
 the functionality work. 

That is exactly the case.  The only change that must be made to remove that .h
file from the driver source is to tell the driver where the *new* location of
the correct firmware is.

What do you mean remove the .h file from the .o and
tell the driver (open your mouth and talk to the screen?).
We are talking about a .o file.  Copying the .o file is the
act of infringement.

Also, if you're going to respond further, please also
answer the following question.  Are you claiming that the FSF intended
to allow a GPL'ed .o file that contains proprietary firmware for another
microprocessor or are you claiming that FSF made a drafting error in
the writing the GPL?

Adam J.

Re: DVD blockdevice buffers

2001-05-25 Thread Linus Torvalds



On 25 May 2001, Eric W. Biederman wrote:
 
 For the small random read case we could use a 
 mapping-a_ops-readpartialpage 

No, if so I'd prefer to just change readpage() to take the same kinds of
arguments commit_page() does, namely the beginning and end of the read
area. 

Filesystems could choose to ignore the arguments completely, and just act
the way they already do - filling in the whole page.

OR a filesystem might know that the page is partially up-to-date (because
of a partial write), and just return an immediate this area is already
uptodate return code or something. Or it could even fill in the page
partially, and just unlock it (but not mark it up-to-date: the reader then
has to wait for the page and then look at PG_error to decide whether the
partial read succeeded or not).

I don't think it really matters, I have to say. It would be very easy to
implement (all the buffer-based filesystems already use the common
fs/buffer.c readpage, so it would really need changes in just one place,
along with some expanded prototypes with ignored arguments in some other
places).

But it _could_ be a performance helper for some strange loads (write a
partial page and immediately read it back - what a stupid program), and
more importantly Al Viro felt earlier that a partial read approach might
help his metadata-in-page-cache stuff because metadata tends to sometimes
be scattered wildly across the disk.

So then we'd have

int (*readpage)(struct file *, struct page *, unsigned offset, unsigned len);

and the semantics would be:
 - the function needs to start IO for _at_least_ the page area
   [offset, offset+len[
 - return error code for _immediate_ errors (ie not asynchronous)
 - if there was an asynchronous read error, we set PG_error
 - if the page is fully populated, we set PG_uptodate
 - if the page was not fully populated, but the partial read succeeded,
   the filesystem needs to have some way of keeping track of the partial
   success (page-buffers is obviously the way for a block-based one),
   and must _not_ set PG_uptodate.
 - after the asynchronous operation (whether complete, partial or
   unsuccessful), the page is unlocked to tell the reader that it is done.

Now, this would be coupled with:
 - generic_file_read() does the read-ahead decisions, and may decide that
   we really only need a partial page.

But NOTE! The above is meant to potentially avoid unnecessary IO and thus
speed up the read-in. HOWEVER, it _will_ slow down the case where we first
would read a small part of the page and then soon afterwards read in the
rest of the page. I suspect that is the common case by far, and that the
current whole-page approach is the faster one in 99% of all cases. So I'm
not at all convinced that the above is actually worth it.

If somebody can show that the above is worth it and worth implementing (ie
the Al Viro kind of I have a real-life schenario where I'd like to use
it), and implements it (should be a fairly trivial exercise), then I'll
happily accept new semantics like this.

But I do _not_ want to see another new function (partialread()), and I
do _not_ want to see synchronous interfaces (Al's first suggestion).

Linus

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

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Jacob Luna Lundberg



On Fri, 25 May 2001, Adam J. Richter wrote:
   1 : a group, body, or mass composed of many distinct parts
   or individuals
 2 a : the collecting of units or parts into a mass or whole
 b : the condition of being so collected

   You have to argue that absolutely nothing more than this
 is being done.  For example, the code the parts are not working
 together.

Um.  So you mean that if I use a processor with proprietary microcode then
I can't run Linux on it?  ;-)

Seems the argument is about where an arbitrary boundry should be placed
and clearly it's not black and white.

-Jacob

--

At a global level, the most developed countries stabilize the wars
among the outcasts depending on how important each conflict is to the
global economy.

 - ``The Hacker Ethic'' by Pekka Himanen



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

Re: DVD blockdevice buffers




On Fri, 25 May 2001, Linus Torvalds wrote:

 If somebody can show that the above is worth it and worth implementing (ie
 the Al Viro kind of I have a real-life schenario where I'd like to use
 it), and implements it (should be a fairly trivial exercise), then I'll
 happily accept new semantics like this.

OK, here's a real-world scenario: inode table on 1Kb ext2 (or 4Kb on
Alpha, etc.) consists of compact pieces - one per cylinder group.

There is a natural mapping from inodes to offsets in that beast.
However, these pieces can trivially be not page-aligned. readpage()
on a boundary of two pieces means large seek.

Another example (even funnier) is bitmaps. Same story, but here you can
have 1Kb per cylinder group. Which is 8Mb in that case. I.e. on Alpha
it means that readpage() will require 7 seeks, 8Mb each. And the worst
thing being, unless we have corrupted free inodes counters we _will_
find what we need in the first 1Kb chunk we are looking at.

I can easily give more examples - just ask. BTW, the fact that this stuff
is so fragmented is not a bug - we want it evenly spread over disk, just
to have the ability to allocate a block/inode not too far from the piece
of bitmap we'll need to modify.
Al
PS: Uff... OK, looking at the locking stuff in fs/super.c was useful - I've
found a way to do it that is seriously simpler than what I used to do.
Just let me torture it for a couple of hours - so far it looks fine...

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

OOM process killer: strange X11 server crash...

2001-05-25 Thread Ishikawa

Question:
Is there still an issue of OOM process killer to
pickup undesirable process, and/or
that the amount of free system be properly updated
after one such victim process is killed
and a new and/or pending memory request comes in from a different
process
BEFORE the second victim process is picked up and killed?

I am using stock 2.4.4 kernel.

Background:

For the last several weeks,
I reported strange X11 server crash and thought it might have
something to do with the X11 server and/or linux kernel VM management.

I thought linux VM might have something to do because
it was hard to believe that X11 server still had a bug
in bitblt code when I use 16 bit pixel value.
(And I could see no problem in the reported code location after
I looked at the register dump recorded by X server wrapper
and fully debugger-enabled code under gdb, as well as the
output of memory-related system call traces.
[Well, I am not an expert of mmap/munmap and so
the last judgement of mine may not be quite reliable.]

Anyway, in order to figure out exactly what is going on, I re-compiled
the X11 server with debug symbol as I mentioned
(after downloading all the X86free source code) and
I see the same X11 server crash if I follow a certain steps
using netscape 4.77. (It has something to do with a visiting a page
and do a search on the same string and find the successive occurrence.)

Alan suggested that there still may be a genuin X11 bug still,
so I began using free memory bug checkers to see if I could
find the real cause. (Too bad, I can't shell out money for Purify.)

Problem with these memory checkers is the much overhead
of memory allocation. Hesenberg effect kicked in.
Now I see crashes at different spots.
I tried three tools before I found the possibly NEW problem with
OOM process killer: I tried electric fence, memprof, and debauch in
these sequence .

With electric fennce, the X11 server even refused to start completely.
Considering that electric fence uses up a memory page for one single
allocation atempt no matter how small, this is understanble.
I have 256MB of memory and 80MB swap.
   (This has given me enough clue to the problem I was facing, but
I falied to notice it the first time it happened, and continued
testing
with other tools.)

So I gave up on electric fence although if I did have memory allocation
problem with X11 server, it was my best bet.

With memprof, it was not clear if the profiling function could detect
problems that I was facing. Lucily, I could reproduce the crash, but
could not find much useful information. (Given the original
purpose of memprof, this again is reasonable. It was meant to
detect memory leaks. For this, it worked great!
I was rather surprised to find a lot of left over memory allocation
chunks.
Great tool if you are worried about these sort of problems.).

   http://people.redhat.com/otaylor/memprof/

So I finally tested X11 server with debauch next and hit upon a possible

issue with OOM:

http://quorum.tamu.edu/jon/gnu/

Now with debauch, I could run netscape, and
during the operation sequence which
would have caused the X11 server to crash in my original
setting, the netscape
and X11 seemed to get hung.: it seems to be allocating much
memory and mouse won't be responding any time soon.
(I heard occasional disk access which is caused by
the writing of debauch message to the xdm.log file.)
But, I could switch to virtual console one to look at ps output.
So after a while,  I gave up and I tried to kill xdm when I noticed
interesting console messages (part of which was lost
since it scrolled way too fast and disappeared)
I have no idea why I have not seen this before.
But, it seems that over-the-memory condition occurred due to
the added overhead of debauch PLUS the original
condition caused by the particular operation of netscape.
(Yes, I suspected some virtual memory-related problem, but
my original question was why netscape was not crashing,
and X11 server?
It may be that OOM process killer was picking up X11 server
as well as netscape and I had no way of knowing, ...
Oh well, this is NOT probalby what happened in my
original problem cases because I didn't see
OOM process killer messages when X11 servers crashed in the
original steps. More testing and investigaton necessary.)

Anyway, this time, here is what was printed on the screen (the tail end
of it).
--- begin quote ---
... could not record the above. they scrolled up and disapper...
Out of Memory: Killed process 4550 (XF8_SVGA.ati12).
__alloc_pages: 0-order allocation failed.
VM: killing process XF86_SVGA.ati12
--- end quote

And before the message disappeared, I think I saw the
netscape process was killed, too.
I checked the log message and looked for "Memory"
Sure enough I foundnetscapewas killed, too, in this case.

May 25 09:16:46 duron kernel: Memory: 255280k/262080k available (978k
kernel cod
e, 6412k reserved, 378k data, 224k init, 0k highmem)
...
May 25 10:45:31 duron kernel: Out of Memory:

Re: [CHECKER] free bugs in 2.4.4 and 2.4.4-ac8

2001-05-25 Thread Rik van Riel


On Thu, 24 May 2001, Dawson Engler wrote:

 Boilerplate disclaimer:
 - this is part of a one-time large batch of errors.  In the future,
   we'll send out incremental bug reports along with a pointer to
   the bug database on our website.

Personally, I'd like to see these every month or so, so
the bugs will go away within a month of their introduction.

Ideally, there never should be a large batch of any kind
of automatically checked bugs, except when a new check is
introduced...

OTOH, splitting them up may be a good idea, especially if
the email with the bug in it is CC'd to the person who is
listed in MAINTAINERS as taking care of that part of the
kernel ;)

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

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

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

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

Re: DVD blockdevice buffers

2001-05-25 Thread Linus Torvalds



On Fri, 25 May 2001, Alexander Viro wrote:
 
 OK, here's a real-world scenario: inode table on 1Kb ext2 (or 4Kb on
 Alpha, etc.) consists of compact pieces - one per cylinder group.
 
 There is a natural mapping from inodes to offsets in that beast.
 However, these pieces can trivially be not page-aligned. readpage()
 on a boundary of two pieces means large seek.

Yes.

But by real-world I mean you can tell in real life.

I see the theoretical arguments for it. But I want to know that it makes a
real difference under real load.

For example, I suspect that the metadata bitmaps in particular cache so
well that the fact that we need to do several seeks over them every once
in a while is a non-issue: we might be happier having the bitmaps in
memory (and having simpler code), than try to avoid the occasional seeks.

The simpler code argument in particular is, I think, a fairly strong
one. Our current bitmap code is quite horrible, with multiple layers of
caching (ext2 will explicitly hold references to some blocks, while at the
same time depending on the buffer cache to cache the other blocks -
nightmare)

Linus

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

RE: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Torrey Hoffman



Adam J. Richter wrote:
 Doug Ledford wrote:
 Adam J. Richter wrote:
 
  On the question of whether this is nothing more than
  aggregation,

... 
[patent law definition of aggregation]
...

Well, I'm just an interested bystander.  But having read the recent 
lkml posts on this issue, it seems to me that the critical points are:

From the point of view of the kernel, the firmware code is just a big
magic number that turns on the firmware.  

The kernel is not _linked_ _with_ the firmware code.

The kernel doesn't even _exec_ the firmware.

The firmware code can be used, unmodified, in other operating systems.

The firmware code does not run in the same address space as the kernel.

In principle, and maybe in practice, that firmware code might be running
on a different processor, with different RAM, and a different instruction
set.  

It's obviously not part of the kernel! 

Torrey Hoffman  -  [EMAIL PROTECTED]
---
I find this corpse guilty of carrying a concealed weapon and I fine it $40. 
-- Judge Roy Bean, finding a pistol and $40 on a man he'd just shot. 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: OOM process killer: strange X11 server crash...

2001-05-25 Thread Jesse Pollard


Ishikawa [EMAIL PROTECTED]:

Anyway, this time, here is what was printed on the screen (the tail end
 of it).
 --- begin quote ---
 ... could not record the above. they scrolled up and disapper...
 Out of Memory: Killed process 4550 (XF8_SVGA.ati12).
 __alloc_pages: 0-order allocation failed.
 VM: killing process XF86_SVGA.ati12
 --- end quote
 
 And before the message disappeared, I think I saw the
 netscape process was killed, too.
 I checked the log message and looked for Memory
 Sure enough I foundnetscapewas killed, too, in this case.
 
 May 25 09:16:46 duron kernel: Memory: 255280k/262080k available (978k
 kernel cod
 e, 6412k reserved, 378k data, 224k init, 0k highmem)
 ...
 May 25 10:45:31 duron kernel: Out of Memory: Killed process 5562
 (netscape).
 May 25 10:45:31 duron kernel: Out of Memory: Killed process 5450
 (XF86_SVGA.ati1
 2).
  ...

Something I have noticed with netscape is that if the X server is
killed out from under it (user logout, or kill X11 manually) is that
it continues to run. The process appears to be looping around select
and attempting to reconnect to the (now dead) X server, and not exiting
like it should.

Other times it seems to terminate properly. The problem may exhibit itself
if netscape is waiting for some asynchronous event (like the name service
lookup maybe) and misses the/a signal that it's socket to the X server
has failed. If a kill -15 doesn't terminate the rogue netscape, then it
takes a kill -9 . In my expierence it is in a tight loop, and ignoring
normal user input. It could still be expanding memory consumption...


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

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

Re: DVD blockdevice buffers




On Fri, 25 May 2001, Linus Torvalds wrote:

 For example, I suspect that the metadata bitmaps in particular cache so
 well that the fact that we need to do several seeks over them every once
 in a while is a non-issue: we might be happier having the bitmaps in
 memory (and having simpler code), than try to avoid the occasional seeks.

 The simpler code argument in particular is, I think, a fairly strong
 one. Our current bitmap code is quite horrible, with multiple layers of
 caching (ext2 will explicitly hold references to some blocks, while at the
 same time depending on the buffer cache to cache the other blocks -
 nightmare)

Oh, current code is a complete mess - no arguments here. 8-element LRU.
Combined with the fact that directories allocation tries to get even
distribution of directory inodes by cylinder groups, you blow that LRU
completely on a regular basis if your fs is larger that 16 cg. For 1Kb
blocks fs it's 128Mb. For 4Kb - 2Gb. And pain starts at the half of that
size.

If you are OK with adding two extra arguments to -readpage() I could
submit a patch replacing that with plain and simple page cache by tomorrow.
It should not be a problem to port, but I want to get some sleep before
testing it...

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

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Larry McVoy


On Fri, May 25, 2001 at 10:02:08AM -0700, Adam J. Richter wrote:
   If you want to argue that a court will use a different definition
 of aggregation, then please explain why and quote that definition.  Also,
 it's important not to forget the word mere.  If the combination is anything
 *more* than aggregration, then it's not _merely_ aggregation.  So,
 if you wanted to argue from the definition on webster.com:

Adam, the point is not what the GPL says or what the definition is.
The point is what is legal.  You can, for example, write a license
which says

By running the software covered by this license, you agree to 
become my personal slave and you will be obligated to bring
me coffee each morning for the rest of my life, greating
me with a Good morning, master, here is your coffee oh
most magnificent one.

If anyone is stupid enough to obey such a license, they need help.
The problem is that licenses can write whatever they want, but what they
say only has meaning if it is enforceable.  The license above would
be found to be unenforceable by the courts in about 30 seconds or so.

OK, so what does this have to do with aggregration?  The prevailing 
legal opinions seem to be that viral licenses cannot extend their
terms across boundaries.  The aggregration verbage is alluding to that
boundary.  If it is true that viral licenses cannot cross some sort of
boundary (and obviously it is true, otherwise the system call boundary
would not be recognized and all programs ever run on Linux would be GPLed),
then the GPL doesn't get to say what it means by that boundary, the law
gets to say that.  Just like the above license doesn't get to create
slaves, some issues are outside the license scope.

I've spoken with my lawyer in depth about this and the feeling is that
there are boundaries which licenses may not cross, and the definition
of such a boundary is one where you could remove the code on one side
of the boundary (aka interface), replace it with completely different 
code, and get substantially the same behaviour.  A device driver is a
good example.  
-- 
---
Larry McVoy  lm at bitmover.com   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] (part 4) fs/super.c cleanup


* MNT_VISIBLE is gone. We simply do not insert vfsmounts we don't
want to see into the vfsmntlist. The only place where it is used is
get_filesystem_info(), so it's obviously correct.

Please, apply.

PS: I've done a different locking scheme for superblocks, so right
now I'm testing it on a complete patch. I.e. that part is postponed until
it gets some testing. So the next several pieces will be just a bunch
of trivial cleanups.

diff -urN S5-pre6/fs/super.c S5-pre6-MNT_VISIBLE/fs/super.c
--- S5-pre6/fs/super.c  Thu May 24 22:15:03 2001
+++ S5-pre6-MNT_VISIBLE/fs/super.c  Thu May 24 23:57:23 2001
@@ -314,13 +314,6 @@
  * Potential reason for failure (aside of trivial lack of memory) is a
  * deleted mountpoint. Caller must hold -i_zombie on mountpoint
  * dentry (if any).
- *
- * Node is marked as MNT_VISIBLE (visible in /proc/mounts) unless both
- * @nd and @devname are %NULL. It works since we pass non-%NULL @devname
- * when we are mounting root and kern_mount() filesystems are deviceless.
- * If we will get a kern_mount() filesystem with nontrivial @devname we
- * will have to pass the visibility flag explicitly, so if we will add
- * support for such beasts we'll have to change prototype.
  */
 
 static struct vfsmount *add_vfsmnt(struct nameidata *nd,
@@ -336,9 +329,6 @@
goto out;
memset(mnt, 0, sizeof(struct vfsmount));
 
-   if (nd || dev_name)
-   mnt-mnt_flags = MNT_VISIBLE;
-
/* It may be NULL, but who cares? */
if (dev_name) {
name = kmalloc(strlen(dev_name)+1, GFP_KERNEL);
@@ -366,7 +356,8 @@
}
INIT_LIST_HEAD(mnt-mnt_mounts);
list_add(mnt-mnt_instances, sb-s_mounts);
-   list_add(mnt-mnt_list, vfsmntlist.prev);
+   if (nd || dev_name)
+   list_add(mnt-mnt_list, vfsmntlist.prev);
spin_unlock(dcache_lock);
 out:
return mnt;
@@ -500,8 +491,6 @@
 
for (p = vfsmntlist.next; p != vfsmntlist; p = p-next) {
struct vfsmount *tmp = list_entry(p, struct vfsmount, mnt_list);
-   if (!(tmp-mnt_flags  MNT_VISIBLE))
-   continue;
path = d_path(tmp-mnt_root, tmp, buffer, PAGE_SIZE);
if (!path)
continue;
diff -urN S5-pre6/include/linux/mount.h S5-pre6-MNT_VISIBLE/include/linux/mount.h
--- S5-pre6/include/linux/mount.h   Thu May 24 22:15:06 2001
+++ S5-pre6-MNT_VISIBLE/include/linux/mount.h   Thu May 24 23:58:00 2001
@@ -12,8 +12,6 @@
 #define _LINUX_MOUNT_H
 #ifdef __KERNEL__
 
-#define MNT_VISIBLE1
-
 struct vfsmount
 {
struct dentry *mnt_mountpoint;  /* dentry of mountpoint */

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

[PATCH] (part 5) fs/super.c cleanups


Takes allocation/initalization of vfsmounts into separate function.
We will need this separation to deal with several places where we need
a non-blocking (and non-failing) equivalent of add_vfsmnt(). There allocation
will be done outside of critical area.

Please, apply.

diff -urN S5-pre6-MNT_VISIBLE/fs/super.c S5-pre6-alloc_vfsmnt/fs/super.c
--- S5-pre6-MNT_VISIBLE/fs/super.c  Thu May 24 23:57:23 2001
+++ S5-pre6-alloc_vfsmnt/fs/super.c Fri May 25 04:13:30 2001
@@ -282,6 +282,21 @@
 
 static LIST_HEAD(vfsmntlist);
 
+struct vfsmount *alloc_vfsmnt(void)
+{
+   struct vfsmount *mnt = kmalloc(sizeof(struct vfsmount), GFP_KERNEL); 
+   if (mnt) {
+   memset(mnt, 0, sizeof(struct vfsmount));
+   atomic_set(mnt-mnt_count,1);
+   INIT_LIST_HEAD(mnt-mnt_clash);
+   INIT_LIST_HEAD(mnt-mnt_child);
+   INIT_LIST_HEAD(mnt-mnt_mounts);
+   INIT_LIST_HEAD(mnt-mnt_list);
+   mnt-mnt_owner = current-uid;
+   }
+   return mnt;
+}
+
 static void detach_mnt(struct vfsmount *mnt, struct nameidata *old_nd)
 {
old_nd-dentry = mnt-mnt_mountpoint;
@@ -324,10 +339,9 @@
struct super_block *sb = root-d_inode-i_sb;
char *name;
 
-   mnt = kmalloc(sizeof(struct vfsmount), GFP_KERNEL);
+   mnt = alloc_vfsmnt();
if (!mnt)
goto out;
-   memset(mnt, 0, sizeof(struct vfsmount));
 
/* It may be NULL, but who cares? */
if (dev_name) {
@@ -337,8 +351,6 @@
mnt-mnt_devname = name;
}
}
-   mnt-mnt_owner = current-uid;
-   atomic_set(mnt-mnt_count,1);
mnt-mnt_sb = sb;
 
spin_lock(dcache_lock);
@@ -351,10 +363,7 @@
} else {
mnt-mnt_mountpoint = mnt-mnt_root;
mnt-mnt_parent = mnt;
-   INIT_LIST_HEAD(mnt-mnt_child);
-   INIT_LIST_HEAD(mnt-mnt_clash);
}
-   INIT_LIST_HEAD(mnt-mnt_mounts);
list_add(mnt-mnt_instances, sb-s_mounts);
if (nd || dev_name)
list_add(mnt-mnt_list, vfsmntlist.prev);

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

Re: Why O_SYNC and fsync are slow in Linux?

2001-05-25 Thread Lance Larsh


On Wed, 16 May 2001, Heikki Tuuri wrote:

 On Red Hat 6.2 and 7.? Intel big block writes are very slow if
 I open the file with O_SYNC. I call pwrite to write 1 MB chunks to
 the file, and I get only 1 MB/s write speed. If I open without O_SYNC
 and call fsync only after writing the whole 100 MB file,
 I get 5 MB/s. I got the same adequate speed 5 MB/s with 16 MB writes
 after which I called fdatasync.

When you open with O_SYNC, the data must go all the way to disk on
every write call.  This means you get at least one disk access for
every write, and possibly more if the writes are large (64k).

When you don't use O_SYNC and only flush after all writes have been
submitted by the application, then the kernel is able to combine writes
in the cache and at the blk dev layer.  Therefore you end up with fewer
accesses to the physical disk, which makes it much faster.

 On a Linux-Compaq Alpha I measured the following: if I open with O_SYNC,
 I can flush the end of my file (it is a log file) to
 disk 170 times / second. If I do not open with O_SYNC,
 but call fsync or fdatasync after each write, I get only 50
 writes/second.

This is generally the case.  If you need to sync every write, O_SYNC
is usually faster than fsync.  If you don't need to sync
every individual write, then a single fsync after the last
write is the fastest to get all the data to disk.

 
 On the Red Hat 7.? I get 500 writes per second if I open with O_SYNC.
 That is too much because the disk does not rotate
 500 rotations/second. Does the disk fool the operating
 system to believe a write has ended while it has not?

Are you using an IDE disk?  If so, it probably has a huge cache.

-Lance

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

Re: CRAK: a process checkpoint/restart kernel module

2001-05-25 Thread Hua Zhong



Please cc to me - I am currently off the list.

On Wed, 23 May 2001, Pavel Machek wrote:

 Hi!!

 One question: can crak be used for process migration (assuming nodes
 share filesystem)? [As in, node of
 cluster is going down so we checkpoint and resume on some other node?]

Yes, as long as the resources (opened files) can be accessed on both
nodes.

 PS: Can it checkpoint/restart X applications? I guess some games would
 be easier with ability to checkpoint ;-)

Which means we need to support migrating network sockets.  I added
TCP/IPv4 socket support this spring (currently for 2.2.19 and will port to
2.4 shortly), and I tested migrating X.  In certain cases I
successfully migrated some applications like Emacs, Acroread, etc, but
there is a problem.  (The socket migration code has not been put online,
but I'd like to discuss how it works here)

Basically I took three steps to migrate a TCP socket.  Assuming A and B
are the two peers:

1. shutdown process A while keep B open
2. restart A and re-establish the socket which points to B
3. change the socket on B to point to the new location of A

The problem is, during this stage, if B sends packets to A before 3 is
complete, B's socket will get a RST.  In the case of X, if you click or
move cursor on A's window when A is being migrated, it will crash.

One solution might be that freezing B when A is being migrated.  There are
two ways to freeze B:

1) send a SIGSTOP to B and later SIGCONT it.  It's simple to do but would
result in freezing the whole process, which is bad in certain cases (e.g.,
the whole X server is stopped - the screen freezes).

2) freeze the socket only.  I tried to set window sizes of B's socket to
zero, but it didn't work (I didn't try too hard though).  I'd like to know
whether there is a way to do so.

Unfortunately, even we use 1), it still doesn't solve the whole problem.
For exmaple, when the X connection is tunneled through ssh, you can only
freeze the sshd process, but packets are still sent to it when you click
on the server side, which will crash the connection as well (at least for
my current implementation).  One reason might be I didn't take care of
pending packets when I migrage a socket, but in fact, the real problem of
socket migration is that you don't know what would happen if the network
address is changed.  Appliactions may depend on it (such as FTP).  A
virtual network interface should be provided to solve the problem
gracefully.

As of migrating games, hmmm, here are my 2cents:

1) Most online games use UDP, and CRAK hasn't implemented UDP support.
It's much easier than TCP though.
2) I am not sure of what the effect would be if we changed the network
address.  Most games requires you to join a group before you start, and
maybe the group membership is based on network address.

At last, there are a lot of work left to do to make process migration work
truly reliably, and CRAK is still far from that.  For example, what if an
application depends on pid?  What if a process uses temporary files
(/tmp) which are not present on other nodes?  Or what if an application
deletes files that are still opened (evil programs like make)?  Not all of
these are possible, or possible without enough kernel cooperation.
Particularly hard when CRAK is just a kernel module.

I am still a lerner.  I wrote CRAK mostly for fun, but I'd like to
hear some advice from the kernel hacker community if people think it has
some value.

 --
 Philips Velo 1: 1x4x8, 300gram, 60, 12MB, 40bogomips, linux, mutt,
 details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



Hua Zhong

Central Research Facilities Department of Computer Science
Columbia University New York, NY 10027
Email: [EMAIL PROTECTED] http://www.cs.columbia.edu/~huaz



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

Re: DVD blockdevice buffers

2001-05-25 Thread Stephen C. Tweedie


Hi,

On Fri, May 25, 2001 at 09:09:37AM -0600, Eric W. Biederman wrote:

 The case we don't get quite right are partial reads that hit cached
 data, on a page that doesn't have PG_Uptodate set.  We don't actually
 need to do the I/O on the surrounding page to satisfy the read
 request.  But we do because generic_file_read doesn't even think about
 that case.

That's *precisely* the case in question.  The whole design of the page
cache involves reading entire pages at a time, in fact.  We _could_
read in only partial pages, but in that case we end up wasting a lot
of the page.

 For the small random read case we could use a 
 mapping-a_ops-readpartialpage 
 function that sees if a request can be satisfied entirely 
 from cached data.  But this is just to allow generic_file_read
 to handle this, case. 

Agreed.  The only case where blockdev-in-pagecache really results in
significantly more IO is partial writes followed by partial reads.
Reads from totally-uncached pages ought to just fill the entire page
from disk; it's only when there is something already present
in the cache for that page that we want to look for partial buffers.

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

Re: DVD blockdevice buffers

2001-05-25 Thread Stephen C. Tweedie


Hi,

On Fri, May 25, 2001 at 02:24:52PM -0400, Alexander Viro wrote:

 If you are OK with adding two extra arguments to -readpage() I could
 submit a patch replacing that with plain and simple page cache by tomorrow.
 It should not be a problem to port, but I want to get some sleep before
 testing it...

The problem will be returning the IO completion status.  We can't just
rely on PG_Error: what happens if two separate partial reads are
submitted at once within the same page, yet the page is not completely
in cache?  If we forced readpage to be synchronous in that case we
could just return the status directly.  Otherwise we need a separate
way of determining the completion status once the page becomes
unlocked (eg. have a special readpage return which means all done,
completion status is X, and resubmit the readpage to get that
completion status once the page lock is dropped.)

--Stephen

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

Re: [CHECKER] error path memory leaks in 2.4.4 and 2.4.4-ac8

2001-05-25 Thread arjan


In article [EMAIL PROTECTED] you wrote:
 I believe we can make that a short. Arjan?

 Is the general way to fix these too-large stack vars to heap allocate
 them?  Or is it preferable to put a static in front of them, if the
 routine is non-reentrant?

You're not always allowed to allocate memory. Esp in filesystems it can be
tricky as writes can be triggered by low-memory situations and allocating
memory their is suboptimal.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] (part 6) fs/super.c cleanups


Expands add_vfsmnt() call in kern_mount(), takes alloc_vfsmnt()
before reading superblock and makes (in add_vfsmnt()) insertion into
vfsmntlist unconditional (kern_mount()) was the only case when we didn't
want it to happen. Moreover, recovery in kern_mount() becomes simpler.

Please, apply.
diff -urN S5-pre6-alloc_vfsmnt/fs/super.c S5-pre6-kern_mount/fs/super.c
--- S5-pre6-alloc_vfsmnt/fs/super.c Fri May 25 04:13:30 2001
+++ S5-pre6-kern_mount/fs/super.c   Fri May 25 15:07:19 2001
@@ -365,8 +365,7 @@
mnt-mnt_parent = mnt;
}
list_add(mnt-mnt_instances, sb-s_mounts);
-   if (nd || dev_name)
-   list_add(mnt-mnt_list, vfsmntlist.prev);
+   list_add(mnt-mnt_list, vfsmntlist.prev);
spin_unlock(dcache_lock);
 out:
return mnt;
@@ -945,21 +944,31 @@
 
 struct vfsmount *kern_mount(struct file_system_type *type)
 {
-   kdev_t dev = get_unnamed_dev();
struct super_block *sb;
-   struct vfsmount *mnt;
-   if (!dev)
+   struct vfsmount *mnt = alloc_vfsmnt();
+   kdev_t dev;
+
+   if (!mnt)
+   return ERR_PTR(-ENOMEM);
+
+   dev = get_unnamed_dev();
+   if (!dev) {
+   kfree(mnt);
return ERR_PTR(-EMFILE);
+   }
sb = read_super(dev, NULL, type, 0, NULL, 0);
if (!sb) {
put_unnamed_dev(dev);
+   kfree(mnt);
return ERR_PTR(-EINVAL);
}
-   mnt = add_vfsmnt(NULL, sb-s_root, NULL);
-   if (!mnt) {
-   kill_super(sb);
-   return ERR_PTR(-ENOMEM);
-   }
+   mnt-mnt_sb = sb;
+   mnt-mnt_root = dget(sb-s_root);
+   mnt-mnt_mountpoint = mnt-mnt_root;
+   mnt-mnt_parent = mnt;
+   spin_lock(dcache_lock);
+   list_add(mnt-mnt_instances, sb-s_mounts);
+   spin_unlock(dcache_lock);
type-kern_mnt = mnt;
return mnt;
 }

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

Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h

2001-05-25 Thread Doug Ledford


Adam J. Richter wrote:
 
 Doug Ledford wrote:
 Adam J. Richter wrote:
 
  On the question of whether this is nothing more than
  aggregation,
 
 Yes, on that very question, I would argue it is a mere aggregation.
 
  the firmware works intimately with the device driver to
  produce a unitary result.
 
 Irrelevant.
 
 The 1991 Abridged 6th Edition of _Black's Law Dictionary_
 defines aggregation thusly (unfortunately, talking in terms of
 patent law, but it is the most authoratitive definition I have found
 so far):
 
 Aggregation: The combination of two or more elements in patent claims,

So the first thing the attorney would have to do is convince the judge that
the definition of a term from patent claims means what you are claiming it
means in software licensing claims.

 each of which is unrelated and each of which performs separately and
 without cooperation , where combination does not define a composite
 integrate mechanism.  Term means that the elements of a claimed
 combination are incapabile of co-operation to produce a unitary
 result, and in its true sense does not need prior art patents to
 support it.
 
 If you want to argue that a court will use a different definition
 of aggregation, then please explain why and quote that definition.

Why is because the definition you have been pushing here is anything that
results in a unitary result.  That's flawed (it's actually quite insane
IMNSHO, since the major point of my last email was that *damn near everything*
in the computer world results in a unitary result, including the glibc -
kernel syscall interface Larry mentions in his email, the module loading
interface that the kernel exports, etc.  The point of my last email was
largely that what you are calling a unitary result, is in fact what most
people call an API).  To quote Larry, it would take roughly 30 seconds to get
that definition of unitary result thrown out as overly broad.

  Also,
 it's important not to forget the word mere.  If the combination is anything
 *more* than aggregration, then it's not _merely_ aggregation.  So,
 if you wanted to argue from the definition on webster.com:
 
 1 : a group, body, or mass composed of many distinct parts
 or individuals
 2 a : the collecting of units or parts into a mass or whole
   b : the condition of being so collected
 
 You have to argue that absolutely nothing more than this
 is being done.  For example, the code the parts are not working
 together.

Yep, that's pretty much what it is.  The firmware is what actually implements
the API on the device we are discussing.  The driver interacts via said API. 
The firmware is actually an opaque object that could be replaced with any
other firmware that implements the same API and things would work the same. 
The downloading of the firmware is just one step in the initialization of the
device and is not dependant on any given firmware version or release.  The
placing of the driver that downloads any valid firmware to the device (or
invalid for that matter) and the firmware itself in the same .o is a matter of
convenience and is merely collecting two individual parts into a mass.

 All drivers work with some sort of firmware on their respective
 targets to produce a unitary result, even if that firmware is implemented with
 silicon (as a ROM BIOS that loads the proper firmware code, or as
 microcode/state hardware built into the chip(set) itself).  As a closely
 similar device, think about the 1542 SCSI controller.  [...]
 
 Yes.  It would also be illegal to distribute a GPL'ed driver
 .o that #include'd that proprietary firmware.
 
   You actually have to do some
  kernel development to remove the
  [proprietary firmware from the keyspan_usa drivers].
 
 That's because you are assuming that uploading garbage to the device is not an
 option.
 
 No.  If I you change the driver to upload garbage, your
 userland loader that just looks for the unitialized device ID will
 not be able to get to the uninitialized device before the device
 driver claims the interface and trashes it.  So, your supposed act of
 disaggregation by zeroing out the effected bytes did not fully
 restore the old functionality.

You missed the point.  The firmware is an opaque object to the driver, not an
integral part of the driver.  Read above.

 That is exactly the case.  The only change that must be made to remove that .h
 file from the driver source is to tell the driver where the *new* location of
 the correct firmware is.
 
 What do you mean remove the .h file from the .o and
 tell the driver (open your mouth and talk to the screen?).

The current driver knows where the firmware is by #include'ing it in itself. 
That is, in and of itself, a means of locating the firmware.  You could
replace that with a code snippet that loaded the firmware from a file on disk
or on an initrd and

[PATCH] (part 7) fs/super.c cleanups


Handling of refcounts for FS_SINGLE filesystems moved to
add_vfsmnt(). That's the first half of real fix for FS_SINGLE mess -
we should make it read_super() if we hadn't done it yet, otherwise
return what we have. That will make kern_mount() uses simpler and
remove all special-casing with refcounts. in the hindsight, the trick
I've used in 2.4.0-test2 merge was ugly - kern_mount() should be used
only when kernel explicitly asks for a vfsmount of its own, not as
as part of init for FS_SINGLE filesystems. Fix is easy, but that chunk
touches several files besides fs/super.c and requires sane locking
to be safe. Patch below is the preliminary part local to fs/super.c.

Please, apply.

diff -urN S5-pre6-kern_mount/fs/super.c S5-pre6-single1/fs/super.c
--- S5-pre6-kern_mount/fs/super.c   Fri May 25 15:07:19 2001
+++ S5-pre6-single1/fs/super.c  Fri May 25 15:12:36 2001
@@ -367,6 +367,8 @@
list_add(mnt-mnt_instances, sb-s_mounts);
list_add(mnt-mnt_list, vfsmntlist.prev);
spin_unlock(dcache_lock);
+   if (sb-s_type-fs_flags  FS_SINGLE)
+   get_filesystem(sb-s_type);
 out:
return mnt;
 fail:
@@ -852,7 +854,6 @@
sb = fs_type-kern_mnt-mnt_sb;
if (!sb)
BUG();
-   get_filesystem(fs_type);
do_remount_sb(sb, flags, data);
return sb;
 }
@@ -1165,8 +1166,6 @@
goto out2;
 
err = -ENOMEM;
-   if (old_nd.mnt-mnt_sb-s_type-fs_flags  FS_SINGLE)
-   get_filesystem(old_nd.mnt-mnt_sb-s_type);

down(mount_sem);
/* there we go */
@@ -1177,8 +1176,6 @@
err = 0;
up(new_nd.dentry-d_inode-i_zombie);
up(mount_sem);
-   if (err  old_nd.mnt-mnt_sb-s_type-fs_flags  FS_SINGLE)
-   put_filesystem(old_nd.mnt-mnt_sb-s_type);
 out2:
path_release(new_nd);
 out1:
@@ -1369,8 +1366,6 @@
return retval;
 
 fail:
-   if (fstype-fs_flags  FS_SINGLE)
-   put_filesystem(fstype);
kill_super(sb);
goto unlock_out;
 }

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

[PATCH] init - initdata for drivers/ide/feature.c (244-ac16)


Hi.

The following patch changes an __init to an __initdata. Applies
against 2.4.4-ac16.


--- linux-244-ac16-clean/arch/ppc/kernel/feature.c  Sat May 19 21:06:18 2001+++ 
linux-244-ac16/arch/ppc/kernel/feature.cMon May 21 00:04:35 2001
@@ -267,7 +267,7 @@
 static struct board_features_t {
char*   compatible;
u32 features;
-} board_features_datas[] __init =
+} board_features_datas[] __initdata =
 {
   {AAPL,PowerMac G3, 0   }, /* Beige G3 */
   {iMac,1,   0   }, /* First iMac 
(gossamer) */

-- 
Regards,
Rasmus([EMAIL PROTECTED])

We're going to turn this team around 360 degrees.
-Jason Kidd, upon his drafting to the Dallas Mavericks
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] check kmalloc return in ide-cd.c (244-ac16)


Hi.

This patch adds a check for the return value from kmalloc in
ide_cdrom_open. Applies against ac16.


--- linux-244-ac16-clean/drivers/ide/ide-cd.c   Fri May 25 21:11:08 2001
+++ linux-244-ac16/drivers/ide/ide-cd.c Fri May 25 21:30:20 2001
@@ -2869,12 +2869,12 @@
 int ide_cdrom_open (struct inode *ip, struct file *fp, ide_drive_t *drive)
 {
struct cdrom_info *info = drive-driver_data;
-   int rc;
+   int rc = -ENOMEM;
 
MOD_INC_USE_COUNT;
if (info-buffer == NULL)
info-buffer = (char *) kmalloc(SECTOR_BUFFER_SIZE, GFP_KERNEL);
-   if ((rc = cdrom_fops.open(ip, fp))) {
+if ((info-buffer == NULL) || (rc = cdrom_fops.open(ip, fp))) {
drive-usage--;
MOD_DEC_USE_COUNT;
}
-- 
Regards,
Rasmus([EMAIL PROTECTED])

The police are not here to create disorder.  They're here to preserve
disorder. -Former Chicago mayor Daley during the infamous 1968 Democratic
Party convention
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] highmem deadlock removal, balancing cleanup

2001-05-25 Thread Rik van Riel


Hi Linus,

the following patch does:

1) Remove GFP_BUFFER and HIGHMEM related deadlocks, by letting
   these allocations fail instead of looping forever in
   __alloc_pages() when they cannot make any progress there.

   Now Linux no longer hangs on highmem machines with heavy
   write loads.

2) Clean up the __alloc_pages() / __alloc_pages_limit() code
   a bit, moving the direct reclaim condition from the latter
   function into the former so we run it less often ;)

3) Remove the superfluous wakeups from __alloc_pages(), not
   only are the tests a real CPU eater, they also have the
   potential of waking up bdflush in a situation where it
   shouldn't run in the first place.  The kswapd wakeup didn't
   seem to have any effect either.

4) Do make sure GFP_BUFFER allocations NEVER eat into the
   very last pages of the system. It is important to preserve
   the following ordering:
- normal allocations
- GFP_BUFFER
- atomic allocations
- other recursive allocations

   Using this ordering, we can be pretty sure that eg. a
   GFP_BUFFER allocation to swap something out to an
   encrypted device won't eat the memory the device driver
   will need to perform its functions. It also means that
   a gigabit network flood won't eat those pages...

5) Change nr_free_buffer_pages() a bit to not return pages
   which cannot be used as buffer pages, this makes a BIG
   difference on highmem machines (which now DO have a working
   write throttling again).

6) Simplify the refill_inactive() loop enough that it actually
   works again. Calling page_launder() and shrink_i/d_memory()
   by the same if condition means that the different caches
   get balanced against each other again.

   The illogical argument for not shrinking the slab cache
   while we're under a free shortage turned out to be very
   much illogical too.  All needed buffer heads will have been
   allocated in page_launder() and shrink_i/d_memory() before
   we get here and we can be pretty sure that these functions
   will keep re-using those same buffer heads as soon as the
   IO finishes.

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

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

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

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

[with-PATCH-really] highmem deadlock removal, balancing cleanup

2001-05-25 Thread Rik van Riel

OK, shoot me.  Here it is again, this time _with_ patch...

-- Forwarded message --
Date: Fri, 25 May 2001 16:53:38 -0300 (BRST)
From: Rik van Riel [EMAIL PROTECTED]

Hi Linus,

the following patch does:

1) Remove GFP_BUFFER and HIGHMEM related deadlocks, by letting
   these allocations fail instead of looping forever in
   __alloc_pages() when they cannot make any progress there.

   Now Linux no longer hangs on highmem machines with heavy
   write loads.

2) Clean up the __alloc_pages() / __alloc_pages_limit() code
   a bit, moving the direct reclaim condition from the latter
   function into the former so we run it less often ;)

3) Remove the superfluous wakeups from __alloc_pages(), not
   only are the tests a real CPU eater, they also have the
   potential of waking up bdflush in a situation where it
   shouldn't run in the first place.  The kswapd wakeup didn't
   seem to have any effect either.

4) Do make sure GFP_BUFFER allocations NEVER eat into the
   very last pages of the system. It is important to preserve
   the following ordering:
- normal allocations
- GFP_BUFFER
- atomic allocations
- other recursive allocations

   Using this ordering, we can be pretty sure that eg. a
   GFP_BUFFER allocation to swap something out to an
   encrypted device won't eat the memory the device driver
   will need to perform its functions. It also means that
   a gigabit network flood won't eat those pages...

5) Change nr_free_buffer_pages() a bit to not return pages
   which cannot be used as buffer pages, this makes a BIG
   difference on highmem machines (which now DO have a working
   write throttling again).

6) Simplify the refill_inactive() loop enough that it actually
   works again. Calling page_launder() and shrink_i/d_memory()
   by the same if condition means that the different caches
   get balanced against each other again.

   The illogical argument for not shrinking the slab cache
   while we're under a free shortage turned out to be very
   much illogical too.  All needed buffer heads will have been
   allocated in page_launder() and shrink_i/d_memory() before
   we get here and we can be pretty sure that these functions
   will keep re-using those same buffer heads as soon as the
   IO finishes.

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

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

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

--- linux-2.4.5-pre6/mm/page_alloc.c.orig   Fri May 25 16:13:39 2001
+++ linux-2.4.5-pre6/mm/page_alloc.cFri May 25 16:35:50 2001
@@ -251,10 +251,10 @@
water_mark = z-pages_high;
}

-   if (z-free_pages + z-inactive_clean_pages  water_mark) {
+   if (z-free_pages + z-inactive_clean_pages = water_mark) {
struct page *page = NULL;
/* If possible, reclaim a page directly. */
-   if (direct_reclaim  z-free_pages  z-pages_min + 8)
+   if (direct_reclaim)
page = reclaim_page(z);
/* If that fails, fall back to rmqueue. */
if (!page)
@@ -299,21 +299,6 @@
if (order == 0  (gfp_mask  __GFP_WAIT))
direct_reclaim = 1;

-   /*
-* If we are about to get low on free pages and we also have
-* an inactive page shortage, wake up kswapd.
-*/
-   if (inactive_shortage()  inactive_target / 2  free_shortage())
-   wakeup_kswapd();
-   /*
-* If we are about to get low on free pages and cleaning
-* the inactive_dirty pages would fix the situation,
-* wake up bdflush.
-*/
-   else if (free_shortage()  nr_inactive_dirty_pages  free_shortage()
-nr_inactive_dirty_pages = freepages.high)
-   wakeup_bdflush(0);
-
 try_again:
/*
 * First, see if we have any zones with lots of free memory.
@@ -329,7 +314,7 @@
if (!z-size)
BUG();

-   if (z-free_pages = z-pages_low) {
+   if (z-free_pages = z-pages_min + 8) {
page = rmqueue(z, order);
if (page)
return page;
@@ -443,18 +428,26 @@
}
/*
 * When we arrive here, we are really tight on memory.
+* Since kswapd didn't succeed in freeing pages for us,
+* we try to help it.
+*
+* Single page allocs loop until the allocation succeeds.
+* Multi-page allocs can fail due to memory fragmentation;
+* in that case we bail out to prevent infinite loops and
+* hanging device drivers

blkdev-pagecache-2 [was Re: DVD blockdevice buffers]

2001-05-25 Thread Andrea Arcangeli

On Thu, May 24, 2001 at 12:32:20AM +0200, Andrea Arcangeli wrote:
userspace. I will try to work on the blkdev patch tomorrow to bring it
in an usable state.

It seems in an usable state right but it is still very early beta, I
need to recheck the whole thing, I will do that tomorrow, for now it
should get it right the fsck on a ro mount fs and the cache coherency
across multiple inodes all pointing to the same blkdev, it actually
worked without any problem in the first basic tests I did. However I
expect it to corrupt a rw mounted fs if you open the blkdev under it
(the fsck test happens with the fs ro), so while it's in an usable state
it's not ready for public consumation yet. Of course ramdisk is still
totally broken too. The other first round of bugs mentioned in the first
thread should be fixed. The blocksize is still hardwired to 4k, I'll
think about the read-modify-write problem later. About the proposed
readpage API change I think it's not worthwhile for new hardware where
reading 1k or 4k doesn't make relevant difference. Handling partial
I/O seems worthwhile only during writes because a partial write would
otherwise trigger a read-modify-write operation with a synchronous read.

ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.4.5pre6/blkdev-pagecache-2

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

[PATCH] kmalloc checks for drivers/ide/ide-probe.c (244ac16)


Hi.

The following patch adds a number of checks for kmalloc returns
to drivers/ide/ide-probe.c. It applies against ac16.

One comment: This patch adds 'drive-present = 0' to the
code path for the EXABYTE case. I could not discern if this was a
shortcoming of the original code or not. Please comment.


--- linux-244-ac16-clean/drivers/ide/ide-probe.cFri May 25 21:11:08 2001
+++ linux-244-ac16/drivers/ide/ide-probe.c  Fri May 25 21:51:08 2001
@@ -58,6 +58,11 @@
struct hd_driveid *id;
 
id = drive-id = kmalloc (SECTOR_WORDS*4, GFP_ATOMIC);  /* called with 
interrupts disabled! */
+if (!id) {
+printk(KERN_WARNING (ide-probe::do_identify) Out of memory.\n);
+goto err_kmalloc;
+}
+
ide_input_data(drive, id, SECTOR_WORDS);/* read 512 bytes of 
id info */
ide__sti(); /* local CPU only */
ide_fix_driveid(id);
@@ -76,8 +81,7 @@
if ((id-model[0] == 'P'  id-model[1] == 'M')
 || (id-model[0] == 'S'  id-model[1] == 'K')) {
printk(%s: EATA SCSI HBA %.10s\n, drive-name, id-model);
-   drive-present = 0;
-   return;
+goto err_misc;
}
 #endif /* CONFIG_SCSI_EATA_DMA || CONFIG_SCSI_EATA_PIO */
 
@@ -96,7 +100,7 @@
ide_fixstring (id-serial_no, sizeof(id-serial_no), bswap);
 
if (strstr(id-model, E X A B Y T E N E S T))
-   return;
+goto err_misc;
 
id-model[sizeof(id-model)-1] = '\0';  /* we depend on this a lot! */
printk(%s: %s, , drive-name, id-model);
@@ -111,8 +115,7 @@
 #ifdef CONFIG_BLK_DEV_PDC4030
if (HWIF(drive)-channel == 1  HWIF(drive)-chipset == ide_pdc4030) {
printk( -- not supported on 2nd Promise port\n);
-   drive-present = 0;
-   return;
+goto err_misc;
}
 #endif /* CONFIG_BLK_DEV_PDC4030 */
switch (type) {
@@ -174,6 +177,12 @@
printk(ATA DISK drive\n);
QUIRK_LIST(HWIF(drive),drive);
return;
+
+err_misc:
+kfree(id);
+err_kmalloc:
+drive-present = 0;
+return;
 }
 
 /*
@@ -759,11 +768,23 @@
}
minors= units * (1PARTN_BITS);
gd= kmalloc (sizeof(struct gendisk), GFP_KERNEL);
-   gd-sizes = kmalloc (minors * sizeof(int), GFP_KERNEL);
-   gd-part  = kmalloc (minors * sizeof(struct hd_struct), GFP_KERNEL);
-   bs= kmalloc (minors*sizeof(int), GFP_KERNEL);
-   max_sect  = kmalloc (minors*sizeof(int), GFP_KERNEL);
-   max_ra= kmalloc (minors*sizeof(int), GFP_KERNEL);
+if (!gd)
+goto err_kmalloc_gd;
+gd-sizes = kmalloc (minors * sizeof(int), GFP_KERNEL);
+if (!gd-sizes)
+goto err_kmalloc_gd_sizes;
+gd-part  = kmalloc (minors * sizeof(struct hd_struct), GFP_KERNEL);
+if (!gd-part)
+goto err_kmalloc_gd_part;
+bs= kmalloc (minors*sizeof(int), GFP_KERNEL);
+if (!bs)
+goto err_kmalloc_gs;
+max_sect  = kmalloc (minors*sizeof(int), GFP_KERNEL);
+if (!max_sect)
+goto err_kmalloc_max_sect;
+max_ra= kmalloc (minors*sizeof(int), GFP_KERNEL);
+if (!max_ra)
+goto err_kmalloc_max_ra;
 
memset(gd-part, 0, minors * sizeof(struct hd_struct));
 
@@ -816,6 +837,21 @@
devfs_mk_dir (ide_devfs_handle, name, NULL);
}
}
+return;
+
+err_kmalloc_max_ra:
+kfree(max_sect);
+err_kmalloc_max_sect:
+kfree(bs);
+err_kmalloc_gs:
+kfree(gd-part);
+err_kmalloc_gd_part:
+kfree(gd-sizes);
+err_kmalloc_gd_sizes:
+kfree(gd);
+err_kmalloc_gd:
+printk(KERN_WARNING (ide::init_gendisk) Out of memory\n);
+return;
 }
 
 static int hwif_init (ide_hwif_t *hwif)
-- 
regards,
Rasmus([EMAIL PROTECTED])

An Emacs reference mug is what I want. It would hold ten gallons of
coffee. -- Steve VanDevender 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: blkdev-pagecache-2 [was Re: DVD blockdevice buffers]

2001-05-25 Thread Andrea Arcangeli


On Fri, May 25, 2001 at 10:12:51PM +0200, Andrea Arcangeli wrote:
   
ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.4.5pre6/blkdev-pagecache-2
   ^ 4 sorry
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

ATI Rage 128

2001-05-25 Thread Android


Are there any plans for including support for the ATI Rage 128 chipset into 
svgalib?
The VESA setting does not work. Causes any program using svgalib to crash.
Are there any configuration settings in the kernel that may help with this?

The kernel I am using is 2.4.4 and the card I am using is the Rage Fury (32 
MB).
The svgalib version is 1.4.2
Framebuffer does have support for Rage 128, so I don't see why svgalib doesn't.

Thanks!

   -- Ted

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

[PATCH] __idetape_kmalloc_stage return code check in ide-tape.c (244-ac16)