Re: #define HZ 1024 -- negative effects?

[Mike Galbraith]

On Fri, 27 Apr 2001, Nigel Gamble wrote:

> On Fri, 27 Apr 2001, Mike Galbraith wrote:
> > On Fri, 27 Apr 2001, Nigel Gamble wrote:
> > > > What about SCHED_YIELD and allocating during vm stress times?
> >
> > snip
> >
> > > A well-written GUI should not be using SCHED_YIELD.  If it is
> >
> > I was refering to the gui (or other tasks) allocating memory during
> > vm stress periods, and running into the yield in __alloc_pages()..
> > not a voluntary yield.
>
> Oh, I see.  Well, if this were causing the problem, then running the GUI
> at a real-time priority would be a better solution than increasing the
> clock frequency, since SCHED_YIELD has no effect on real-time tasks
> unless there are other runnable real-time tasks at the same priority.
> The call to schedule() would just reschedule the real-time GUI task
> itself immediately.
>
> However, in times of vm stress it is more likely that GUI performance
> problems would be caused by parts of the GUI having been paged out,
> rather than by anything which could be helped by scheduling differences.

Agreed.  I wasn't thinking about swapping, only kswapd not quite keeping
up with laundering, and then user tasks having to pick up some of the
load.  Anyway, I've been told that for most values of HZ the slice is
50ms, so my reasoning wrt HZ/SCHED_YIELD was wrong.  (begs the question
why do some archs use higher HZ values?)

-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: [PATCH] SMP race in ext2 - metadata corruption.

[Albert D. Cahalan]

Linus Torvalds writes:

> The buffer cache is "virtual" in the sense that /dev/hda is a
> completely separate name-space from /dev/hda1, even if there
> is some physical overlap.

So the aliasing problems and elevator algorithm confusion remain?
Is this ever likely to change, and what is with the 1 kB assumptions?
(Hmmm, cruft left over from the 1 kB Minix filesystem blocks?)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Oops when using the Netfilter QUEUE target

[Rusty Russell]

In message <[EMAIL PROTECTED]> you write:
> On Wed, Apr 25, 2001 at 04:24:46PM +1000, James Morris wrote:
> > Please try the patch below.
> 
> So i did and it seems to work just fine (= no more oops') under 2.4.3/2.4.2-a

James,  I only glanced at the patch, but IIRC it just did
route_me_harder() on everything.  This is, unfortunately, no longer
"Best Practice": the prevailing trend is to reroute only when
something has actually been changed, to avoid overriding the socket
binding, etc.

See mangle for an example (store old values, see if they changed).  I
think this would be more complex, but still possible in your case, no?

Thanks,
Rusty.
--
Premature optmztion is rt of all evl. --DK
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] 2.4.4-pre8 mm/Makefile

[Keith Owens]

Fix for "__VERSIONED_SYMBOL(shmem_file_setup)".  Against 2.4.4-pre8.

Index: 4-pre8.2/mm/Makefile
--- 4-pre8.2/mm/Makefile Fri, 05 Jan 2001 13:42:29 +1100 kaos (linux-2.4/j/19_Makefile 
1.1 644)
+++ 4-pre8.2(w)/mm/Makefile Sat, 28 Apr 2001 14:10:59 +1000 kaos 
+(linux-2.4/j/19_Makefile 1.1 644)
@@ -9,6 +9,8 @@
 
 O_TARGET := mm.o
 
+export-objs := shmem.o
+
 obj-y   := memory.o mmap.o filemap.o mprotect.o mlock.o mremap.o \
vmalloc.o slab.o bootmem.o swap.o vmscan.o page_io.o \
page_alloc.o swap_state.o swapfile.o numa.o oom_kill.o \

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

Oopses under 2.4.4pre8 with Tbird 1.2GHz/Epox 8kta3

[Lawrence Gold]

Hi,

About a week ago, I bought an AMD Thunderbird 1.2GHz CPU with a 266MHz
frontside bus, along with an Epox 8KTA3 motherboard.

If I boot into 2.2.18pre2, which was the version on the old hard drive I'm
using for testing, everything runs just fine.  However, if I boot into a
2.4.x kernel, either 2.4.2 or 2.4.4pre8, I will usually receive an oops
within a few minutes of running and sometimes a kernel panic during the
boot process.

At the end of this message, you'll find the output of one of the oopses I
received; it occurred a few seconds into building gpm.

Here's a list of facts which may or may not be pertinent:

- The kernel does NOT have DMA support or the VIA IDE driver enabled.
  (I will send my .config file it it'd be helpful.)
- The kernel was compiled with egcs-1.1.2 for Athlon (-mcpu-i686
  -malign-functions=4)
- The BIOS is the latest version from 17 April 2001.
- The BIOS has default rather than optimal settings enabled.
- The 128Mb DIMM in the machine was tested with memtest86 on the same
  hardware and checked out with no problems.  The panics/oopses also occur
  if I run with a different 128Mb DIMM.  Both are rated for 133MHz
  operation.
- The CPU and system temperature as reported by the BIOS seem to be well
  within reason: ~107 Fahrenheit for the CPU and ~80 Fahrenheit for the
  system.

Since I couldn't get gpm running and I didn't see the output of the oops
in my system logs, I took a picture with my digicam and typed it out by
hand.  :-)  If there's anything that looks REALLY screwy, I will
double-check the picture in my camera.

P.S. I'm not subscribed to the mailing list, so I'd appreciate being CC'd.

Thanks!


ksymoops 2.4.1 on i686 2.4.4-pre8.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.4-pre8/ (default)
 -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not 
found in System.map.  Ignoring ksyms_base entry
Unable to handle kernel paging request at virtual address ca4ef810
c0127a83
*pde = 
Oops: 0002
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010012
eax:   ebx: 55d17f93  ecx: c4f1e000  edx: 0013
esi: c1227c14  edi: 0282  ebp: 015745fe  esp: c45dfc10
ds: 0018  es: 0018  ss: 0018
Process sh (pid: 578, stackpage=c45df000)
Stack: c4f1e2c0 c1240a40 4010d000 4000 c4690404 0004f1e0 c0121c10 c1227c14
   c4f1e2c0 c45de000 c45dfdac c45de000 c1240a40 c4f1e640 c0138455 c1240a40
   c45de000 c45dfdac c538cac0 c45dfe6c c01385b5 ffb0 c45dfdac c01cf832
Call Trace: [] [] [] [] []
[] []
  [] [c01058ff>] []
Code: 89 44 a9 18 89 69 14 8b 56 14 8b 41 10 ff 49 10 39 d0 74 09

>>EIP; c0127a83<=
Trace; c0121c10 
Trace; c0138455 
Trace; c01385b5 
Trace; c0146f94 
Trace; c0146a50 
Trace; c0138aa7 
Trace; c0138d3a 
Trace; c0138d51 
Code;  c0127a83 
 <_EIP>:
Code;  c0127a83<=
   0:   89 44 a9 18   mov%eax,0x18(%ecx,%ebp,4)   <=
Code;  c0127a87 
   4:   89 69 14  mov%ebp,0x14(%ecx)
Code;  c0127a8a 
   7:   8b 56 14  mov0x14(%esi),%edx
Code;  c0127a8d 
   a:   8b 41 10  mov0x10(%ecx),%eax
Code;  c0127a90 
   d:   ff 49 10  decl   0x10(%ecx)
Code;  c0127a93 
  10:   39 d0 cmp%edx,%eax
Code;  c0127a95 
  12:   74 09 je 1d <_EIP+0x1d> c0127aa0 



2 warnings issued.  Results may not be reliable.


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

Re: kernel panic with 2.4.x and reiserfs

[david]

To your complaint, I have to add my kudos.  I frequently run into 
crashes and I have only had reiserfs filesystem that I had to rebuild in 
well over a year of using it on half a dozen workstations.  I use 2.4 
exclusively and have often had "premature restarts".

David

Tony Hoyle wrote:

> jason wrote:
>
>> Hello,
>>
>> As the subject would imply, I've been having problems with 2.4.x. I have
>> my root partition (/dev/hda1) as reiserfs and also have another 
>> harddrive
>> with a reiserfs partition (/dev/hdc1). Several programs write (e.g. save
>> files to) /dev/hdc1, and I also store files there. Under 2.4.2, whenever
>> manually copying files from hda1 to hdc1, I would get a kernel panic, 
>> the
>
>
>
> Reiserfs doesn't cope well with crashes  Under 2.4 I wouldn't 
> recommend using it on any kind of critical server - it seems to 
> progressively corrupt itself (I'm looking at the second reformat and 
> reinstall in a week, and I'm not a happy bunny).
>
> As the warning on reiserfsck says, the rebuild-tree option is a last 
> resort.  It's as likely to make the problem worse then improve it (It 
> rounds all the file lengths up to a block size, padding with zeros, 
> which breaks lots of stuff).  Backup what you can first.
>
> I find that if you run reiserfsck -x /dev/hda1 a couple of dozen times 
> it slowly fixes stuff that it couldn't fix on the previous pass.One 
> thing that can't fix is the bug that seems to make random files on the 
> FS unreadable even for root.The only way I've found around that one is 
> a periodic format/reinstall.
>
> Tony
>



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

Atrocious icache/dcache in 2.4.2

[Ed Tomlinson]

Hi,

Here is a patch that prunes unused, clean inodes from the icache
faster.  I have previously checked out cleaning the unused dirty
icache entries from the the same place in kswapd but did not find
it to be much a win.

This code does the following.  It factors prune_icache to use,  
prune_unused_icache to actually prune the list.   This makes it
simple to add a shrink_unused_icache_memory routine which gets
plugged into the kswapd loop.  The result is the icache is kept 
smaller.

fast_prune.diff
-
--- 2.4.4-pre7/include/linux/dcache.h   Thu Apr 26 12:57:47 2001
+++ linux/include/linux/dcache.hFri Apr 27 18:17:20 2001
@@ -176,6 +176,7 @@
 
 /* icache memory management (defined in linux/fs/inode.c) */
 extern void shrink_icache_memory(int, int);
+extern void shrink_unused_icache_memory(int);
 extern void prune_icache(int);
 
 /* only used at mount-time */
--- 2.4.4-pre7/mm/vmscan.c  Fri Apr 27 11:36:04 2001
+++ linux/mm/vmscan.c   Fri Apr 27 18:33:07 2001
@@ -953,6 +953,11 @@
 */
refill_inactive_scan(DEF_PRIORITY, 0);
 
+   /* 
+* Free unused inodes.
+*/
+   shrink_unused_icache_memory(GFP_KSWAPD);
+
/* Once a second, recalculate some VM stats. */
if (time_after(jiffies, recalc + HZ)) {
recalc = jiffies;
--- 2.4.4-pre7/fs/inode.c   Thu Apr 26 12:49:33 2001
+++ linux/fs/inode.cFri Apr 27 18:54:25 2001
@@ -540,16 +540,16 @@
 !inode_has_buffers(inode))
 #define INODE(entry)   (list_entry(entry, struct inode, i_list))
 
-void prune_icache(int goal)
+/*
+ * Called with inode lock held, returns with it released.
+ */
+int prune_unused_icache(int goal)
 {
LIST_HEAD(list);
struct list_head *entry, *freeable = 
-   int count = 0, synced = 0;
+   int count = 0;
struct inode * inode;
 
-   spin_lock(_lock);
-
-free_unused:
entry = inode_unused.prev;
while (entry != _unused)
{
@@ -577,19 +577,27 @@
 
dispose_list(freeable);
 
+   return count;
+}
+
+/*
+ * A goal of zero frees everything
+ */
+void prune_icache(int goal)
+{
+   spin_lock(_lock);
+   goal -= prune_unused_icache(goal);
+
/* 
 * If we freed enough clean inodes, avoid writing 
-* dirty ones. Also giveup if we already tried to
-* sync dirty inodes.
+* dirty ones.
 */
-   if (!goal || synced)
+   if (!goal)
return;

-   synced = 1;
-
spin_lock(_lock);
try_to_sync_unused_inodes();
-   goto free_unused;
+   prune_unused_icache(goal);
 }
 
 void shrink_icache_memory(int priority, int gfp_mask)
@@ -611,6 +619,20 @@
 
prune_icache(count);
kmem_cache_shrink(inode_cachep);
+}
+
+void shrink_unused_icache_memory(int gfp_mask)
+{
+   /*
+* Nasty deadlock avoidance..
+*/
+   if (!(gfp_mask & __GFP_IO))
+   return;
+
+   if (spin_trylock(_lock)) {
+   prune_unused_icache(0);
+   kmem_cache_shrink(inode_cachep);
+   }
 }
 
 /*
-

Comments?

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

amd 760 supported?

[The_Beast]

Hi, is the amd 760 chipset supporte by the new 2.4 kernels, and dpt 
controllers from adaptec?
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: [PATCH] cleanup for fixing get_super() races

[Alexander Viro]

On Fri, 27 Apr 2001, Linus Torvalds wrote:

> 
> On Fri, 27 Apr 2001, Alexander Viro wrote:
> > 
> > PS: last time I've separated that part of patch was a couple months
> > ago. See if something similar to the variant below would be OK with
> > you (I'll rediff it):
> 
> This one looks fine.

Erm? It _does_ pull the fsync_dev() in there (conditionally, depending
on the "flag" argument of invalidate_dev()).

Oh, well... Check the variant I've sent to you couple of minutes ago and
tell which one you prefer, OK?

Al
PS: gotta love the email latency...


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] cleanup for fixing get_super() races

[Alexander Viro]

On Fri, 27 Apr 2001, Linus Torvalds wrote:

> 
> On Fri, 27 Apr 2001, Alexander Viro wrote:
> > 
> > Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
> > either sync_dev() or fsync_dev(). What do you think about pulling that
> > into the same function?
> 
> I'd actually prefer not. I don't think it makes sense from a conceptual
> standpoint, and I think drivers could validly say "syncing this device at
> this point is _wrong_".

OK... That would be something like

diff -urN S4-pre8/drivers/acorn/block/mfmhd.c 
S4-pre8-ream_inodes/drivers/acorn/block/mfmhd.c
--- S4-pre8/drivers/acorn/block/mfmhd.c Fri Feb 16 18:37:01 2001
+++ S4-pre8-ream_inodes/drivers/acorn/block/mfmhd.c Fri Apr 27 21:51:22 2001
@@ -1486,12 +1486,9 @@
for (i = maxp - 1; i >= 0; i--) {
int minor = start + i;
kdev_t devi = MKDEV(MAJOR_NR, minor);
-   struct super_block *sb = get_super(devi);
 
sync_dev (devi);
-   if (sb)
-   invalidate_inodes (sb);
-   invalidate_buffers (devi);
+   invalidate_device (devi);
 
mfm_gendisk.part[minor].start_sect = 0;
mfm_gendisk.part[minor].nr_sects = 0;
diff -urN S4-pre8/drivers/block/DAC960.c S4-pre8-ream_inodes/drivers/block/DAC960.c
--- S4-pre8/drivers/block/DAC960.c  Thu Feb 22 06:46:26 2001
+++ S4-pre8-ream_inodes/drivers/block/DAC960.c  Fri Apr 27 21:38:32 2001
@@ -5134,16 +5134,13 @@
  PartitionNumber);
  int MinorNumber = DAC960_MinorNumber(LogicalDriveNumber,
   PartitionNumber);
- SuperBlock_T *SuperBlock = get_super(Device);
  if (Controller->GenericDiskInfo.part[MinorNumber].nr_sects == 0)
continue;
  /*
Flush all changes and invalidate buffered state.
  */
  sync_dev(Device);
- if (SuperBlock != NULL)
-   invalidate_inodes(SuperBlock);
- invalidate_buffers(Device);
+ invalidate_device(Device);
  /*
Clear existing partition sizes.
  */
diff -urN S4-pre8/drivers/block/acsi.c S4-pre8-ream_inodes/drivers/block/acsi.c
--- S4-pre8/drivers/block/acsi.cFri Feb 16 22:53:03 2001
+++ S4-pre8-ream_inodes/drivers/block/acsi.cFri Apr 27 21:38:42 2001
@@ -1887,12 +1887,9 @@
for( i = max_p - 1; i >= 0 ; i-- ) {
if (gdev->part[start + i].nr_sects != 0) {
kdev_t devp = MKDEV(MAJOR_NR, start + i);
-   struct super_block *sb = get_super(devp);
 
fsync_dev(devp);
-   if (sb)
-   invalidate_inodes(sb);
-   invalidate_buffers(devp);
+   invalidate_device(devp);
gdev->part[start + i].nr_sects = 0;
}
gdev->part[start+i].start_sect = 0;
diff -urN S4-pre8/drivers/block/amiflop.c S4-pre8-ream_inodes/drivers/block/amiflop.c
--- S4-pre8/drivers/block/amiflop.c Fri Feb 16 18:59:20 2001
+++ S4-pre8-ream_inodes/drivers/block/amiflop.c Fri Apr 27 21:38:51 2001
@@ -1540,10 +1540,7 @@
break;
case FDFMTEND:
floppy_off(drive);
-   sb = get_super(inode->i_rdev);
-   if (sb)
-   invalidate_inodes(sb);
-   invalidate_buffers(inode->i_rdev);
+   invalidate_device(inode->i_rdev);
break;
case FDGETPRM:
memset((void *), 0, sizeof (getprm));
diff -urN S4-pre8/drivers/block/cciss.c S4-pre8-ream_inodes/drivers/block/cciss.c
--- S4-pre8/drivers/block/cciss.c   Fri Apr 27 06:20:56 2001
+++ S4-pre8-ream_inodes/drivers/block/cciss.c   Fri Apr 27 21:39:21 2001
@@ -694,10 +694,8 @@
 for(i=max_p; i>=0; i--) {
 int minor = start+i;
 kdev_t devi = MKDEV(MAJOR_NR + ctlr, minor);
-struct super_block *sb = get_super(devi);
 sync_dev(devi);
-if (sb) invalidate_inodes(sb);
-invalidate_buffers(devi);
+invalidate_device(devi);
 gdev->part[minor].start_sect = 0;
 gdev->part[minor].nr_sects = 0;
 
diff -urN S4-pre8/drivers/block/cpqarray.c S4-pre8-ream_inodes/drivers/block/cpqarray.c
--- S4-pre8/drivers/block/cpqarray.cFri Feb 16 22:56:28 2001
+++ S4-pre8-ream_inodes/drivers/block/cpqarray.cFri Apr 27 21:51:35 2001
@@ -1577,10 +1577,8 @@
for(i=max_p; i>=0; i--) {
int minor = start+i;
kdev_t devi = MKDEV(MAJOR_NR + ctlr, minor);
-   struct super_block *sb = get_super(devi);
sync_dev(devi);
-   if (sb) invalidate_inodes(sb);
-   invalidate_buffers(devi);
+   invalidate_device(devi);
 

Re: [PATCH] cleanup for fixing get_super() races

[Linus Torvalds]

On Fri, 27 Apr 2001, Alexander Viro wrote:
> 
> PS: last time I've separated that part of patch was a couple months
> ago. See if something similar to the variant below would be OK with
> you (I'll rediff it):

This one looks fine.

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: [PATCH] cleanup for fixing get_super() races

[Linus Torvalds]

On Fri, 27 Apr 2001, Alexander Viro wrote:
> 
> Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
> either sync_dev() or fsync_dev(). What do you think about pulling that
> into the same function?

I'd actually prefer not. I don't think it makes sense from a conceptual
standpoint, and I think drivers could validly say "syncing this device at
this point is _wrong_".

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: [PATCH] cleanup for fixing get_super() races

[Alexander Viro]

On Fri, 27 Apr 2001, Alexander Viro wrote:

> Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
> either sync_dev() or fsync_dev(). What do you think about pulling that
> into the same function? Actually, that's what I've done in namespace
> patch (name being invalidate_dev(), BTW ;-) The only problem I see
> here is the argument telling whether we want sync or fsync (or nothing).
> OTOH, I seriously suspect that we ought replace all sync_dev() cases
> with fsync_dev() anyway... Your opinion?
>   Al

PS: last time I've separated that part of patch was a couple months
ago. See if something similar to the variant below would be OK with
you (I'll rediff it):

diff -urN S2/drivers/acorn/block/mfmhd.c S2-s_lock-1/drivers/acorn/block/mfmhd.c
--- S2/drivers/acorn/block/mfmhd.c  Fri Oct 27 01:35:47 2000
+++ S2-s_lock-1/drivers/acorn/block/mfmhd.c Thu Feb 22 07:00:38 2001
@@ -1486,13 +1486,8 @@
for (i = maxp - 1; i >= 0; i--) {
int minor = start + i;
kdev_t devi = MKDEV(MAJOR_NR, minor);
-   struct super_block *sb = get_super(devi);
-
-   sync_dev (devi);
-   if (sb)
-   invalidate_inodes (sb);
-   invalidate_buffers (devi);
 
+   invalidate_dev(devi, 1);
mfm_gendisk.part[minor].start_sect = 0;
mfm_gendisk.part[minor].nr_sects = 0;
}
diff -urN S2/drivers/block/DAC960.c S2-s_lock-1/drivers/block/DAC960.c
--- S2/drivers/block/DAC960.c   Thu Feb 22 06:22:36 2001
+++ S2-s_lock-1/drivers/block/DAC960.c  Thu Feb 22 07:00:38 2001
@@ -5134,16 +5134,12 @@
  PartitionNumber);
  int MinorNumber = DAC960_MinorNumber(LogicalDriveNumber,
   PartitionNumber);
- SuperBlock_T *SuperBlock = get_super(Device);
  if (Controller->GenericDiskInfo.part[MinorNumber].nr_sects == 0)
continue;
  /*
Flush all changes and invalidate buffered state.
  */
- sync_dev(Device);
- if (SuperBlock != NULL)
-   invalidate_inodes(SuperBlock);
- invalidate_buffers(Device);
+ invalidate_dev(Device, 1);
  /*
Clear existing partition sizes.
  */
diff -urN S2/drivers/block/acsi.c S2-s_lock-1/drivers/block/acsi.c
--- S2/drivers/block/acsi.c Thu Feb 22 06:22:36 2001
+++ S2-s_lock-1/drivers/block/acsi.cThu Feb 22 07:00:39 2001
@@ -1887,12 +1887,7 @@
for( i = max_p - 1; i >= 0 ; i-- ) {
if (gdev->part[start + i].nr_sects != 0) {
kdev_t devp = MKDEV(MAJOR_NR, start + i);
-   struct super_block *sb = get_super(devp);
-
-   fsync_dev(devp);
-   if (sb)
-   invalidate_inodes(sb);
-   invalidate_buffers(devp);
+   invalidate_dev(devp, 2);
gdev->part[start + i].nr_sects = 0;
}
gdev->part[start+i].start_sect = 0;
diff -urN S2/drivers/block/amiflop.c S2-s_lock-1/drivers/block/amiflop.c
--- S2/drivers/block/amiflop.c  Sun Oct  1 22:35:15 2000
+++ S2-s_lock-1/drivers/block/amiflop.c Thu Feb 22 07:00:39 2001
@@ -1490,7 +1490,6 @@
 {
int drive = inode->i_rdev & 3;
static struct floppy_struct getprm;
-   struct super_block * sb;
 
switch(cmd){
case HDIO_GETGEO:
@@ -1540,10 +1539,7 @@
break;
case FDFMTEND:
floppy_off(drive);
-   sb = get_super(inode->i_rdev);
-   if (sb)
-   invalidate_inodes(sb);
-   invalidate_buffers(inode->i_rdev);
+   invalidate_dev(inode->i_rdev, 0);
break;
case FDGETPRM:
memset((void *), 0, sizeof (getprm));
@@ -1677,9 +1673,6 @@
 
 static int floppy_release(struct inode * inode, struct file * filp)
 {
-#ifdef DEBUG
-   struct super_block * sb;
-#endif
int drive = MINOR(inode->i_rdev) & 3;
 
if (unit[drive].dirty == 1) {
diff -urN S2/drivers/block/blkpg.c S2-s_lock-1/drivers/block/blkpg.c
--- S2/drivers/block/blkpg.cFri Oct 27 01:35:47 2000
+++ S2-s_lock-1/drivers/block/blkpg.c   Thu Feb 22 07:00:39 2001
@@ -157,8 +157,7 @@
 
/* partition in use? Incomplete check for now. */
devp = MKDEV(MAJOR(dev), minor);
-   if (get_super(devp) ||  /* mounted? */
-   is_swap_partition(devp))
+   if (is_mounted(devp) || is_swap_partition(devp))
return -EBUSY;
 
/* all seems OK */
diff -urN S2/drivers/block/cciss.c S2-s_lock-1/drivers/block/cciss.c
--- S2/drivers/block/cciss.cThu Feb 22 06:22:36 2001
+++ S2-s_lock-1/drivers/block/cciss.c   Thu Feb 22 07:00:39 2001
@@ -693,10 +693,7 @@
  

Re: [PATCH] cleanup for fixing get_super() races

[Alexander Viro]

On Fri, 27 Apr 2001, Linus Torvalds wrote:

> On Fri, 27 Apr 2001, Alexander Viro wrote:
> >
> > Each of these places is an oopsable race with umount. We can't fix them
> > without touching a lot of drivers. However, we can make the future fix
> > easier if we put the above into a helper function. Patch below does that.
> 
> I don't like the name "ream_inodes()".
> 
> Also, a driver shouldn't know about "inodes" and "buffers". It should just
> do something like
> 
>   invalidate_device(dev);
> 
> because the only thing the driver knows about is the _device_.
> 
> Then, invalidate_device() might do 
> 
>   sb = get_super(dev)
>   if (sb)
>   invalidate_inodes (sb);
>   invalidate_buffers(dev);
> 
> which makes some amount of sense. And which can later be extended to deal
> with the page cache etc without the drivers ever knowing or caring.

Fine with me. Actually in _all_ cases execept cdrom.c it's preceded by
either sync_dev() or fsync_dev(). What do you think about pulling that
into the same function? Actually, that's what I've done in namespace
patch (name being invalidate_dev(), BTW ;-) The only problem I see
here is the argument telling whether we want sync or fsync (or nothing).
OTOH, I seriously suspect that we ought replace all sync_dev() cases
with fsync_dev() anyway... Your opinion?
Al

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] cleanup for fixing get_super() races

[Linus Torvalds]

On Fri, 27 Apr 2001, Alexander Viro wrote:
>
> Each of these places is an oopsable race with umount. We can't fix them
> without touching a lot of drivers. However, we can make the future fix
> easier if we put the above into a helper function. Patch below does that.

I don't like the name "ream_inodes()".

Also, a driver shouldn't know about "inodes" and "buffers". It should just
do something like

invalidate_device(dev);

because the only thing the driver knows about is the _device_.

Then, invalidate_device() might do 

sb = get_super(dev)
if (sb)
invalidate_inodes (sb);
invalidate_buffers(dev);

which makes some amount of sense. And which can later be extended to deal
with the page cache etc without the drivers ever knowing or caring.

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: X15 alpha release: as fast as TUX but in user space

[Fabio Riccardi]

In both cases (X15 and TUX) the CPU utilization is 100%

There are no IO bottlenecks on disk or on the net side.

I think that the major bottleneck is the speed of RAM and the PCI bus, wait
cycles.

We are basically going at the speed of the hardware.

 - Fabio

"David S. Miller" wrote:

> Fabio Riccardi writes:
>  > On my Dell 4400 with 2G of RAM and 2 933MHz PIII and NetGear 2Gbit NICs
>  > I achieve about 2500 SpecWeb99 connections, with both X15 and
>  > TUX (actually X15 is sligtly faster, some 20 connections more... ;)
>
> What is the CPU utilization like in X15 vs. TUX during
> these runs?
>
> 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/

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

[David S. Miller]

Fabio Riccardi writes:
 > On my Dell 4400 with 2G of RAM and 2 933MHz PIII and NetGear 2Gbit NICs
 > I achieve about 2500 SpecWeb99 connections, with both X15 and
 > TUX (actually X15 is sligtly faster, some 20 connections more... ;)

What is the CPU utilization like in X15 vs. TUX during
these runs?

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/

[PATCH] cleanup for fixing get_super() races

[Alexander Viro]

A lot of drivers does the following:
sb = get_super(dev);
if (sb)
invalidate_inodes(sb);
Each of these places is an oopsable race with umount. We can't fix them
without touching a lot of drivers. However, we can make the future fix
easier if we put the above into a helper function. Patch below does that.
Results:
* simpler code in drivers
* drivers don't care about the superblocks and their handling
* when we will add refcounting for superblocks we will not need
  to touch every block driver out there.
Patch is absolutely straightforward - function added to inode.c, declared
in fs.h and exported; instances of the body replaced with calls.

Please, apply it.
Al

diff -urN S4-pre8/drivers/acorn/block/mfmhd.c 
S4-pre8-ream_inodes/drivers/acorn/block/mfmhd.c
--- S4-pre8/drivers/acorn/block/mfmhd.c Fri Feb 16 18:37:01 2001
+++ S4-pre8-ream_inodes/drivers/acorn/block/mfmhd.c Fri Apr 27 20:16:01 2001
@@ -1486,11 +1486,9 @@
for (i = maxp - 1; i >= 0; i--) {
int minor = start + i;
kdev_t devi = MKDEV(MAJOR_NR, minor);
-   struct super_block *sb = get_super(devi);
 
sync_dev (devi);
-   if (sb)
-   invalidate_inodes (sb);
+   ream_inodes(devi);
invalidate_buffers (devi);
 
mfm_gendisk.part[minor].start_sect = 0;
diff -urN S4-pre8/drivers/block/DAC960.c S4-pre8-ream_inodes/drivers/block/DAC960.c
--- S4-pre8/drivers/block/DAC960.c  Thu Feb 22 06:46:26 2001
+++ S4-pre8-ream_inodes/drivers/block/DAC960.c  Fri Apr 27 20:16:31 2001
@@ -5134,15 +5134,13 @@
  PartitionNumber);
  int MinorNumber = DAC960_MinorNumber(LogicalDriveNumber,
   PartitionNumber);
- SuperBlock_T *SuperBlock = get_super(Device);
  if (Controller->GenericDiskInfo.part[MinorNumber].nr_sects == 0)
continue;
  /*
Flush all changes and invalidate buffered state.
  */
  sync_dev(Device);
- if (SuperBlock != NULL)
-   invalidate_inodes(SuperBlock);
+ ream_inodes(Device);
  invalidate_buffers(Device);
  /*
Clear existing partition sizes.
diff -urN S4-pre8/drivers/block/acsi.c S4-pre8-ream_inodes/drivers/block/acsi.c
--- S4-pre8/drivers/block/acsi.cFri Feb 16 22:53:03 2001
+++ S4-pre8-ream_inodes/drivers/block/acsi.cFri Apr 27 20:16:48 2001
@@ -1887,11 +1887,9 @@
for( i = max_p - 1; i >= 0 ; i-- ) {
if (gdev->part[start + i].nr_sects != 0) {
kdev_t devp = MKDEV(MAJOR_NR, start + i);
-   struct super_block *sb = get_super(devp);
 
fsync_dev(devp);
-   if (sb)
-   invalidate_inodes(sb);
+   ream_inodes(devp);
invalidate_buffers(devp);
gdev->part[start + i].nr_sects = 0;
}
diff -urN S4-pre8/drivers/block/amiflop.c S4-pre8-ream_inodes/drivers/block/amiflop.c
--- S4-pre8/drivers/block/amiflop.c Fri Feb 16 18:59:20 2001
+++ S4-pre8-ream_inodes/drivers/block/amiflop.c Fri Apr 27 20:17:09 2001
@@ -1540,9 +1540,7 @@
break;
case FDFMTEND:
floppy_off(drive);
-   sb = get_super(inode->i_rdev);
-   if (sb)
-   invalidate_inodes(sb);
+   ream_inodes(inode->i_rdev);
invalidate_buffers(inode->i_rdev);
break;
case FDGETPRM:
diff -urN S4-pre8/drivers/block/cciss.c S4-pre8-ream_inodes/drivers/block/cciss.c
--- S4-pre8/drivers/block/cciss.c   Fri Apr 27 06:20:56 2001
+++ S4-pre8-ream_inodes/drivers/block/cciss.c   Fri Apr 27 20:17:30 2001
@@ -694,9 +694,8 @@
 for(i=max_p; i>=0; i--) {
 int minor = start+i;
 kdev_t devi = MKDEV(MAJOR_NR + ctlr, minor);
-struct super_block *sb = get_super(devi);
 sync_dev(devi);
-if (sb) invalidate_inodes(sb);
+ream_inodes(devi);
 invalidate_buffers(devi);
 gdev->part[minor].start_sect = 0;
 gdev->part[minor].nr_sects = 0;
diff -urN S4-pre8/drivers/block/cpqarray.c S4-pre8-ream_inodes/drivers/block/cpqarray.c
--- S4-pre8/drivers/block/cpqarray.cFri Feb 16 22:56:28 2001
+++ S4-pre8-ream_inodes/drivers/block/cpqarray.cFri Apr 27 20:17:42 2001
@@ -1577,9 +1577,8 @@
for(i=max_p; i>=0; i--) {
int minor = start+i;
kdev_t devi = MKDEV(MAJOR_NR + ctlr, minor);
-   struct super_block *sb = get_super(devi);
sync_dev(devi);
-   if (sb) 

Re: 2.2.19 and ide.2.2.19.04092001.patch error

[Douglas J. Hunley]

On Friday 27 April 2001 20:21, Mark Hahn babbled:
> > Kernel config is attached. So is a description of my computer. Anyone got
> > any ideas?
>
> your disk has bad errors.  why do you think software changes will help?

 I know the disk has errors. Hence I run fsck. This is a brand new drive. I 
thought the kernel messages were indicative of an issue w/ the IDE patch.
-- 
Douglas J. Hunley (Linux User #174778)
http://hunley.homeip.net/

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

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

[Aaron Lehmann]

On Fri, Apr 27, 2001 at 05:18:26PM -0700, Fabio Riccardi wrote:
> You can download X15 Alpha 1 from here:
> http://www.chromium.com/X15-Alpha-1.tgz

Where's the source?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Resetting a PCI device

[Tim Wright]

Not generally.
Systems that support hot-plug PCI also have the ability to reset individual
PCI slots (ISTR that it's a requirement). Sadly, this facility is not
generally available on "normal" systems.

Tim

On Fri, Apr 27, 2001 at 10:52:20AM +0100, [EMAIL PROTECTED] wrote:
> Is there any way of issuing a PCI reset (safely) without rebooting?  I am
> developing a peripheral device (using a pci card with an FPGA and a plx9080
> pci interface), and find that its local bus is prone to hanging up.  It
> would be nice if I could just reset the entire device via the PCI reset,
> without having to go through the hassle of a reboot.  Is this wishful
> thinking?
> 
> - Dave
> 
> -
>  Dave Fraser
>  Development Engineer
>  BAE Systems, Ferry Road,
>  Edinburgh, EH5 2XS
>  Tel: +44 131 3434729
>  Fax: +44 131 3434124
> -
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Question regarding kernel threads and userlevel

[Steffen Persvold]

Hi linux-kernel,

I have a question regarding kernel threads : Are kernel threads treated equally
in terms of scheduling as normal userlevel processes ??

In my test case I have a driver for a PCI card from which I want to control
access to it's memory (prefetchable PCI space). Userlevel processes can mmap
this PCI memory and write directly to it (via the nopage technique). This is
also possible from the kernel thread, but to avoid trashing and short bursts on
the PCI bus, I protect every access to the memory space with a spin lock (a
mmapped kernel memory page which the driver initializes). That means if you
have a SMP system and two userlevel processes wants to write to this memory,
one will have to wait for the other before doing the memcpy (yep I'm using what
you can call PIO). This works great for two userlevel processes.

Now the reason for my question is; if also I have a kernel thread wanting to
write to this memory space it will also have to wait for the same lock (though
not mmapped since we are already in kernel space and can access the lock page
directly). What happens, is that if a userlevel process holds this lock and the
kernel thread gets scheduled and tries to get the same lock it will deadlock
because the userlevel process never gets back control and releases the lock
(kinda like when you spinlock in interrupt level on a lock wich is locked
without spinlock_irq). Is this because the kernel thread has higher priority
than the user level process (it has a nice level of -20) ?

Best regards,
-- 
 Steffen PersvoldSystems Engineer
 Email  : mailto:[EMAIL PROTECTED]Scali AS (http://www.scali.com)
 Norway : Tel  : (+47) 2262 8950 Olaf Helsets vei 6
  Fax  : (+47) 2262 8951 N-0621 Oslo, Norway

 USA: Tel  : (+1) 713 706 0544   10500 Richmond Avenue, Suite 190
 Houston, Texas 77042, USA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Fabio Riccardi]

Dear All,

I'd like to announce the first release of X15 Alpha 1, a _user space_
web server that is as fast as TUX.

On my Dell 4400 with 2G of RAM and 2 933MHz PIII and NetGear 2Gbit NICs
I achieve about 2500 SpecWeb99 connections, with both X15 and
TUX (actually X15 is sligtly faster, some 20 connections more... ;)

Given the limitations of my experimental setup I'd like to ask if some
of you could help me testing my software on some higher end machines.
I'm interested to see what happens on 4-8 processors in terms of
scalability etc.

You can download X15 Alpha 1 from here:
http://www.chromium.com/X15-Alpha-1.tgz

The the README file in the tarball should contain sufficient information
to run the thing, I also included a support module for running the
SpecWeb benchmark.

TIA, ciao,

 - Fabio


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] hpt366.c, *bad_ata66_4 additions (2.2.19 + ide.2.2.19.04092001.patch)

[Tim Moore]

(2.2.19 + ide.2.2.19.04092001.patch)

--- drivers/block/hpt366.c  Fri Apr 20 14:23:54 2001
+++ drivers/block/hpt366.new.c  Fri Apr 27 16:30:13 2001
@@ -56,8 +56,11 @@
 
 const char *bad_ata66_4[] = {
"IBM-DTLA-307075",
+   "IBM-DTLA-307060",
"IBM-DTLA-307045",
"IBM-DTLA-307030",
+   "IBM-DTLA-307020",
+   "IBM-DTLA-307015",
"WDC AC310200R",
NULL
 };

Can we assume the rest of the Deskstar 75GXP family has the same problems?

hdg: IBM-DTLA-307020, 19623MB w/1916kB Cache, CHS=39870/16/63, UDMA(66)
hdh: IBM-DTLA-307020, 19623MB w/1916kB Cache, CHS=39870/16/63, UDMA(66)

http://www.storage.ibm.com/hardsoft/diskdrdl/desk/ds75gxp.htm

Deskstar 75GXP  Interface Capacity (GB)   RPM
  DTLA-307015   Ultra ATA/100   15.36  7200
  DTLA-307020   Ultra ATA/100   20.57  7200
  DTLA-307030   Ultra ATA/100   30.73  7200
  DTLA-307045   Ultra ATA/100   46.11  7200
  DTLA-307060   Ultra ATA/100   61.49  7200
  DTLA-307075   Ultra ATA/100   76.86  7200

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

2.2.19 and ide.2.2.19.04092001.patch error

[Douglas J. Hunley]

While trying to use this patch to access /dev/hde1 on my Promise controller, 
I get  the following errors:
dma_intr: status=0x51 { DriveReady SeekComplete Error }
dma_intr: error=0x40 { UncorrectableError }, LBAsect=21233782, sector=21233712

This fs has errors on it, and trying to run fsck on it I get:
Error reading block 2654557 (Attempt to read block from filesystem resuleted 
in short read) while doing inode scan. Ignore error?

I use the following in my /etc/lilo.conf:
ide[0-2]=autotune

This is 2.2.19 with the IDE patch, and the EXT3 patch (though this drive is 
still ext2).

Kernel config is attached. So is a description of my computer. Anyone got any 
ideas?
-- 
Douglas J. Hunley (Linux User #174778)
http://hunley.homeip.net/

Ambivalent? Well, yes and no.


#
# Automatically generated by make menuconfig: don't edit
#

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
CONFIG_M586=y
# CONFIG_M586TSC is not set
# CONFIG_M686 is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_1GB=y
# CONFIG_2GB is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
# CONFIG_KMOD is not set

#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_QUIRKS=y
CONFIG_PCI_OPTIMIZE=y
CONFIG_PCI_OLD_PROC=y
# CONFIG_MCA is not set
# CONFIG_VISWS is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_BINFMT_JAVA is not set
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
# CONFIG_PARPORT_OTHER is not set
# CONFIG_APM is not set
# CONFIG_TOSHIBA is not set

#
# Plug and Play support
#
CONFIG_PNP=y
CONFIG_PNP_PARPORT=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_IDE=y
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_IDEDISK_STROKE=y
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=y
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_PKT_TASK_IOCTL is not set
# CONFIG_IDE_TASK_IOCTL_DEBUG is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_IDEDMA_NEW_DRIVE_LISTINGS=y
CONFIG_IDEDMA_PCI_EXPERIMENTAL=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_PDC202XX=y
CONFIG_PDC202XX_BURST=y
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_OSB4 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_IVB=y
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_PARIDE_PARPORT=y
# CONFIG_PARIDE is not set
CONFIG_BLK_DEV_IDE_MODES=y
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_HD is not set

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=y
CONFIG_FIREWALL=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_TOS=y
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_ROUTE_LARGE_TABLES is not set
CONFIG_IP_ROUTE_NAT=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
CONFIG_IP_FIREWALL=y
CONFIG_IP_FIREWALL_NETLINK=y
CONFIG_NETLINK_DEV=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_TRANSPARENT_PROXY=y
CONFIG_IP_MASQUERADE=y
CONFIG_IP_MASQUERADE_ICMP=y
CONFIG_IP_MASQUERADE_MOD=y
CONFIG_IP_MASQUERADE_IPAUTOFW=y
CONFIG_IP_MASQUERADE_IPPORTFW=y
CONFIG_IP_MASQUERADE_MFW=y
CONFIG_IP_ROUTER=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
CONFIG_IP_ALIAS=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_RARP=y
CONFIG_SKB_LARGE=y
# CONFIG_IPV6 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_BRIDGE is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_LLC is 

Re: 2.4.4-pre7 build failure w/ IP NAT and ipchains

[David S. Miller]

Kai Germaschewski writes:
 > If you get this mail, it works okay :-) (Just using a simple
 > masquerading setup here)

Cool, I've sent this fix off to Rusty and Linus already.

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/

Re: 2.4.4-pre7 build failure w/ IP NAT and ipchains

[Kai Germaschewski]

On Fri, 27 Apr 2001, David S. Miller wrote:

> Kai, can you try this patch out?  I think it does the right
> thing.  What I'm mostly interested in is if your ipchains
> setup works for the resulting kernel, I've already checked
> that it links properly. :-)

If you get this mail, it works okay :-) (Just using a simple
masquerading setup here)

--Kai


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

Re: [patch] linux likes to kill bad inodes

[Andreas Dilger]

I previously wrote:
> I will post a patch separately which handles a couple of cases where
> *_delete_inode() does not call clear_inode() in all cases.

OK, here it is.  The ext2_delete_inode() change isn't exactly a bug fix,
but rather a "performance" change.  No need to hold BLK to check status
or call clear_inode() (we call clear_inode() outside BLK in VFS if
delete_inode() method does not exist).

Cheers, Andreas
===
diff -ru linux-2.4.4p1.orig/fs/ext2/inode.c linux/fs/ext2/inode.c
--- linux-2.4.4p1.orig/fs/ext2/inode.c  Tue Apr 10 16:44:49 2001
+++ linux/fs/ext2/inode.c   Fri Apr 27 13:51:15 2001
@@ -44,12 +47,12 @@
  */
 void ext2_delete_inode (struct inode * inode)
 {
-   lock_kernel();
-
if (is_bad_inode(inode) ||
inode->i_ino == EXT2_ACL_IDX_INO ||
inode->i_ino == EXT2_ACL_DATA_INO)
goto no_delete;
+
+   lock_kernel();
inode->u.ext2_i.i_dtime = CURRENT_TIME;
mark_inode_dirty(inode);
ext2_update_inode(inode, IS_SYNC(inode));
@@ -59,9 +62,7 @@
ext2_free_inode (inode);
 
unlock_kernel();
return;
 no_delete:
-   unlock_kernel();
clear_inode(inode); /* We must guarantee clearing of inode... */
 }
 
diff -ru linux-2.4.4p1.orig/fs/bfs/inode.c linux/fs/bfs/inode.c
--- linux-2.4.4p1.orig/fs/bfs/inode.c   Tue Apr 10 16:44:49 2001
+++ linux/fs/bfs/inode.cFri Apr 27 15:45:31 2001
@@ -145,7 +145,7 @@
if (is_bad_inode(inode) || inode->i_ino < BFS_ROOT_INO ||
inode->i_ino > inode->i_sb->su_lasti) {
printf("invalid ino=%08lx\n", inode->i_ino);
-   return;
+   goto bad_inode;
}

inode->i_size = 0;
@@ -155,8 +156,7 @@
bh = bread(dev, block, BFS_BSIZE);
if (!bh) {
printf("Unable to read inode %s:%08lx\n", bdevname(dev), ino);
-   unlock_kernel();
-   return;
+   goto bad_unlock;
}
off = (ino - BFS_ROOT_INO)%BFS_INODES_PER_BLOCK;
di = (struct bfs_inode *)bh->b_data + off;
@@ -178,7 +178,9 @@
s->su_lf_eblk = inode->iu_sblock - 1;
mark_buffer_dirty(s->su_sbh);
}
+bad_unlock:
unlock_kernel();
+bad_inode:
clear_inode(inode);
 }
 
diff -ru linux-2.4.4p1.orig/fs/ufs/ialloc.c linux/fs/ufs/ialloc.c
--- linux-2.4.4p1.orig/fs/ufs/ialloc.c  Thu Nov 16 14:18:26 2000
+++ linux/fs/ufs/ialloc.c   Fri Apr 27 15:53:26 2001
@@ -82,6 +82,7 @@
if (!((ino > 1) && (ino < (uspi->s_ncg * uspi->s_ipg  {
ufs_warning(sb, "ufs_free_inode", "reserved inode or nonexistent inode 
%u\n", ino);
unlock_super (sb);
+   clear_inode (inode);
return;
}

@@ -90,6 +91,7 @@
ucpi = ufs_load_cylinder (sb, cg);
if (!ucpi) {
unlock_super (sb);
+   clear_inode (inode);
return;
}
ucg = ubh_get_ucg(UCPI_UBH);
-- 
Andreas Dilger   TurboLabs filesystem development
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

Release 1.3.1: Fri Apr 27 19:02:31 EDT 2001
* kxref.py can now replace the unmaintained checkhelp.pl,  
  checkconfig.pl, and checkincludes.pl scripts.

I'm going to stick my neck out a mile and say that I think this is a
stable release.  Doing so, of course, is in reality a clever plan which
ensures that at least three embarrassing bugs will be discovered within
the next 24 hours...

Seriously, I am now out of stuff to do on the CML2 code itself.  The
code now seems to be up to acceptable speed even on slow machines, the
UI feature requests have petered out, and this release seems to be
feature-complete with respect to everything that can be done before
the 2.5 cutover.

There is one 1.3.0 bug report pending from jeff millar, but I have 
not been able to reproduce it with 1.3.1.  I will, of course, continue
to process CML2 bug reports and rulesfile fixes.
-- 
http://www.tuxedo.org/~esr/;>Eric S. Raymond

"The bearing of arms is the essential medium through which the
individual asserts both his social power and his participation in
politics as a responsible moral being..."
-- J.G.A. Pocock, describing the beliefs of the founders of the U.S.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Latest linux security module patch against 2.4.3

[Greg KH]

The latest version of the linux security module patch is available at:
http://lsm.immunix.org/patches/lsm-2001_04_27-2.4.3.patch.gz


Changes in this version include:
- typo and null pointer dereference fixes from Seth Arnold
- changed the extra version of the kernel to "lsm" from
  "immunix"
- update ptrace hook and fixes
- added dummy_binprm_compute_creds so no oops on booting.
- mount and umount changes by Stephen Smalley
- added inode parameter to inode_ops->alloc_security
- moved the set and reset label functions to the task group as
  per Serge Hallyn's comments.
- can now load capability module
- removed SubDomain specific values in sysctl.h

thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: #define HZ 1024 -- negative effects?

[Nigel Gamble]

On Fri, 27 Apr 2001, Mike Galbraith wrote:
> On Fri, 27 Apr 2001, Nigel Gamble wrote:
> > > What about SCHED_YIELD and allocating during vm stress times?
> 
> snip
> 
> > A well-written GUI should not be using SCHED_YIELD.  If it is
> 
> I was refering to the gui (or other tasks) allocating memory during
> vm stress periods, and running into the yield in __alloc_pages()..
> not a voluntary yield.

Oh, I see.  Well, if this were causing the problem, then running the GUI
at a real-time priority would be a better solution than increasing the
clock frequency, since SCHED_YIELD has no effect on real-time tasks
unless there are other runnable real-time tasks at the same priority.
The call to schedule() would just reschedule the real-time GUI task
itself immediately.

However, in times of vm stress it is more likely that GUI performance
problems would be caused by parts of the GUI having been paged out,
rather than by anything which could be helped by scheduling differences.

Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/

MontaVista Software [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/

IDE reset and DMA disabled after CD read error

[Tobias Ringstrom]

When reading a bad CD, Linux 2.4.4-pre5 decided to turn off DMA when
trying to read a bad sector.  It also decided to reset the drive.  Is that
the expected behaviour?  I'm certanly not an ATAPI expert, but it does
seem a bit drastic to me.  The drive is in UDMA33 mode on a VIA vt82c686a,
with no (U)DMA problems detected (so far).

Isn't it possible to recogise a read error and treat it more gently?

/Tobias, fumbling in the dark


Here is the dmesg output:

Apr 27 23:32:31 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:31 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:31 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:31 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:32 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:32 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:33 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:33 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:33 igor kernel: hda: DMA disabled
Apr 27 23:32:33 igor kernel: hda: ATAPI reset complete
Apr 27 23:32:33 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:33 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:34 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:34 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:35 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:35 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:35 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:35 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:35 igor kernel: hda: ATAPI reset complete
Apr 27 23:32:36 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:36 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:36 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:36 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:37 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:37 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:37 igor kernel: hda: ATAPI reset complete
Apr 27 23:32:37 igor kernel: end_request: I/O error, dev 03:00 (hda), sector 651222
Apr 27 23:32:38 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:38 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:38 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:38 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:39 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:39 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:40 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:40 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:40 igor kernel: hda: ATAPI reset complete
Apr 27 23:32:40 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:40 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:41 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:41 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:42 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:42 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:42 igor kernel: hda: ATAPI reset complete
Apr 27 23:32:42 igor kernel: end_request: I/O error, dev 03:00 (hda), sector 651222
Apr 27 23:32:42 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:42 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:43 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:43 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:44 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:44 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:44 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:44 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:44 igor kernel: hda: ATAPI reset complete
Apr 27 23:32:45 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:45 igor kernel: hda: cdrom_decode_status: error=0x34
Apr 27 23:32:46 igor kernel: hda: cdrom_decode_status: status=0x51 { DriveReady 
SeekComplete Error }
Apr 27 23:32:46 igor 

Re: 2.4.4-pre7 build failure w/ IP NAT and ipchains

[David S. Miller]

Kai, can you try this patch out?  I think it does the right
thing.  What I'm mostly interested in is if your ipchains
setup works for the resulting kernel, I've already checked
that it links properly. :-)

--- net/ipv4/netfilter/Makefile.~1~ Thu Apr 26 23:30:39 2001
+++ net/ipv4/netfilter/Makefile Fri Apr 27 15:49:54 2001
@@ -16,11 +16,11 @@
 
 # objects for the conntrack and NAT core (used by standalone and backw. compat)
 ip_nf_conntrack-objs   := ip_conntrack_core.o ip_conntrack_proto_generic.o 
ip_conntrack_proto_tcp.o ip_conntrack_proto_udp.o ip_conntrack_proto_icmp.o
-ip_nf_nat-objs := ip_nat_core.o ip_nat_proto_unknown.o ip_nat_proto_tcp.o 
ip_nat_proto_udp.o ip_nat_proto_icmp.o
+ip_nf_nat-objs := ip_nat_core.o ip_nat_helper.o ip_nat_proto_unknown.o 
+ip_nat_proto_tcp.o ip_nat_proto_udp.o ip_nat_proto_icmp.o
 
 # objects for the standalone - connection tracking / NAT
 ip_conntrack-objs  := ip_conntrack_standalone.o $(ip_nf_conntrack-objs)
-iptable_nat-objs   := ip_nat_standalone.o ip_nat_rule.o ip_nat_helper.o 
$(ip_nf_nat-objs)
+iptable_nat-objs   := ip_nat_standalone.o ip_nat_rule.o $(ip_nf_nat-objs)
 
 # objects for backwards compatibility mode
 ip_nf_compat-objs  := ip_fw_compat.o ip_fw_compat_redir.o ip_fw_compat_masq.o 
$(ip_nf_conntrack-objs) $(ip_nf_nat-objs)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4 and 2GB swap partition limit

[LA Walsh]

Rik van Riel wrote:

> On Fri, 27 Apr 2001, LA Walsh wrote:
>
> > An interesting option (though with less-than-stellar performance
> > characteristics) would be a dynamically expanding swapfile.  If you're
> > going to be hit with swap penalties, it may be useful to not have to
> > pre-reserve something you only hit once in a great while.
>
> This makes amazingly little sense since you'd still need to
> pre-reserve the disk space the swapfile grows into.

---
Why?  Why not have a zero length file that you grow only if you spill?
If you can't spill, you are out of memory -- or reserve a 'safety'
margin ahead -- like reserve 32k at a time and grow it.  It may make
little sense, but I believe it is what is used on pseudo OS's
like Windows -- you *can* preallocate, but the normal case has
Windows managing the swap file and growing it as needed up to
available disk space.  If it is doable in windows, you'd think there'd
be some way of doing it in Linux, but perhaps linux's complexity
doesn't allow for that type of feature.

As for disk-space reserves, if you have 5% reserved for
root' on a 20G ext disk, that still amounts to 1G reserved for root.
Seems an automatically sizing swap file might be just fine for some people
not me, I don't even like to use swap, but I'm not my mom using windows ME either).

But, conversely, if it's coming out of space I wouldn't normally
use anyway -- say the "5%" -- i.e. the 5% is something I'd likely only
use under *rare* conditions.  I might have enough memory and the
right system load that I also 'rarely' use swap -- so not reserving
1G/1G (2xMEM) on my laptop both of which will rarely get used seems like
a waste of 2G.  I suppose if I put it that way I might convince myself
to use it,

--
The above thoughts and   | They may have nothing to do with
writings are my own. | the opinions of my employer. :-)
L A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338



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

Re: 2.4 and 2GB swap partition limit

[Hugh Dickins]

On Fri, 27 Apr 2001, Rik van Riel wrote:
> On Fri, 27 Apr 2001, LA Walsh wrote:
> 
> > An interesting option (though with less-than-stellar performance
> > characteristics) would be a dynamically expanding swapfile.  If you're
> > going to be hit with swap penalties, it may be useful to not have to
> > pre-reserve something you only hit once in a great while.
> 
> This makes amazingly little sense since you'd still need to
> pre-reserve the disk space the swapfile grows into.

It makes roughly the same sense as over-committing memory.
Both are useful, both are unreliable.

Hugh

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

Re: 2.4 and 2GB swap partition limit

[Rik van Riel]

On Fri, 27 Apr 2001, Hugh Dickins wrote:
> On Fri, 27 Apr 2001, Rik van Riel wrote:
> > On Fri, 27 Apr 2001, LA Walsh wrote:
> >
> > > An interesting option (though with less-than-stellar performance
> > > characteristics) would be a dynamically expanding swapfile.  If you're
> > > going to be hit with swap penalties, it may be useful to not have to
> > > pre-reserve something you only hit once in a great while.
> >
> > This makes amazingly little sense since you'd still need to
> > pre-reserve the disk space the swapfile grows into.
>
> It makes roughly the same sense as over-committing memory.
> Both are useful, both are unreliable.

True, agreed.

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: Seagate ST340824A and (un)clipping max LBA: 2.2.19+ide04092001 patch

[Andries . Brouwer]

From: Alexander Stavitsky <[EMAIL PROTECTED]>

Disk capacity unclipping routines in ide.2.2.19.04092001.patch do not unclip
Seagate ST340824A.

I have to use the jumper on the drive to make system boot.
I tried "setmax" program and it is able to unclip the capacity,
kernel however does not.

I digged a little and I think the problem is that ST340824A does not follow
the ATA standard - it does support both READ NATIVE MAX ADDRESS
and SET MAX ADDRESS, but does not advertise support for
Host Protected Area feature set.

(maybe support is incomplete and therefore not announced?)

drive->id->command_set_1 =3D 0x306b for the this drive.

The unclipping routines compare
drive->id->command_set_1 and 0x0400 (Host Protected Feature set)

That is correct.

The earlier version of the patch compared
drive->id->command_set_1 and 0x000a (Security Mode & Power Managment ???)

When I changed it back to 0x000a, it unclipped the capacity just fine.
But 0x000a doesn't make any sense to me.

No. Maybe someone can tell us about its origin, but in your case
of course this just works because 0xa intersects 0x306b. You might
comment out this entire test.

What is the correct solution?

In the case of this particular disk the manufacturer says:
Use the Set Features command (EF) with subfunction F1.
That tells the disk to report full capacity.
(ATA-6 says that F1 is reserved for use by the Compact Flash Association)

[Could you try that and report identify output before and after?]

Also a related question: when I use "setmax", the drive reports full
capacity through "hdparm -I /dev/hd*", but kernel still uses the old info.
How does one update the kernel info after using "setmax"?

Details depend on kernel version and patches used.
There is not yet a good framework here.
(Many kernel versions will believe the partition table, even if it
extends beyond the end of the disk. That may be regarded as a bug,
but is useful in cases like this where the disk lies about its size.)


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

Re: 2.4 and 2GB swap partition limit

[Wakko Warner]

> I've always been trying to convice people that 2x RAM remains a good 
> rule-of-thumb.

IMO this is pointless

 total   used   free sharedbuffers cached
Mem:517456 505332  12124 111016  97752 236884
-/+ buffers/cache: 170696 346760
Swap:   131048  23216 107832

Of course for me, I'm not about to waste 1gb of disk space for swap.

The swap I have is 2 partitions, one on each drive both with a priority of
0.  Personally, I like the way it's done on my box.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] linux likes to kill bad inodes

[Linus Torvalds]

On Fri, 27 Apr 2001, Andreas Dilger wrote:
>
> However, since make_bad_inode() only changes the file methods and not
> the superblock

Please just make "make_bad_inode()" just do

inode->i_sb = bad_super_block;

and do everything else too.

It's not acceptable to make low-level filesystems care about these things.

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: [patch] linux likes to kill bad inodes

[Andreas Dilger]

Pavel writes:
> [I'd really like to get patch it; killing user's data without good
> reason seems evil to me, and this did quite a lot of damage to my
> $HOME.]
> 
>   Pavel
> PS: Only filesystem at use at time of problem was ext2, and it was
> ext2 iinode that got killed.

However, since make_bad_inode() only changes the file methods and not
the superblock, any of the put_inode(), delete_inode(), or write_inode()
methods can still be called.  While the write_inode() call is safe to
block in the VFS, I don't think it is safe to block *_put_inode() and
*_delete_inode() in the VFS because the filesystem may have allocated
memory or other things that need to be undone even for bad inodes.

The following patch fixes the VFS write_inode() (per Pavel's patch),
and ext2_put_inode(), bfs_delete_inode(), and udf_put_inode() to not
do anything with bad inodes.  I have bailed (with a FIXME) on
hpfs_delete_inode() and smb_delete_inode(), because I don't know what
(if anything) needs to be done to correctly clean up a bad inode.

I will post a patch separately which handles a couple of cases where
*_delete_inode() does not call clear_inode() in all cases.

Cheers, Andreas
===
diff -ru linux-2.4.4p1.orig/fs/inode.c linux/fs/inode.c
--- linux-2.4.4p1.orig/fs/inode.c   Tue Apr 10 16:44:49 2001
+++ linux/fs/inode.cFri Apr 27 13:05:04 2001
@@ -179,6 +181,12 @@
 
 static inline void write_inode(struct inode *inode, int sync)
 {
+   if (is_bad_inode(inode)) {
+   printk(KERN_CRIT "Cowardly refusing to write bad inode %s:%d\n",+  
+kdevname(inode->i_dev), inode->i_ino);
+   return;
+   }
+
if (inode->i_sb && inode->i_sb->s_op && inode->i_sb->s_op->write_inode)
inode->i_sb->s_op->write_inode(inode, sync);
 }
diff -ru linux-2.4.4p1.orig/fs/ext2/inode.c linux/fs/ext2/inode.c
--- linux-2.4.4p1.orig/fs/ext2/inode.c  Tue Apr 10 16:44:49 2001
+++ linux/fs/ext2/inode.c   Fri Apr 27 13:51:15 2001
@@ -36,6 +36,9 @@
  */
 void ext2_put_inode (struct inode * inode)
 {
+   if (is_bad_inode(inode))
+   return;
+
ext2_discard_prealloc (inode);
 }
 
diff -ru linux-2.4.4p1.orig/fs/bfs/inode.c linux/fs/bfs/inode.c
--- linux-2.4.4p1.orig/fs/bfs/inode.c   Tue Apr 10 16:44:49 2001
+++ linux/fs/bfs/inode.cFri Apr 27 15:45:31 2001
@@ -142,7 +142,8 @@
 
dprintf("ino=%08lx\n", inode->i_ino);
 
-   if (inode->i_ino < BFS_ROOT_INO || inode->i_ino > inode->i_sb->su_lasti) {
+   if (is_bad_inode(inode) || inode->i_ino < BFS_ROOT_INO ||
+   inode->i_ino > inode->i_sb->su_lasti) {
printf("invalid ino=%08lx\n", inode->i_ino);
return;
}
diff -ru linux-2.4.4p1.orig/fs/udf/inode.c linux/fs/udf/inode.c
--- linux-2.4.4p1.orig/fs/udf/inode.c   Tue Apr 10 16:41:51 2001
+++ linux/fs/udf/inode.cFri Apr 27 14:03:49 2001
@@ -74,7 +74,7 @@
  */
 void udf_put_inode(struct inode * inode)
 {
-   if (!(inode->i_sb->s_flags & MS_RDONLY))
+   if (!(inode->i_sb->s_flags & MS_RDONLY) && !is_bad_inode(inode))
{
lock_kernel();
udf_discard_prealloc(inode);
diff -ru linux-2.4.4p1.orig/fs/hpfs/inode.c linux/fs/hpfs/inode.c
--- linux-2.4.4p1.orig/fs/hpfs/inode.c  Tue Apr 10 16:41:50 2001
+++ linux/fs/hpfs/inode.c   Fri Apr 27 13:57:12 2001
@@ -316,6 +304,7 @@
 
 void hpfs_delete_inode(struct inode *inode)
 {
+   /* FIXME: handle is_bad_inode??? */
lock_kernel();
hpfs_remove_fnode(inode->i_sb, inode->i_ino);
unlock_kernel();
diff -ru linux-2.4.4p1.orig/fs/smbfs/inode.c linux/fs/smbfs/inode.c
--- linux-2.4.4p1.orig/fs/smbfs/inode.c Tue Apr 10 16:44:54 2001
+++ linux/fs/smbfs/inode.c  Fri Apr 27 14:01:33 2001
@@ -254,6 +254,7 @@
 smb_delete_inode(struct inode *ino)
 {
DEBUG1("ino=%ld\n", ino->i_ino);
+   /* FIXME: handle is_bad_inode() case??? */
lock_kernel();
if (smb_close(ino))
PARANOIA("could not close inode %ld\n", ino->i_ino);
-- 
Andreas Dilger   TurboLabs filesystem development
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4 and 2GB swap partition limit

[Thomas Dodd]

Rik van Riel wrote:
> 
> On Fri, 27 Apr 2001, LA Walsh wrote:
> 
> > An interesting option (though with less-than-stellar performance
> > characteristics) would be a dynamically expanding swapfile.  If you're
> > going to be hit with swap penalties, it may be useful to not have to
> > pre-reserve something you only hit once in a great while.
> 
> This makes amazingly little sense since you'd still need to
> pre-reserve the disk space the swapfile grows into.
> 
> A dynamically growing swap file can only save you if you
> reserve enough free space on your filesystem for the thing
> to grow...

I seams to work for M$, not that they are a good example.

But in /proc/sys/vm or /proc/sys/swapfile having
min_swap, max_swap, min_free_space and the filename to use. This could
then be set by init scripts like sysctl.

It never grows larger than max(swapfile.max_swap, free_space -
min_free_space).
so if you have free space on the filesystem it can be used,
but if you don't have space the current behavior remains.

Sure it would be slow, but that would only be a problem if you
run out of swap space and need to allocate more. Any
time this routine allocates a larger file than syapfile.min_swap
or frees space you send a WARN message.

Now the user will know why the performance dropped
and can either add RAM, or increase swap with by
partition, file, or increase swapfile.min_swap.

Those with enough RAM/swap will never even know it's there.

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

Re: 2.4 and 2GB swap partition limit

[Rik van Riel]

On Fri, 27 Apr 2001, LA Walsh wrote:

> An interesting option (though with less-than-stellar performance
> characteristics) would be a dynamically expanding swapfile.  If you're
> going to be hit with swap penalties, it may be useful to not have to
> pre-reserve something you only hit once in a great while.

This makes amazingly little sense since you'd still need to
pre-reserve the disk space the swapfile grows into.

A dynamically growing swap file can only save you if you
reserve enough free space on your filesystem for the thing
to grow...

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: looking for books

[David =?ISO-8859-1?Q?G=F3mez]

On Fri, 27 Apr 2001, Xiong Zhao wrote:

> hello.currently,i need to know the details about linux kernel,things
> like how fork and pthread are implemented,how clone actually work and
> so on.where can i get materials on these topics?
> thanx

Take a look on the new book from O'Reilly, "Understanding the Linux
kernel"

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



David Gómez

"The question of whether computers can think is just like the question of
 whether submarines can swim." -- Edsger W. Dijkstra


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

Re: 2.4.4-pre7 build failure w/ IP NAT and ipchains

[David S. Miller]

Kai Germaschewski writes:
 > Anyway, the appended patch fixed the problem for me, vmlinux links okay
 > now - didn't try if it works, though.

This may work, but it is evidently the wrong change.

The helpers list desired by net/ipv4/netfilter/ip_nat_*.c is
in net/ipv4/netfilter/ip_nat_helper.c and it is not static there.

My analysis on your config being illegal, as pointed out by others, is
wrong technically.  But, something else is awry since
net/ipv4/netfilter/ip_nat_core.o should not be built without
net/ipv4/netfilter/ip_nat_helper.o being built as well.

I'll hopefully solve this by the end of the day.

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/

Re: init process in 2.2.19

[Subba Rao]

On  0, Jesse Pollard <[EMAIL PROTECTED]> wrote:
> Subba Rao <[EMAIL PROTECTED]>:
> > I am trying to add a process which is to be managed by init. I have added the
> > following entry to /etc/inittab
> > 
> > SV:2345:respawn:env - PATH=/usr/local/bin:/usr/sbin:/usr/bin:/bin svscan /service 
> dev/console
> > 
> > After saving, I execute the following command:
> > 
> > # kill -HUP 1
> > 
> > This does not start the process I have added. The process that I have added
> > only starts when I do:
> > 
> > # init u
> > or
> > # telinit u
> > 
> > PS - The process will not start even after a reboot. I have to manually do one
> > of the above commands as root.
> > 
> > My kernel version is : 2.2.19
> > Distro : Slackware
> > GCC : gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
> > 
> > Any help appreciated.
> 
> I'm using Slackware 7.1, so one of the following possible solutions may work:
> 

Forgot to mention that I am using Slackware 7.1 too

> A second possibility (try this first - its easer:
>   I see that the daemon is to run in modes "2345". There is a possiblity
>   that you have this entry near the beginning of the inittab. If so, try
>   putting it at the end. I believe that init runs each line of the
>   inittab for a given run level in the same order that it appears in the
>   file. Putting the entry last should allow it to be started AFTER
>   all file systems are mounted - the  entry for multiuser mode is:
> 
>   # Script to run when going multi user.
>   rc:2345:wait:/etc/rc.d/rc.M
>
>   
> 

Thank you for replying!

I have tried those methods and they did not work. What I did as recommended
by someone, is that I added "strace" to the process in /etc/inittab

SV:2345:respawn:strace env - PATH=/usr/local/bin:/usr/sbin:/usr/bin:/bin svscan 
/service /backup/strace.out

Instead of sending the strace messages to the console, I saved them to a file.
Part of the log is at the end of this note. Most of these messages seem to be
from the memory module.

If anyone could look at these messages and let me know how to fix it, I would
appreciate it.

Thank you in advance for any help!
-- 

Subba Rao
[EMAIL PROTECTED]
http://members.home.net/subba9/

GPG public key ID 27FC9217




execve("/usr/bin/env", ["env", "-", "PATH=/usr/local/bin:/usr/sbin:/usr/bin:/bin", 
"svscan", "/service"], [/* 16 vars */]) = 0
brk(0)  = 0x804a3c0
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=22195, ...}) = 0
old_mmap(NULL, 22195, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0755, st_size=1013224, ...}) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\250\206"..., 4096) = 4096
old_mmap(NULL, 954492, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001a000
mprotect(0x400fc000, 28796, PROT_NONE)  = 0
old_mmap(0x400fc000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xe1000) = 
0x400fc000
old_mmap(0x4010, 12412, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 
-1, 0) = 0x4010
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40104000
mprotect(0x4001a000, 925696, PROT_READ|PROT_WRITE) = 0
mprotect(0x4001a000, 925696, PROT_READ|PROT_EXEC) = 0
munmap(0x40014000, 22195)   = 0
personality(PER_LINUX)  = 0
getpid()= 880
brk(0)  = 0x804a3c0
brk(0x804a3f8)  = 0x804a3f8
brk(0x804b000)  = 0x804b000
execve("/usr/local/bin/svscan", ["svscan", "/service"], [/* 1 var */]) = 0
brk(0)  = 0x8053d20
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=22195, ...}) = 0
old_mmap(NULL, 22195, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0755, st_size=1013224, ...}) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\250\206"..., 4096) = 4096
old_mmap(NULL, 954492, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001a000
mprotect(0x400fc000, 28796, PROT_NONE)  = 0
old_mmap(0x400fc000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xe1000) = 
0x400fc000
old_mmap(0x4010, 12412, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 
-1, 0) = 0x4010
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40104000
mprotect(0x4001a000, 925696, PROT_READ|PROT_WRITE) = 0

i2o_block struct gendisk misinitialization (2.4.3)

[Alvaro Lopes]

Hi

i2o_block is not properly initializing its gendisk structure
(i2o_gendisk) and someone forgot to link it to the gendisk linked list,
causing i2o hard drives and partitions not to show in /proc/partitions
(debian installer relies on this to find fdisk'able drives).

I attached a simple patch to fix it.

Álvaro Lopes

--- linux-2.4.3/drivers/i2o/i2o_block.c Sat Apr  7 16:42:21 2001
+++ linux/drivers/i2o/i2o_block.c   Fri Apr 27 19:58:41 2001
@@ -15,6 +15,8 @@
  * from loop.c. Isn't free software great for reusability 8)
  *
  * Fixes/additions:
+ *  Alvaro Lopes:
+ *  Fixed misc gendisk misinitialization
  * Steve Ralston:  
  * Multiple device handling error fixes,
  * Added a queue depth.
@@ -1675,6 +1677,10 @@
i2o_remove_handler(_block_handler);
return 0;
}
+
+   i2ob_gendisk.next = gendisk_head;
+   gendisk_head = _gendisk;
+   i2ob_gendisk.nr_real = MAX_I2OB;
 
/*
 *  Finally see what is actually plugged in to our controllers

Re: 2.4 and 2GB swap partition limit

[LA Walsh]

Rogier Wolff wrote:

> > > On Linux any swap adds to the memory pool, so 1xRAM would be
> > > equivalent to 2xRAM with the old old OS's.
> >
> > no more true AFAIK
>
> I've always been trying to convice people that 2x RAM remains a good
> rule-of-thumb.

---
Ug.  I like to view swap as "low grade memory" -- i.e. I really
should spend 99.9% of my time in RAM -- if I spill, then it means
I'm running too much/too big for my computer and should get more RAM --
meanwhile, I suffer with performance degradation to remind me I'm really
exceeding my machine's physical memory capacity.

An interesting option (though with less-than-stellar performance
characteristics) would be a dynamically expanding swapfile.  If you're
going to be hit with swap penalties, it may be useful to not have to
pre-reserve something you only hit once in a great while.

Definitely only for systems where you don't expect to use swap (but
it could be there for "emergencies" up to some predefined limit or
available disk space).

--
The above thoughts and   | They may have nothing to do with
writings are my own. | the opinions of my employer. :-)
L A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338



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

ReiserFS oops/panic/uninterruptable sleeps in -ac

[Ian Gulliver]

I have an SMP PenIII that had been running 2.4.1-ac18 for 65
days.  Its /home partition was a newly created (first used on
that kernel) ResierFS 3.6.x partition.  For no obvious reason,
two days ago, processes started going into uninterruptable
sleeps, reportedly in "down" in the kernel.  

We rebooted into 2.4.3-ac14, and suddenly we had oops and
eventually panics when accessing certain parts of /home.
(just an "ls" could spawn an oops, and an "ls -l" could
spawn a panic).  This is a production box, so unfortunately
writing down the oops/panic info was the lowest priority
on my list and it didn't happen.

We tried a reiserfsck with the newest reiserfsutils with
both --rebuild-sb and --rebuild-tree, and neither worked.

Finally, as a last resort before returning to ext2, we tried
2.4.3 stock kernel.  Magically, everything worked fine.
We have yet to see any instability, and we can't make any
processes stick, even under load.

This seems to be a bug somewhere in the ac patch, possibly
related to SMP.  If anyone could figure it out, it'd really
be nice to fix this before the bug makes it way into the
stock kernels.

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

Re: #define HZ 1024 -- negative effects?

[Mike Galbraith]

On Fri, 27 Apr 2001, Nigel Gamble wrote:

> > What about SCHED_YIELD and allocating during vm stress times?

snip

> A well-written GUI should not be using SCHED_YIELD.  If it is

I was refering to the gui (or other tasks) allocating memory during
vm stress periods, and running into the yield in __alloc_pages()..
not a voluntary yield.

-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: [PATCH] Single user linux

[Jim Gettys]

Not to mention fold up keyboard, IBM microdrive, etc.  So you
can run the ARM Debian distro either via NFS (with the problems that
entails), or even locally on a microdrive (or I suppose you could
also play with an IDE or SCSI controller if you were really insane).

On the kernel software side, we also have IPV6/mobile IP running.  We're
using Dave Woodhouse's JFFS2 with compression for our file system (Compressed
journalling flash file system) on flash.

In terms of apps, various PIM stuff, though needs lots of work,
other goodies like GPS applications, etc.  Mozilla in previous versions
has been known to work.  Tons of games, doom, etc.

MP3 players (at least 3).  Gnome core libraries.

Python, Java 2 standard edition, swing, all running etc. 

Lots of work/fun left to do, of course, in all areas.

Shall we just say we're having lots and lots and lots of fun :-).

These are real computers.

Lots of dust in the air: lots should have settled by June.  In particular,
look at the Familiar work.

See www.handhelds.org.  I apologize about the state of our web site:
I've done much of the maintenance in the past, but I've been out for some
surgery and life has been insane ever since.  Most of the interesting
stuff is in the Wiki.  And iPAQ's are not as unobtanium as they once were:
we're in really high volume production (>100K/month) but demand still
outstrips supply (sigh...).

Come join the party...

- Jim Gettys



> Sender: [EMAIL PROTECTED]
> From: Disconnect <[EMAIL PROTECTED]>
> Date: Wed, 25 Apr 2001 10:17:55 -0400
> To: Ronald Bultje <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PATCH] Single user linux
> -
> On Wed, 25 Apr 2001, Ronald Bultje did have cause to say:
> 
> > Who says it needs to compile? Who says it needs software installed? Who
> > says it needs to run the software itself?
> 
> My current project (and I'm just waiting for nfs and wvlan_cs to stabalize
> on ARM before putting the final touches on it) is an ipaq nfsrooted to a
> Debian image, over the wireless lan.  Works like a champ, and it -does-
> compile stuff reasonably fast (well, reasonably fast considering the data
> is all on the far side of 11M/sec wireless.)  My kit is mostly portable as
> well, since the nfs server is on the libretto and runs just fine in my
> backpack ;)
> 
> The next step is bludgeoning debian-arm into not running 50-100 little
> servers I don't need on my PIM.  But that may be the function of a
> task-nfs-ipaq package or some such.
> 
> So far -multiuser- linux on PIMs ("true" linux, with X, etc, as distinct
> from pocketlinux/qpe/etc, which are a different animal in this case) is
> almost there.  Web browsers are coming along nicely (and remote-X netscape
> is usable, although barely) and there are several nice imap clients. (and
> input methods ranging from a handwriting system to a little onscreen
> keyboard, if you are in a situation where an external keyboard is not
> feasable.)
> 
> ---

--
Jim Gettys
Technology and Corporate Development
Compaq Computer Corporation
[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/

2.4.4-pre8 undefined symbols

[Ed Tomlinson]

Hi 

The following patch adpated from the fix in the ac series, fixes the undefined
symbols in the various drm modules in pre7/8.

-
--- linux/lib/rwsem.c.orig  Fri Apr 27 13:24:48 2001
+++ linux/lib/rwsem.c   Fri Apr 27 13:25:08 2001
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct rwsem_waiter {
struct list_headlist;
@@ -202,9 +203,9 @@
return sem;
 }
 
-EXPORT_SYMBOL(rwsem_down_read_failed);
-EXPORT_SYMBOL(rwsem_down_write_failed);
-EXPORT_SYMBOL(rwsem_wake);
+EXPORT_SYMBOL_NOVERS(rwsem_down_read_failed);
+EXPORT_SYMBOL_NOVERS(rwsem_down_write_failed);
+EXPORT_SYMBOL_NOVERS(rwsem_wake);
 #if RWSEM_DEBUG
 EXPORT_SYMBOL(rwsemtrace);
 #endif
-

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

Re: Atrocious icache/dcache in 2.4.2

[Alexander Viro]

On Fri, 27 Apr 2001, Pete Zaitcev wrote:

> Hello:
> 
> My box here slows down dramatically after a while, and starts
> behaving as if it has very little memory, e.g. programs page
> each other out. It turns out that out of 40MB total, about
> 35MB is used for dcache and icache, and system basically
> runs in 5MB of RAM.
> 
> When I tried to discuss it with riel, viro, and others,
> I got an immediate and very strong knee jerk reaction "we fixed
> it in 2.4.4-pre4!" "we gotta call prune_dcache more!".
> That just does not sound persuasive to me.
 
[snip]
> written to disk if was changed), drop it into kmem_cache_free(),
> but retain on hash (forget about poisoning for a momemt).

What for?

I'm with you until now. But why bother keeping them resurrectable?
They are not refered by dentries. They have no IO happening on
them. Why retain them in cache for long?

Notice that icache is behind the dcache, so you are looking at the
second-order effects here. With the data you've shown on #kernel
it looks like half of your icache is just sitting there for no
ggod reason and slows down hash lookups.

It makes sense to retain them for a while, but inode sitting there
unreferenced by anything for minutes is a dead weight and nothing
else.

Notice that actually percent of the needlessly held inodes is higher -
2.4.2 _really_ keeps stale stuff in dcache and that means stale
stuff in icache. I.e. the only reference is from dentry that hadn't
been touched by anything for a _long_ time.

IOW, we just need to make sure that unreferenced inodes get freed
once they are not dirty / not locked. Fast. No need to keep them
on hash - just free them for real. Moreover, that will get
fragmentation down.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] rw_semaphores, exported symbol non-versioning

[D . W . Howells]

This patch (made against linux-2.4.4-pre8) turns off module export versioning 
on the rwsem symbols called from inline assembly.

David


diff -uNr linux-2.4.4-pre8/lib/rwsem.c linux-rwsem/lib/rwsem.c
--- linux-2.4.4-pre8/lib/rwsem.cFri Apr 27 20:10:11 2001
+++ linux-rwsem/lib/rwsem.c Fri Apr 27 20:27:03 2001
@@ -202,9 +202,9 @@
return sem;
 }
 
-EXPORT_SYMBOL(rwsem_down_read_failed);
-EXPORT_SYMBOL(rwsem_down_write_failed);
-EXPORT_SYMBOL(rwsem_wake);
+EXPORT_SYMBOL_NOVERS(rwsem_down_read_failed);
+EXPORT_SYMBOL_NOVERS(rwsem_down_write_failed);
+EXPORT_SYMBOL_NOVERS(rwsem_wake);
 #if RWSEM_DEBUG
 EXPORT_SYMBOL(rwsemtrace);
 #endif

sched.h problem with kernel 2.4.3

[Shaw Carruthers]

I have just tried to upgrade to kernel 2.4.3 and my home grown modules
won't compile e.g:

The offending line 27 is:

#include 

Could some kind kernel guru point to a source which explains the error of
my ways?


In file included from lm78.c:13:
/usr/src/linux/include/linux/kernel.h:71: parse error before `int'
/usr/src/linux/include/linux/mount.h: In function `mntput':
In file included from /usr/src/linux/include/linux/dcache.h:7,
 from /usr/src/linux/include/linux/fs.h:19,
 from /usr/src/linux/include/linux/capability.h:17,
 from /usr/src/linux/include/linux/binfmts.h:5,
 from /usr/src/linux/include/linux/sched.h:9,
 from lm78.c:27:
/usr/src/linux/include/linux/mount.h:46: warning: implicit declaration of function 
`printk_R1b7d4074'
/usr/src/linux/include/asm/semaphore.h: At top level:
In file included from /usr/src/linux/include/linux/fs.h:199,
 from /usr/src/linux/include/linux/capability.h:17,
 from /usr/src/linux/include/linux/binfmts.h:5,
 from /usr/src/linux/include/linux/sched.h:9,
 from lm78.c:27:
/usr/src/linux/include/asm/semaphore.h:99: parse error before `void'
/usr/src/linux/include/asm/semaphore.h:100: parse error before `int'
/usr/src/linux/include/asm/semaphore.h:101: parse error before `int'
/usr/src/linux/include/asm/semaphore.h:102: parse error before `void'
/usr/src/linux/include/asm/semaphore.h:104: parse error before `void'
/usr/src/linux/include/asm/semaphore.h:105: parse error before `int'
/usr/src/linux/include/asm/semaphore.h:106: parse error before `int'
/usr/src/linux/include/asm/semaphore.h:107: parse error before `void'
In file included from /usr/src/linux/include/linux/capability.h:17,
 from /usr/src/linux/include/linux/binfmts.h:5,
 from /usr/src/linux/include/linux/sched.h:9,
 from lm78.c:27:
/usr/src/linux/include/linux/fs.h:962: parse error before `long'
/usr/src/linux/include/linux/fs.h:963: parse error before `long'
In file included from /usr/src/linux/include/linux/sched.h:10,
 from lm78.c:27:
/usr/src/linux/include/linux/personality.h:66: parse error before `long'
In file included from /usr/src/linux/include/linux/sched.h:25,
 from lm78.c:27:
/usr/src/linux/include/linux/sem.h:124: parse error before `long'
/usr/src/linux/include/linux/sem.h:125: parse error before `long'
/usr/src/linux/include/linux/sem.h:126: parse error before `long'
In file included from lm78.c:27:
/usr/src/linux/include/linux/sched.h:152: parse error before `void'
/usr/src/linux/include/linux/sched.h:569: parse error before `long'
/usr/src/linux/include/linux/vmalloc.h: In function `vmalloc':
In file included from /usr/src/linux/include/asm/io.h:108,
 from lm78.c:31:
/usr/src/linux/include/linux/vmalloc.h:35: `boot_cpu_data_R0657d037' undeclared (first 
use this function)
/usr/src/linux/include/linux/vmalloc.h:35: (Each undeclared identifier is reported 
only once
/usr/src/linux/include/linux/vmalloc.h:35: for each function it appears in.)
/usr/src/linux/include/linux/vmalloc.h: In function `vmalloc_dma':
/usr/src/linux/include/linux/vmalloc.h:44: `boot_cpu_data_R0657d037' undeclared (first 
use this function)
/usr/src/linux/include/linux/vmalloc.h: In function `vmalloc_32':
/usr/src/linux/include/linux/vmalloc.h:53: `boot_cpu_data_R0657d037' undeclared (first 
use this function)
lm78.c: At top level:
lm78.c:49: warning: initialization from incompatible pointer type
lm78.c: In function `lm78_get_info':
lm78.c:68: warning: implicit declaration of function `sprintf_R3c2c5af5'
lm78.c: In function `init_module':
lm78.c:156: warning: implicit declaration of function `proc_register'
lm78.c: In function `cleanup_module':
lm78.c:195: warning: implicit declaration of function `proc_unregister'
make: *** [lm78.o] Error 1

-- 
Shaw Carruthers - [EMAIL PROTECTED]
London SW14 7JW UK
This is not a sig( with homage to Magritte).
  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: #define HZ 1024 -- negative effects?

[Nigel Gamble]

On Fri, 27 Apr 2001, Mike Galbraith wrote:
> > Rubbish.  Whenever a higher-priority thread than the current
> > thread becomes runnable the current thread will get preempted,
> > regardless of whether its timeslices is over or not.
> 
> What about SCHED_YIELD and allocating during vm stress times?
> 
> Say you have only two tasks.  One is the gui and is allocating,
> the other is a pure compute task.  The compute task doesn't do
> anything which will cause preemtion except use up it's slice.
> The gui may yield the cpu but the compute job never will.
> 
> (The gui won't _become_ runnable if that matters.  It's marked
> as running, has yielded it's remaining slice and went to sleep..
> with it's eyes open;)

A well-written GUI should not be using SCHED_YIELD.  If it is
"allocating", anything, it won't be using SCHED_YIELD or be marked
runnable, it will be blocked, waiting until the resource becomes
available.  When that happens, it will preempt the compute task (if its
priority is high enough, which is very likely - and can be assured if
it's running at a real-time priority as I suggested earlier).

Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/

MontaVista Software [EMAIL PROTECTED]

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

Re: [PATCH] SMP race in ext2 - metadata corruption.

[Shane Wegner]

On Fri, Apr 27, 2001 at 09:52:19AM -0700, Linus Torvalds wrote:
> 
> On Fri, 27 Apr 2001, Vojtech Pavlik wrote:
> > 
> > Actually this is done quite often, even on mounted fs's:
> > 
> > hdparm -t /dev/hda
> 
> Note that this one happens to be ok.
> 
> The buffer cache is "virtual" in the sense that /dev/hda is a completely
> separate name-space from /dev/hda1, even if there is some physical
> overlap.

Wouldn't something like "hdparm -t /dev/md0" trigger it
though.  It is the same device as gets mounted as md
devices aren't partitioned.

Shane


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

Re: [PATCH] allow PF_MEMALLOC tasks to directly reclaim pages

[Mark Hemment]

Marcelo,

  Infact, the test can be made even weaker than that.

  We only what to avoid the inactive-clean list when allocating from
within an interrupt (or from a bottom-half handler) to avoid 
deadlock on taking the pagecache_lock and pagemap_lru_lock.
  Note: no allocations are done while holding either of these locks.

  Even GFP_ATOMIC doesn't matter; that simply says if we should block or
not (could be an allocation while holding a spinlock, but not inside an
interrupt).

  I've been doing v heavy load on a 4-way server with;

if (order == 0 && !in_interrupt())
direct_reclaim = 1;

without any problems.

  Of course, the in_interrupt() is heavier than (gfp_mask & __GFP_WAIT),
but the benefits outweight the slight fattening.

Mark



On Fri, 27 Apr 2001, Marcelo Tosatti wrote:

> 
> Linus,
> 
> Currently __alloc_pages() does not allow PF_MEMALLOC tasks to free clean
> inactive pages.
> 
> This is senseless --- if the allocation has __GFP_WAIT set, its ok to grab
> the pagemap_lru_lock/pagecache_lock/etc.
> 
> I checked all possible codepaths after reclaim_page() and they are ok.
> 
> The following patch fixes that.
> 
> 
> --- linux/mm/page_alloc.c.origFri Apr 27 05:59:35 2001
> +++ linux/mm/page_alloc.c Fri Apr 27 05:59:48 2001
> @@ -295,8 +295,7 @@
>* Can we take pages directly from the inactive_clean
>* list?
>*/
> - if (order == 0 && (gfp_mask & __GFP_WAIT) &&
> - !(current->flags & PF_MEMALLOC))
> + if (order == 0 && (gfp_mask & __GFP_WAIT))
>   direct_reclaim = 1;
>  
>   /*
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Atrocious icache/dcache in 2.4.2

[Christoph Hellwig]

Hi Pete,

In article <[EMAIL PROTECTED]> you wrote:
> After a little thinking it seems apparent to me that it
> may be a good thing to have VM taking pages from dentry and
> inode pools directly. This sounds almost what slab does,
> so let me speculate about it (it is a bad idea, but it is
> interesting _why_).
>
> Suppose that we do this: when inode gets clean (e.g. unlocked,
> written to disk if was changed), drop it into kmem_cache_free(),
> but retain on hash (forget about poisoning for a momemt).
> Then, if memory is needed, VM may ask slab, slab calls our
> destructors, and destructors take inode off hash. The idea
> solves the problem, but has two marks agains it. First, when
> we look up an inode, we either hit dirty or "clean", which
> is free. Then we have to do kmem_cache_alloc() and that will
> return wrong inode, which we have to drop from hash, then do
> memcpy from old "really free one", etc. It still saves disk
> I/O, but messy. Another thing is a fragmentation: suppose we
> have bunch of slabs, every one has a single dirty inode in it
> (tar xf -). Memory pressure will be powerless to do anything
> about them.

It looks like you want the SLAB cache ->reclaim method we seem
to have forgotten when cloning the Solaris SLAB interface nearly
1:1...

Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: binfmt_misc on 2.4.3-ac14

[Thomas Dodd]

[EMAIL PROTECTED] wrote:
> 
> <[EMAIL PROTECTED]> wrote:
> >is it going to become the default in future kernel releases?
> It's been that way in the -ac kernels for a while now, but Linus hasn't put it
> into his kernels yet.  Perhaps he's waiting until work begins on 2.5, rather
> than break an existing interface in 2.4.  Anyway, it's entirely up to Linus, so
> I'm just guessing here. :-)

It's in the 2.4 kernels from RedHat (like the one shipped with SeaWolf)
So if you update you distro you'll see it for a while.

I thought the plan was to move this out of /proc and
to say /etc where config info like this "belongs".
Did this change?

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

Re: [OT] linux on pda was Re: [PATCH] Single user linux

[Erik Mouw]

On Fri, Apr 27, 2001 at 07:42:25AM -0500, Collectively Unconscious wrote:
> Also it seems to me last I checked PDA's were at least equvalent to the
> 386 which is ostensibly the bottom linux rung.

Check out the Compaq iPaq 3600 series.

> As for the objection about slow compile times, get real. No PDA is going
> to compile anything. All compilations happen on your desktop with a
> crosscompiler. PDA's are for running handy little apps, not development
> work.

Ehm, I know that people actually use their iPaq to compile things
natively. Plug in an IBM microdrive, add a foldable keyboard and you
get a complete Unix workstation in pocket format. For more information,
see http://www.handhelds.org/ .


Erik
[who also natively compiles kernels on a platform comparable to the
iPaq -- see http://www.lart.tudelft.nl/ ]

-- 
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/

Atrocious icache/dcache in 2.4.2

[Pete Zaitcev]

Hello:

My box here slows down dramatically after a while, and starts
behaving as if it has very little memory, e.g. programs page
each other out. It turns out that out of 40MB total, about
35MB is used for dcache and icache, and system basically
runs in 5MB of RAM.

When I tried to discuss it with riel, viro, and others,
I got an immediate and very strong knee jerk reaction "we fixed
it in 2.4.4-pre4!" "we gotta call prune_dcache more!".
That just does not sound persuasive to me.

After a little thinking it seems apparent to me that it
may be a good thing to have VM taking pages from dentry and
inode pools directly. This sounds almost what slab does,
so let me speculate about it (it is a bad idea, but it is
interesting _why_).

Suppose that we do this: when inode gets clean (e.g. unlocked,
written to disk if was changed), drop it into kmem_cache_free(),
but retain on hash (forget about poisoning for a momemt).
Then, if memory is needed, VM may ask slab, slab calls our
destructors, and destructors take inode off hash. The idea
solves the problem, but has two marks agains it. First, when
we look up an inode, we either hit dirty or "clean", which
is free. Then we have to do kmem_cache_alloc() and that will
return wrong inode, which we have to drop from hash, then do
memcpy from old "really free one", etc. It still saves disk
I/O, but messy. Another thing is a fragmentation: suppose we
have bunch of slabs, every one has a single dirty inode in it
(tar xf -). Memory pressure will be powerless to do anything
about them.

So, I have a better crackpot idea: create a fake filesystem,
say "inodefs". When inodes are needed, we pretend to read
pages from that filesystem, but in fact we just zero most
of them and put inodes there, also every one needs a "used"
counter, like slab has.  When an inode is dirty, we mark
those pages locked or dirty, if only clean - mark pages
as dirty. VM will automatically try to get pages, and
write out those that are "dirty". At that moment,
we have an option to look, if any used (clean or dirty) inodes
are inside the page. If they are, we either move them in
some other (fragmented) pages, or just remove them from
hashes and pretend that the page is written.

The bad part is that inode cache code and inodefs will have
part of slab machinery replicated in them. Dunno if that is
bad enough to bury the thing.

If you have read to this point, let me know what you think.

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

[Erik Mouw]

On Thu, Apr 26, 2001 at 09:41:13PM +0200, Pavel Machek wrote:
> > When I first started I compiled my linux kernels on a 386 dx with 8 mb ram
> > heh.  I think a lot of the current PDAs are faster.
> 
> My pocket computer is 40MHz mips r3902, likely faster than your
> 386dx. That's 3 years old. Anything you can buy today is at least
> twice as fast. [hell, I saw 8MB ram 2MB flash 80MHz mips machine in
> size of palm for $100 (vtech helio) -- I'll tell you where to buy it
> when you ask.]

The Compaq iPaq uses an Intel StrongARM SA1110 CPU running at 190MHz.
Integer performance for a 221MHz SA1110 is comparable with a Pentium
180 (on the average), so I guess that the iPaq performance is
compatable with a P166.


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: [linux-usb-devel] Repeatable lockup on SMP w/usbprocfs

[volodya]

On Thu, 29 Mar 2001, johan verrept wrote:

> Tony Hoyle wrote:
> > 
> > If an application calls the USBDEVFS_SUBMITURB ioctl to submit a read,
> > when the async completion routine is called, the kernel goes into a hard
> > deadlock (no response to ping, etc.).  I've narrowed it down to the
> > async_completed routine in usb.c.  That's the only place where spinlocks
> > are used.  I'm not familiar enough with them to see what the error is,
> > though.
> 
> It is async_completed in devio.c btw.
> I have looked at this too, but I am not sure whether this happens when the 
>completion is called or
> when the program does a USBDEVFS_REAPURB(NDELAY).
> I have looked at the code, but I do not see anything obviously wrong.
> 
> One thing I considered weird is the "wake_up(>wait);" in async_completed().
> This will wake up the program that has submitted the urb, whether is expects to be 
>woken or not. I
> am not sure what the consequences of this are, but it seems harmless enough.
> 
> > The system runs fine until the packet is returned, then it just locks 
> > solid (On the alcatel USB modem I used for testing it will not respond 
> > until it gets sync, which may be several seconds).
> 
> I have also noticed this only with the Alcatel SpeedTouch USB driver. I am not aware 
>of any other
> driver that uses this although I am writing one that will be using this. It is very 
>possible the
> program does something wrong (For example the code mixes the async and the sync 
>versions of the urb
> ioctl's...), but even then it is not supposed to be able to lock up the whole 
>machine.
> 
> > Others have found that just compiling SMP into the kernel is enough to
> > break it, you don't actually need two processors.
> 
> Probably because when you turn SMP off, spinlocks are disabled so deadlocks are 
>avoided.
> 

I have the similar problem (also with Alcatel modem).. Besides everything
else I, sometimes, get an oops in process 0 (swapper) - looks like some
memory corruption going on. I really hate it when the control app is
binary only. There are some obvious bugs in it (try running 'mgmt creset')
and alcatel supplied it as an object file (which might/is breaking glibc
compatibility) instead of a fully linked binary.

Vladimir Dergachev


>   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/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] swap-speedup-2.4.3-B3 (fwd)

[Rik van Riel]

On Fri, 27 Apr 2001, Mike Galbraith wrote:

> virgin pre7 +Rik
> real11m44.088s
> user7m57.720s
> sys 0m36.420s

> None of them make much difference.

Good, then I suppose we can put in the cleanup from my code, since
it makes the balancing a bit more predictable and should keep the
background aging within bounds.

I'll send a fixed patch tonight (with that last small thinko you
and marcelo discovered removed).

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: ramdisk/tmpfs/ramfs/memfs ?

[mirabilos]

> > btw I get my initial root filesystem from a compact flash that can
be
> > accessed just like a hardisk. It's writeable also like a harddisk,
but
> > we boot with it readonly, and only mount it rw if we want to save
> > config or whatever. We definitely wouldn't swap to it as it has
> > limited erase/write cycles. The filesystem is compressed ext2.
>
> Why copy it into RAM? Why not use cramfs and either turn the writable
> directories into symlinks into a ramfs which you create at boot time,
or
> union-mount a ramfs over the top of it?

Hey! SOunds great! How to do it?
I tried to # mount --bind the directories but they do not show
me both entries. I have romfs root and tmpfs.

-mirabilos


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

Re: [PATCH] SMP race in ext2 - metadata corruption.

[dek_ml]

On Fri, Apr 27, 2001 at 11:02:17AM -0700, LA Walsh wrote:
> Andrzej Krzysztofowicz wrote:
> 
> > I know a few people that often do:
> >
> > dd if=/dev/hda1 of=/dev/hdc1
> > e2fsck /dev/hdc1
> >
> > to make an "exact" copy of a currently working system.
> 
> ---
> Presumably this isn't a problem is the source disks are either unmounted or 
>mounted 'read-only' ?
> 
> 

I thought the known best solution on this was to use COW snapshots,
because then you copy the filesystem as exactly the state when the snapshot
was made, without impacting the writability of the filesystem while
the (potentially very long) dump is made?

I tried using this on LVM, but after seeing a few messages on the list about
kernel oopses happening with snapshots of filesystems with heavy write
activities, as well as experiencing serious problems with the LVM userspace
tools (they would core dump on startup if the LVM filesystem had any sort
of corruption or integrity failure) I decided to put it away until the LVM
folks managed to get a production version ready.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.4-pre7 build failure w/ IP NAT and ipchains

[Kai Germaschewski]

On Fri, 27 Apr 2001, David S. Miller wrote:

>> net/network.o: In function `ip_nat_setup_info':
>> net/network.o(.text+0x37b3e): undefined reference to `helpers'
>> net/network.o(.text+0x37b54): undefined reference to `helpers'
>
> Your configuration seems impossible, somehow the config system allowed
> you to set CONFIG_IP_NF_COMPAT_IPCHAINS without setting
> CONFIG_IP_NF_CONNTRACK.

Hmmh, actually the Config.in won't allow you to to set
CONFIG_IP_NF_COMPAT_IPCHAINS if CONFIG_IP_NF_CONNTRACK=y, but I don't
really understand that Config.in completely. (CONFIG_IP_NF_NAT_NEEDED is
set, but AFAICS never referenced anywhere).

Anyway, the appended patch fixed the problem for me, vmlinux links okay
now - didn't try if it works, though.

--Kai


Index: net/ipv4/netfilter/ip_conntrack_core.c
===
RCS file: /scratch/kai/cvsroot/linux_2_4/net/ipv4/netfilter/ip_conntrack_core.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 ip_conntrack_core.c
--- net/ipv4/netfilter/ip_conntrack_core.c  2001/04/24 00:20:29 1.1.1.3
+++ net/ipv4/netfilter/ip_conntrack_core.c  2001/04/26 20:49:36
@@ -46,7 +46,7 @@
 void (*ip_conntrack_destroyed)(struct ip_conntrack *conntrack) = NULL;
 LIST_HEAD(expect_list);
 LIST_HEAD(protocol_list);
-static LIST_HEAD(helpers);
+LIST_HEAD(helpers);
 unsigned int ip_conntrack_htable_size = 0;
 static int ip_conntrack_max = 0;
 static atomic_t ip_conntrack_count = ATOMIC_INIT(0);




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

preset performance options in make config

[Dan Mann]

I was wondering if having a make config option with 3 or 4 choices for
general performance settings would be an option for the kernel?

Like maybe the first question would read something like:

Configure Preset Performance Options? (Y/N) Y
Configure as Database Server (Y/N) N
Configure as Web Server (Y/N)  N
Configure as File & Print Server (Y/N) N
Configure as Desktop Workstation (Y/N) Y


If you choose no at the first level you would get the standard vanilla
kernell.  If you choose Database Server Y, you would have some compile time
options set for you that make sense for a Data base server, like maybe vm
and cache settings or something like that.  If you choose Desktop
Workstation, you would get some compile time options that would increase
graphics performance, interactivity/latency or whatever. And likewise, if
you choose File & Print, you might get things that would make a desktop user
cringe performance wise, but really accelerate the machine in a server
environment.

This might be really complicated or easy...I don't know.  But I was reading
some Linux performance tuning stuff that talked about tweaking stuff in
/proc, and I figured that stuff starts out at a predefined base in the
source code.  There are tools out there that can work with /proc and help
tune, but they can't change things that are only available BEFORE the binary
is built. Maybe also things like different versions of scheduler or you know
like a schedule_database.c or a schedule_workstation.c, or a vm or disk
version of the same thing?

I know I might be way off base here...someone tell me if I am :-)but
from my angle (non-programming guru) it might make a difference in the way
that linux performs for the average user/administrator.

What do you think?  Maybe help for someone who is looking to get the most
perf out of his/her system but maybe doesn't understand src code directly?

Dan

PS - Does anyone have any ideas about NT's kernel config before compile?
when you buy server is the kernel identical to workstation, with only
userland tweaks for performance?  Or are there deep source code level
changes between the two?  I'm sure since the code isn't out there no one
knows for sure, but does anyone even have an opinion on this matter?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] SMP race in ext2 - metadata corruption.

[LA Walsh]

Andrzej Krzysztofowicz wrote:

> I know a few people that often do:
>
> dd if=/dev/hda1 of=/dev/hdc1
> e2fsck /dev/hdc1
>
> to make an "exact" copy of a currently working system.

---
Presumably this isn't a problem is the source disks are either unmounted or 
mounted 'read-only' ?


--
The above thoughts and   | They may have nothing to do with
writings are my own. | the opinions of my employer. :-)
L A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338



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

[Jeff Garzik]

Evan Montgomery-Recht wrote:
> 
> About 2 years ago, I bought a IBM 600E laptop with one
> of the IBM branded Xircom CardBUS cards.  It took me
> about a month (with the help of a lot of people with
> simular machines) to figure out why the card would be
> recognized, and even connect to the network, but could
> never get a IP address from DHCP.  It turned out that
> the sound card which is a one of the CS based chips.
> The fix that I found was that if I added the following
> line to the /etc/pcmcia/config.opts The card would be
> detected, and recognized, and get a IP address.
> 
> exclude ports 0x2f8-0x2ff

What kernel are you running?  You may need to go to
http://pcmcia-cs.sourceforge.net/ for support, not there.

For kernel 2.4, make sure you have the following options set, exactly as
I present them, in your kernel .config file.

CONFIG_PCMCIA=y
CONFIG_CARDBUS=y
# CONFIG_I82365 is not set

-- 
Jeff Garzik  | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.4.4-pre7 build failure w/ IP NAT and ipchains

[Andrzej Krzysztofowicz]

"Matthias Andree wrote:"
> On Fri, 27 Apr 2001, David S. Miller wrote:
> > Your configuration seems impossible, somehow the config system allowed
> > you to set CONFIG_IP_NF_COMPAT_IPCHAINS without setting
> > CONFIG_IP_NF_CONNTRACK.

Just quick look at net/ipv4/netfilter/Config.in explains everything:

: if [ "$CONFIG_IP_NF_CONNTRACK" != "y" ]; then
:   if [ "$CONFIG_IP_NF_IPTABLES" != "y" ]; then
: tristate 'ipchains (2.2-style) support' CONFIG_IP_NF_COMPAT_IPCHAINS

CONFIG_IP_NF_COMPAT_IPCHAINS depends on CONFIG_IP_NF_CONNTRACK being
disabled. And it seems to be intentional...

> Now, if I set "connection tracking" to "y", the ipchains option
> disappears (make menuconfig). Are things supposed to behave this way?
> I'd like to stick to ipchains for a while, rather than switch to
> iptables. (Administrator laziness, of course.)

-- 
===
  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/

Re: [patch] swap-speedup-2.4.3-B3 (fwd)

[Mike Galbraith]

On Thu, 26 Apr 2001, Linus Torvalds wrote:

> Have you looked at "free_pte()"? I don't like that function, and it might
> make a difference. There are several small nits with it:

snip

> I _think_ the logic should be something along the lines of: "freeing the
> page amounts to a implied down-aging of the page, but the 'accessed' bit
> would have aged it up, so the two take each other out". But if so, the
> free_pte() logic should have something like
>
>   if (page->mapping) {
>   if (!pte_young(pte) || PageSwapCache(page))
>   age_page_down_ageonly(page);
>   if (!page->age)
>   deactivate_page(page);
>   }

Hi,

I tried this out today after some more reading.

virgin pre7 +Rik
real11m44.088s
user7m57.720s
sys 0m36.420s

+Rik +Linus
real11m48.597s
user7m55.620s
sys 0m37.860s

+Rik +Linus +HarshAging
real11m17.758s
user7m57.650s
sys 0m36.350s

None of them make much difference.

-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/

ide.2.2.19.04092001.patch + VIA82CXXX (Abit VP6)

[William Park]

I have Abit VP6 (VIA 82c694x, 82c686b) running 2.2.19 and
ide.2.2.19.04092001.patch.  When I enable
VIA82CXXX chipset support (EXPERIMENTAL) -- CONFIG_BLK_DEV_VIA82CXXX 
my machine hangs,
Uniform Multi-Platform E-IDE driver Revision: 6.30
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xa000-0xa007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xa008-0xa00f, BIOS settings: hdc:DMA, hdd:pio
HPT370: IDE controller on PCI bus 00 dev 70
HPT370: chipset revision 3
HPT370: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0xc000-0xc007, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xc008-0xc00f, BIOS settings: hdg:pio, hdh:pio
hda: ST315320A, ATA DISK drive
hdc: CD-ROM 24X/AKOx, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15 <-- hangs here

Interestingly, I didn't have this problem with ide-2.2.18 patch.

--William Park, Open Geometry Consulting, Mississauga, Ontario, Canada.
  8 CPUs, Linux, python, LaTeX, vim, mutt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] SMP race in ext2 - metadata corruption.

[Jeff Garzik]

Linus Torvalds wrote:
> On Fri, 27 Apr 2001, Neil Conway wrote:
> >
> > I'm surprised that dump is deprecated (by you at least ;-)).  What to
> > use instead for backups on machines that can't umount disks regularly?
> 
> Note that dump simply won't work reliably at all even in 2.4.x: the buffer
> cache and the page cache (where all the actual data is) are not
> coherent. This is only going to get even worse in 2.5.x, when the
> directories are moved into the page cache as well.

> Dump was a stupid program in the first place. Leave it behind.

Dump/restore are useful, on-line dump is silly.  I am personally amazed
that on-line, mounted dump was -ever- supported.  I guess it would work
if mounted ro...

dump is still the canonical solution, IMHO, for saving and restoring
filesystem metadata OFFLINE.  tar/cpio can be taught to do stuff like
security ACLs and EAs and such, but such code and formats are not yet
standardized, and they do not approach dump when it comes to taking an
accurate snapshot of the filesystem.

-- 
Jeff Garzik  | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Negative values of cat /proc/sys/fs/inode-nr

[Ingo Oeser]

Hi Alan,
Hi linux-kernel,

I just saw, that cat /proc/sys/fs/inode-nr gives negative values
for the second part.

559 -211555

or 

174805  -3

I'm using 2.4.3-ac13.

I see this both on SMP and non-SMP, HIGHMEM and non-HIGHMEM, if
that matters.

The first value for the second example (SMP+HIGHMEM machine) also
seems a bit large...

exact .config or more data available, if needed.

Otherwise this kernel is very stable for me, and it feels really
good in interactive performance. 

Regards

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

Re: HPT366 IDE DMA error question.

[Tim Hockin]

Mike Panetta wrote:

> hdi: timeout waiting for DMA
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> hdi: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
> hdi: DMA disabled
> ide4: reset: success
> 
> I get this message on all my off board HPT366 based controller
> cards.  I am using these cards with seagate Barracuda ATA III
> Model ST320414A 20GB drives.  Are there any known issues with
> these drives and the HPT366 based controllers?  Are there any

we have a system with hpt 370's (366 driver) that we found the following
obvious bug in.  If you read the spec carefuly, it is obviously correct. 
You have to set DMA up for read vs. write.  Does this make your problems go
away?  DIff against 2.4.3


-- 
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]

diff -u dist-2.4.3/drivers/ide/hpt366.c linux-2.4/drivers/ide/hpt366.c
--- dist-2.4.3/drivers/ide/hpt366.c Sat Jan 27 08:45:58 2001
+++ linux-2.4/drivers/ide/hpt366.c  Thu Apr 26 20:15:17 2001
@@ -523,9 +638,11 @@
 
 void hpt370_rw_proc (ide_drive_t *drive, ide_dma_action_t func)
 {
-   if ((func != ide_dma_write) || (func != ide_dma_read))
+   if ((func != ide_dma_write && func != ide_dma_read)
+|| drive->rwproc_cache == (void *)func)
return;
hpt370_tune_chipset(drive, drive->current_speed, (func == ide_dma_write));
+   drive->rwproc_cache = (void *)func;
 }
 
 static int config_drive_xfer_rate (ide_drive_t *drive)
diff -u dist-2.4.3/include/linux/ide.h linux-2.4/include/linux/ide.h
--- dist-2.4.3/include/linux/ide.h  Mon Jan 29 23:25:32 2001
+++ linux-2.4/include/linux/ide.h   Thu Apr 26 20:16:00 2001
@@ -284,6 +284,7 @@
unsigned long service_time; /* service time of last request */
unsigned long timeout;  /* max time to wait for irq */
special_t   special;/* special action flags */
+   void *rwproc_cache; /* last rwproc update */
byte keep_settings; /* restore settings after drive reset */
byte using_dma; /* disk is using dma for read/write */
byte waiting_for_dma;   /* dma currently in progress */
 
 

Re: ramdisk/tmpfs/ramfs/memfs ?

[David L. Parsley]

David Woodhouse wrote:

> Why copy it into RAM? Why not use cramfs and either turn the writable
> directories into symlinks into a ramfs which you create at boot time, or
> union-mount a ramfs over the top of it?
  ^^^

I didn't think we had union-mounting support... does it exist and
I've somehow missed it?

regards,
David

-- 
David L. Parsley
Network Administrator
Roanoke College
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: ramdisk/tmpfs/ramfs/memfs ?

[Xavier Bestel]

Le 27 Apr 2001 18:53:07 +0100, Padraig Brady a écrit :

> How much more efficent is JFFS than say ext3+e3compr, wrt:
> logic size/logic speed/RAM requirements/filesystem structure size.

JFFS doesn't have to use the FTL layer between its block device and the
flash - that's a lot already !

Xav

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

[Federico Edelman Anaya]

# ./dklimits 1
Can open 1020 AF_LOCAL sockets with socketpair
Can open 0 AF_INET sockets with socketpair
Can open 1021 fds
Can open 1021 files
Can poll 1025 sockets
Can bind 1021 ephemeral ports

Dan Kegel wrote:

> Federico Edelman Anaya wrote:
> >
> > Yeah .. I put in /etc/sysctl.conf
> >
> > fs.file-max=16384
> > fs.inode-max=65536
> >
> > But, in 2.4.3 doesn't support fs.inode-max  :(
> >
> > Dan Kegel wrote:
> >
> > > > How can I increase the FD in the Kernel 2.4.3?
> > >
> > > echo 32768 > /proc/sys/fs/file-max
> > >
> > > See also http://www.kegel.com/c10k.html#limits.filehandles
>
> You don't need fs.inode-max under 2.4.
>
> Can you check something for me?  Run the program dklimits.c from
> http://www.kegel.com/dkftpbench/#tuning
> with argument 1 and tell me what it prints.
> (Compile it with gcc -DLINUX dklimits.c.)
>
> - Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] SMP race in ext2 - metadata corruption.

[Martin Dalecki]

Linus Torvalds wrote:

> Dump was a stupid program in the first place. Leave it behind.

Not quite Linus - dump/restore are nice tools to create for example
automatic over network installation servers, i.e. efficient system
images
or such. tar/cpio and friends don't deal properly with

a. holes inside of files.
b. hardlinks between files.

Really they are not useless. However I wouldn't recommend them
for backup practicies as well.

Please see for example:

http://www.systime-solutions.de/index.php?topic=produkte=setupserver

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

Seagate ST340824A and (un)clipping max LBA: 2.2.19+ide04092001 patch

[Alexander Stavitsky]

Disk capacity unclipping routines in ide.2.2.19.04092001.patch do not unclip
Seagate ST340824A.

I have to use the jumper on the drive to make system boot.
I tried "setmax" program and it is able to unclip the capacity,
kernel however does not.

I digged a little and I think the problem is that ST340824A does not follow
the ATA standard - it does support both READ NATIVE MAX ADDRESS
and SET MAX ADDRESS, but does not advertise support for
Host Protected Area feature set.

drive->id->command_set_1 = 0x306b for the this drive.

The unclipping routines compare
drive->id->command_set_1 and 0x0400 (Host Protected Feature set)
The earlier version of the patch compared
drive->id->command_set_1 and 0x000a (Security Mode & Power Managment ???)

When I changed it back to 0x000a, it unclipped the capacity just fine.
But 0x000a doesn't make any sense to me.
What is the correct solution?

Also the idedisk_supports_host_protected_area is there, but not used and
the printk's notifying of unclipping are commented out???

I attach the diff to show what I'm talking about.

Also a related question: when I use "setmax", the drive reports full
capacity through "hdparm -I /dev/hd*", but kernel still uses the old info.
How does one update the kernel info after using "setmax"?


--- ide-disk.c.orig Mon Apr 16 13:30:50 2001
+++ ide-disk.c  Fri Apr 27 11:16:38 2001
@@ -546,7 +546,7 @@
ide_task_t args;
unsigned long addr = 0;
 
-   if (!(drive->id->command_set_1 & 0x0400))
+   if (!(drive->id->command_set_1 & 0x000a))
 // if (!(drive->id->cfs_enable_1 & 0x0400))
return addr;
 
@@ -580,7 +580,7 @@
ide_task_t args;
unsigned long addr_set = 0;

-// printk("%s: (un)clipping max LBA...%lu\n", drive->name, addr_req);
+   printk("%s: (un)clipping max LBA...%lu\n", drive->name, addr_req);
 
addr_req--;
/* Create IDE/ATA command request structure */
@@ -603,7 +603,7 @@
 | ((args.tfRegister[IDE_SECTOR_OFFSET]   ));
}
addr_set++;
-// printk("%s: max LBA (un)clipped to %lu\n", drive->name, addr_set);
+   printk("%s: max LBA (un)clipped to %lu\n", drive->name, addr_set);
return addr_set;
 }
 


-- 
  = mailto:[EMAIL PROTECTED]
 ===http://www.geocities.com/astavitsky
=   GPG Key 0xF7343C8B: 68DD 1E1B 2C98 D336 E31F  C87B 91B9 5244 F734 3C8B
  |_Alexander Stavitsky 

 PGP signature

Re: Lid support for ACPI

[Michael K. Johnson]

>PS: This seems very strange. What if machine is so crashed so that it
>can no longer shutdown properly. Will that mean that its CPU will
>damage itself?

No, the ACPI standard requires CPUs to shut themselves down before
any damage would occur from overheading.  Well, at least the 1.0b
version of the standard did; I haven't read 2.0 yet.

michaelkjohnson

 "He that composes himself is wiser than he that composes a book."
 Linux Application Development -- Ben Franklin
 http://people.redhat.com/johnsonm/lad/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: FD in Kernel 2.4.x

[Dan Kegel]

> How can I increase the FD in the Kernel 2.4.3? 

echo 32768 > /proc/sys/fs/file-max

See also http://www.kegel.com/c10k.html#limits.filehandles

- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] SMP race in ext2 - metadata corruption.

[Linus Torvalds]

[ linux-kernel added back as a cc ]

On Fri, 27 Apr 2001, Neil Conway wrote:
> 
> I'm surprised that dump is deprecated (by you at least ;-)).  What to
> use instead for backups on machines that can't umount disks regularly? 

Note that dump simply won't work reliably at all even in 2.4.x: the buffer
cache and the page cache (where all the actual data is) are not
coherent. This is only going to get even worse in 2.5.x, when the
directories are moved into the page cache as well.

So anybody who depends on "dump" getting backups right is already playing
russian rulette with their backups.  It's not at all guaranteed to get the
right results - you may end up having stale data in the buffer cache that
ends up being "backed up".

Dump was a stupid program in the first place. Leave it behind.

> I've always thought "tar" was a bit undesirable (updates atimes or
> ctimes for example).

Right now, the cpio/tar/xxx solutions are definitely the best ones, and
will work on multiple filesystems (another limitation of "dump"). Whatever
problems they have, they are still better than the _guaranteed_(*)  data
corruptions of "dump".

However, it may be that in the long run it would be advantageous to have a
"filesystem maintenance interface" for doing things like backups and
defragmentation..

Linus

(*) Dump may work fine for you a thousand times. But it _will_ fail under
the right circumstances. And there is nothing you can do about 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: ramdisk/tmpfs/ramfs/memfs ?

[Padraig Brady]

David Woodhouse wrote:
> 
> [EMAIL PROTECTED] said:
> > btw I get my initial root filesystem from a compact flash that can be
> > accessed just like a hardisk. It's writeable also like a harddisk, but
> > we boot with it readonly, and only mount it rw if we want to save
> > config or whatever. We definitely wouldn't swap to it as it has
> > limited erase/write cycles. The filesystem is compressed ext2.
> 
> Why copy it into RAM? Why not use cramfs and either turn the writable
> directories into symlinks into a ramfs which you create at boot time, or
> union-mount a ramfs over the top of it?

? I never said I copied it into RAM. The ramfs is just used for /tmp &
/var
which are symlinks on the flash. I didn't know you could read/write
cramfs
like ext2/JFFS2? I still want to be able to update/create/delete files
like a normal ext2 partition. Oh I see the confusion, sorry my fault,
when
I said the root filesystem is compressed ext2, I meant it's ext2 with
chattr +c done on all files (the e2compr patch implmenents it). By the
way why isn't e2compr a standard part of the kernel. I've have no
problems
at all with it.

I didn't know about union-mounting, seems useful.

As for whether to use tmpfs/ramfs I think they do basically the same
thing 
only the implementation is different. tmpfs uses shared mem and so is 
probably more portable than ramfs which it tightly coupled with VFS. I
think I'll use ramfs (with limits patch) so.

> [EMAIL PROTECTED] said:
> > As for using JFFS2 + MTD ramdisk intead of ext2+e2compr+ramdisk is not
> > an option as the only advantage would be journalling, you still can't
> > resize. IMHO JFFS is only required where you have flash without an IDE
> > interface.
> 
> True. We are currently lacking a compact, compressing, journalling
> filesystem for use on block devices. It's been suggested that we could make
> JFFS2 work on them, by making a fake MTD device which uses a block device
> as backing store. Nobody's yet shown me the code though :)

How much more efficent is JFFS than say ext3+e3compr, wrt:
logic size/logic speed/RAM requirements/filesystem structure size.

> --
> dwmw2

Padraig.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] SMP race in ext2 - metadata corruption.

[Linus Torvalds]

On Fri, 27 Apr 2001, Vojtech Pavlik wrote:
> 
> Actually this is done quite often, even on mounted fs's:
> 
> hdparm -t /dev/hda

Note that this one happens to be ok.

The buffer cache is "virtual" in the sense that /dev/hda is a completely
separate name-space from /dev/hda1, even if there is some physical
overlap.

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: 2.4.4-pre8 undefined symbols

[Michel Wilson]

I think Andrea's rwsem-patches fix these, but i'm not sure. You might give
it a try, though.

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Chua
> Sent: Friday, April 27, 2001 18:11
> To: Linux Kernel
> Cc: Jeff Chua
> Subject: 2.4.4-pre8 undefined symbols
>
>
>
> depmod -ae yields the following errors under 2.4.4-pre8
>
> Any fix?
>
>
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.4-pre8/kernel/drivers/char/drm/i810.o
> depmod: rwsem_down_write_failed
> depmod: rwsem_wake
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.4-pre8/kernel/drivers/char/drm/mga.o
> depmod: rwsem_down_write_failed
> depmod: rwsem_wake
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.4-pre8/kernel/drivers/char/drm/r128.o
> depmod: rwsem_down_write_failed
> depmod: rwsem_wake
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.4-pre8/kernel/drivers/char/drm/radeon.o
> depmod: rwsem_down_write_failed
> depmod: rwsem_wake
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.4-pre8/kernel/drivers/char/drm/tdfx.o
> depmod: rwsem_down_write_failed
> depmod: rwsem_wake
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.4-pre8/kernel/fs/binfmt_aout.o
> depmod: rwsem_down_write_failed
> depmod: rwsem_wake
>
>
>
> Thanks,
> Jeff
> [ [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/

FD in Kernel 2.4.x

[Federico Edelman Anaya]

Hi! I am newbie in this list! .. I'm Federico Edelman Anaya ... well! ..
I have a question ...

I need increase the FD (File Descriptors) ... I was change the value of
the FD in kernel 2.2.17:

/usr/include/bits/types.h:
#define __FD_SETSIZE1024->  4096

/usr/src/linux/include/linux/posix_types.h
#define __FD_SETSIZE1024->  4096

/usr/src/linux/include/linux/tasks.h
#define NR_TASKS   512 ->  2048   /* On x86 Max 4092, or
4090 w/APM configured. */


Well... Kernel 2.4.3:
/usr/include/bits/types.h:
#define __FD_SETSIZE1024->  4096

/usr/src/linux/include/linux/posix_types.h
#define __FD_SETSIZE1024->  4096

It's only change was posible to do ... Because, tasks.h doesn't exist!

How can I do to increase the FD in the Kernel 2.4.3?

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: devfs and /proc/ide/hda

[Richard Gooch]

AJ Lewis writes:
> 
> --CblX+4bnyfN0pR09
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Thu, Mar 08, 2001 at 01:32:03PM +0100, Goswin Brederlow wrote:
> >  > What it should do is change based on whether devfs is mounted
> >  > or not.  It doesn't make *any* sense to have
> >  > /dev/ide/host0/foo/bar in your /proc/partitions entries if you
> >  > aren't mounting devfs.  The /proc/partitions entry is the only
> >  > way I know of for something like LVM to determine which devices
> >  > to scan for Volume Groups.  If you can't read /proc/partitions,
> >  > it has to attempt to scan all block devices it recognizes,
> >  > regardless of whether they are actually on the system or not.
> >  > This can take several minutes.
> >=20
> > First:
> >=20
> > % cat /proc/partitions=20
> > major minor  #blocks  name
> >=20
> >3 0   20010816 ide/host0/bus0/target0/lun0/disc
> >3 1 192748 ide/host0/bus0/target0/lun0/part1
> >3 2 249007 ide/host0/bus0/target0/lun0/part2
> >3 3  1 ide/host0/bus0/target0/lun0/part3
> >3 5 289138 ide/host0/bus0/target0/lun0/part5
> >3 61951866 ide/host0/bus0/target0/lun0/part6
> >3 7 979933 ide/host0/bus0/target0/lun0/part7
> >3 8   16346106 ide/host0/bus0/target0/lun0/part8
> >   33 0   80043264 ide/host2/bus0/target0/lun0/disc
> >   33 1   80035798 ide/host2/bus0/target0/lun0/part1
> >=20
> > So its already right.
> 
> Only if devfs is mounted.  That's my point.  Maybe it's an corner
> case to have devfs compiled into the kernel, but not mounted, and so
> we can just ignore this, but it seems to me that /proc/partitions
> should reflect which /dev system is currently running.

I consider it a corner case. There isn't really an alternative.
Firstly, it would be really messy to magically change the output of
/proc/partitions depending on whether devfs was mounted. Secondly,
just because it's mounted doesn't mean it's mounted on /dev, so it's
still easy to get wrong.

> > Secondly with devfs, why not just scan all /dev/discs/?
> >=20
> > % ls -l /dev/discs=20
> > total 0
> > lr-xr-xr-x1 root root   30 Jan  1  1970 disc0 -> ../ide/h=
> ost0/bus0/target0/lun0/
> > lr-xr-xr-x1 root root   30 Jan  1  1970 disc1 -> ../ide/h=
> ost2/bus0/target0/lun0/
> >=20
> > Also if lvm opens all known devices by way of /dev/whatever while
> > scanning, it will only find existing devices there with devfs.
> 
> Yeah, as long as devfs is running, that makes sense.

If you want a really robust solution, have your tool scan
/proc/filesystems and see if devfs is available. If not, scan
/proc/partitions. If devfs is available, then create a temporary mount
point and mount it there, then scan $mntpoint/discs.

Regards,

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

Re: Hashing and directories

[Daniel Phillips]

On Thursday 08 March 2001 13:42, Goswin Brederlow wrote:
> > " " == Pavel Machek <[EMAIL PROTECTED]> writes:
>  > Hi!
>  >
> >> I was hoping to point out that in real life, most systems that
> >> need to access large numbers of files are already designed to
> >> do some kind of hashing, or at least to divide-and-conquer by
> >> using multi-level directory structures.
> >>
>  > Yes -- because their workaround kernel slowness.
>  >
>  > I had to do this kind of hashing because kernel disliked 7
>  > html files (copy of train time tables).
>  >
>  > BTW try rm * with 7 files in directory -- command line will
>  > overflow.
>
> There are filesystems that use btrees (reiserfs) or hashing (affs) for
> directories.
>
> That way you get a O(log(n)) or even O(1) access time for
> files. Saddly the hashtable for affs depends on the blocksize and
> linux AFAIK only allows far too small block sizes (512 byte) for affs.
> It was designed for floppies, so the lack of dynamically resizing hash
> tables is excused.
>
> What also could be done is to keed directories sorted. Creating of
> files would cost O(N) time but a lookup could be done in
> O(log(log(n))) most of the time with reasonable name distribution.
> This could be done with ext2 without breaking any compatibility. One
> would need to convert (sort all directories) every time the FS was
> mounted RW by an older ext2, but otherwise nothing changes.
>
> Would you like to write support for this?

Hi, I missed this whole thread at the time, ironically, because I was 
too busy working on my hash-keyed directory index.

How do you get log(log(n))?  The best I can do is logb(n), with
b=large.  For practical purposes this is O(1).

The only problem I ran into is the mismatch between the storage order
of the sorted directory and that of the inodes, which causes thrashing
in the inode table.  I was able to eliminate this thrashing completely
from user space by processing the files in inode order.  I went on to 
examine ways of eliminating the thrashing without help from user space,
and eventually came up with a good way of doing that that relies on
setting an inode allocation target that corresponds loosely to the sort
order.

The thrashing doesn't hurt much anyway compared to the current N**2
behaviour.  For a million files I saw a 4X slowdown for delete vs
create.  Create shows no thrashing because it works in storage order
in the inodes, with the directory blocks themselves being smaller by
a factor of 6-7, so not contributing significantly to the cache
pressure.  Compare this to the 150 times slowdown you see with normal
Ext2, creating 100,000 files.

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

2.4.4-pre8 undefined symbols

[Jeff Chua]

depmod -ae yields the following errors under 2.4.4-pre8

Any fix?


depmod: *** Unresolved symbols in
/lib/modules/2.4.4-pre8/kernel/drivers/char/drm/i810.o
depmod: rwsem_down_write_failed
depmod: rwsem_wake
depmod: *** Unresolved symbols in
/lib/modules/2.4.4-pre8/kernel/drivers/char/drm/mga.o
depmod: rwsem_down_write_failed
depmod: rwsem_wake
depmod: *** Unresolved symbols in
/lib/modules/2.4.4-pre8/kernel/drivers/char/drm/r128.o
depmod: rwsem_down_write_failed
depmod: rwsem_wake
depmod: *** Unresolved symbols in
/lib/modules/2.4.4-pre8/kernel/drivers/char/drm/radeon.o
depmod: rwsem_down_write_failed
depmod: rwsem_wake
depmod: *** Unresolved symbols in
/lib/modules/2.4.4-pre8/kernel/drivers/char/drm/tdfx.o
depmod: rwsem_down_write_failed
depmod: rwsem_wake
depmod: *** Unresolved symbols in
/lib/modules/2.4.4-pre8/kernel/fs/binfmt_aout.o
depmod: rwsem_down_write_failed
depmod: rwsem_wake



Thanks,
Jeff
[ [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: devfs and /proc/ide/hda

[AJ Lewis]

On Thu, Mar 08, 2001 at 01:32:03PM +0100, Goswin Brederlow wrote:
>  > What it should do is change based on whether devfs is mounted
>  > or not.  It doesn't make *any* sense to have
>  > /dev/ide/host0/foo/bar in your /proc/partitions entries if you
>  > aren't mounting devfs.  The /proc/partitions entry is the only
>  > way I know of for something like LVM to determine which devices
>  > to scan for Volume Groups.  If you can't read /proc/partitions,
>  > it has to attempt to scan all block devices it recognizes,
>  > regardless of whether they are actually on the system or not.
>  > This can take several minutes.
> 
> First:
> 
> % cat /proc/partitions 
> major minor  #blocks  name
> 
>3 0   20010816 ide/host0/bus0/target0/lun0/disc
>3 1 192748 ide/host0/bus0/target0/lun0/part1
>3 2 249007 ide/host0/bus0/target0/lun0/part2
>3 3  1 ide/host0/bus0/target0/lun0/part3
>3 5 289138 ide/host0/bus0/target0/lun0/part5
>3 61951866 ide/host0/bus0/target0/lun0/part6
>3 7 979933 ide/host0/bus0/target0/lun0/part7
>3 8   16346106 ide/host0/bus0/target0/lun0/part8
>   33 0   80043264 ide/host2/bus0/target0/lun0/disc
>   33 1   80035798 ide/host2/bus0/target0/lun0/part1
> 
> So its already right.

Only if devfs is mounted.  That's my point.  Maybe it's an corner case to
have devfs compiled into the kernel, but not mounted, and so we can just
ignore this, but it seems to me that /proc/partitions should reflect which
/dev system is currently running.

> Secondly with devfs, why not just scan all /dev/discs/?
> 
> % ls -l /dev/discs 
> total 0
> lr-xr-xr-x1 root root   30 Jan  1  1970 disc0 -> 
>../ide/host0/bus0/target0/lun0/
> lr-xr-xr-x1 root root   30 Jan  1  1970 disc1 -> 
>../ide/host2/bus0/target0/lun0/
> 
> Also if lvm opens all known devices by way of /dev/whatever while
> scanning, it will only find existing devices there with devfs.

Yeah, as long as devfs is running, that makes sense.

-- 
AJ Lewis
Sistina Software Inc.  Voice:  612-379-3951
1313 5th St SE, Suite 111  Fax:612-379-3952
Minneapolis, MN 55414  E-Mail: [EMAIL PROTECTED]
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)

-Begin Obligatory Humorous Quote
A computer without a Microsoft operating system is like a dog without bricks
tied to its head.
-End Obligatory Humorous Quote--

 PGP signature

Where did this patch come from?

[peck, william]

I was wondering if anyone could tell me who is responsible for the patch I
have included?  It fixes some issues with scanning the scsi bus,
specifically it reports luns higher than 8.  I am just wondering if whoever
has created this if they have submitted it to be included in the mainstream
2.2.x kernel series.


 patch-scsi-2.2.16-22.16

O_DIRECT support in 2.4.4?

[Michael Susæg]

We have tested the rawio and o_direct patches from Andrea Arcangeli 
with great success, and wondered if they will be part of the next 
kernel release, 2.4.4?

So far we have tested these patches on four different systems.
With the latest versions of these patches (rawio-6, o_direct-3) 
all systems works perfectly ok. Both with and without O_DIRECT 
enabled in big file operations.

The O_DIRECT support really helps performance a lot
for some types of applications. We happen to have such an 
application, and we would like to see O_DIRECT 
support in the kernel source in the near future.
 
This would lift Linux to a new level in terms of disk performance
for "self-caching" applications.

A performance test we did on our application shows a huge 
improvement, upto 8 times better data read speed with direct-IO.
With buffered IO, the CPU is doing caching most of the time.

I attached a graph showing this performance win using O_DIRECT
versus buffered IO. Each thread reads at a random offset a random 
amount of data from a big data set. The dataset is placed on 
a software RAID 0 with many disks. With that configuration 
we are able to fully utilize the 160 MB/s SCSI controllers.



-- 
Michael Susæg, M.Eng. Mail:  [EMAIL PROTECTED]
Software Engineer Web:   http://www.fast.no/
Fast Search & Transfer ASAPhone: +47 21 60 12 27
P.O. Box 1677 VikaFax:   +47 21 60 12 01
NO-0120 Oslo, NORWAY

Try FAST Search: http://www.alltheweb.com/

Re: kernel panic with 2.4.x and reiserfs

[Chris Mason]

On Friday, April 27, 2001 04:33:15 PM +0100 Tony Hoyle
<[EMAIL PROTECTED]> wrote:
 
> Reiserfs doesn't cope well with crashes  Under 2.4 I wouldn't
> recommend using it on any kind of critical server - it seems to
> progressively corrupt itself (I'm looking at the second reformat and
> reinstall in a week, and I'm not a happy bunny).

Could you please forward along the details of these corruptions (including
hardware)?  

> 
> As the warning on reiserfsck says, the rebuild-tree option is a last
> resort.  It's as likely to make the problem worse then improve it (It
> rounds all the file lengths up to a block size, padding with zeros, which
> breaks lots of stuff).  Backup what you can first.

It shouldn't always do this, most of the time it has enough info to get the
size right.  Which reiserfsck did you use?

-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: ramdisk/tmpfs/ramfs/memfs ?

[David Woodhouse]

[EMAIL PROTECTED] said:
> btw I get my initial root filesystem from a compact flash that can be
> accessed just like a hardisk. It's writeable also like a harddisk, but
> we boot with it readonly, and only mount it rw if we want to save
> config or whatever. We definitely wouldn't swap to it as it has
> limited erase/write cycles. The filesystem is compressed ext2.

Why copy it into RAM? Why not use cramfs and either turn the writable
directories into symlinks into a ramfs which you create at boot time, or 
union-mount a ramfs over the top of it?


[EMAIL PROTECTED] said:
> As for using JFFS2 + MTD ramdisk intead of ext2+e2compr+ramdisk is not
> an option as the only advantage would be journalling, you still can't
> resize. IMHO JFFS is only required where you have flash without an IDE
> interface.

True. We are currently lacking a compact, compressing, journalling 
filesystem for use on block devices. It's been suggested that we could make 
JFFS2 work on them, by making a fake MTD device which uses a block device 
as backing store. Nobody's yet shown me the code though :)

--
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: init process in 2.2.19

[Russell King]

On Thu, Apr 26, 2001 at 05:30:16PM +, Subba Rao wrote:
> I am trying to add a process which is to be managed by init. I have added the
> following entry to /etc/inittab
> 
> SV:2345:respawn:env - PATH=/usr/local/bin:/usr/sbin:/usr/bin:/bin svscan /service 
> dev/console
> 
> After saving, I execute the following command:
> 
>   # kill -HUP 1
> 
> This does not start the process I have added. The process that I have added
> only starts when I do:

telinit q tells init to re-read the inittab, as per the telinit man page.

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

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

Re: ramdisk/tmpfs/ramfs/memfs ?

[Bjorn Wesen]

On Fri, 27 Apr 2001, Padraig Brady wrote:
> for a partition. If I understand correctly ramfs just points
> to the file data which are pages in the cache marked not to be

It does not even do that - as of 2.4, the VFS in the kernel also knows how
to cache a filestructure itself. It's in the dentry-cache. So ramfs just
provides the thin mapping between VFS operations and the VFS caches
(dentries, inodes, pages) like any other 2.4 filesystem - with the
difference that ramfs does not need to know anything about actually
transferring the cache entries to a backing store (a physical filesystem).

Take a look at fs/ramfs/inode.c, it's just some hundred odd lines of
code and worth reading to find out more about how 2.4's VFS works.

> uncached. Doh! is ramfs supported in 2.2?

Don't think so, for the above reason.

-BW

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: ramdisk/tmpfs/ramfs/memfs ?

[Christoph Rohland]

Hi Padraig,

On Fri, 27 Apr 2001, Padraig Brady wrote:
> I don't have swap so don't need tmpfs, but could probably
> use it anyway without a backing store? 

Yes, it does not need backing store.

> Anyway why was ramfs created if tmpfs existed, unless tmpfs requires
> backing store?  They both seem to have been written around the same
> time?

- shm fs was written as a specialized fs to implement POSIX shared
  memory based on SYSV shm.
- ramfs was introduced shortly after shm fs and was meant as a
  programming example for a minimal virtual filesystem. 
- Later shm fs was redone to use the same methods like ramfs but still
  was only useable for shared memory.
- After the release of 2.4.0, I extended shm fs to support read/write
  and thus be tmpfs and since then it can replace ramfs.

Greetings
Christoph


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

Re: kernel panic with 2.4.x and reiserfs

[Tony Hoyle]

jason wrote:

> Hello,
> 
> As the subject would imply, I've been having problems with 2.4.x. I have
> my root partition (/dev/hda1) as reiserfs and also have another harddrive
> with a reiserfs partition (/dev/hdc1). Several programs write (e.g. save
> files to) /dev/hdc1, and I also store files there. Under 2.4.2, whenever
> manually copying files from hda1 to hdc1, I would get a kernel panic, the


Reiserfs doesn't cope well with crashes  Under 2.4 I wouldn't 
recommend using it on any kind of critical server - it seems to 
progressively corrupt itself (I'm looking at the second reformat and 
reinstall in a week, and I'm not a happy bunny).

As the warning on reiserfsck says, the rebuild-tree option is a last 
resort.  It's as likely to make the problem worse then improve it (It 
rounds all the file lengths up to a block size, padding with zeros, 
which breaks lots of stuff).  Backup what you can first.

I find that if you run reiserfsck -x /dev/hda1 a couple of dozen times 
it slowly fixes stuff that it couldn't fix on the previous pass.One 
thing that can't fix is the bug that seems to make random files on the 
FS unreadable even for root.The only way I've found around that one is a 
periodic format/reinstall.

Tony

-- 
Where a calculator on the ENIAC is equpped with 18,000 vaccuum
tubes and weighs 30 tons, computers in the future may have only
1,000 vaccuum tubes and perhaps weigh 1 1\2 tons.
-- Popular Mechanics, March 1949

[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/