Re: Notification payment schedule

[Colonel Marion Horn Jr]

Hello Sir


This brief introduction to the best way we have to conclude this transaction 
and have this funds wired to your account without any complication. Having 
studied your file and understanding limitations to the fund claim and documents 
limited to back you up as fund beneficiary. It will also cost us nothing and 
yet legalize the funding immediately.


I am aware that designated officials will be in North America and have direct 
beneficiary endorse fund release order in person through there paying bank in 
United Kingdom.


Your name will be included in the payment schedule and beneficiary in London , 
United Kingdom.


Once we have understanding, I will have them open communication with you and 
let them agree date and venue that will not be difficult for all parties. You 
will travel to London and have the final release order documents signed and the 
funds wired to your account as expected.


Regards


Congratulations
Colonel Marion Horn Jr.
Executive trustee.

Re: 2.4.5-ac12 kernel oops

[Colonel]

>>Hmm, I would have thought that /proc was more up to date, because it
>>would reflect changes.  No reboot, never even considered it (I've
>>rescued too many junior sysadmins that think rebooting is _the_ answer).
>
>/proc/ksyms is dynamic, it changes as modules are loaded and unloaded.
>And often the oops is so bad that the machine is dead so reboot is the
>only option, ksyms after reboot may be for a completely different
>kernel.  If you want accurate ksyms and lsmod data to feed into
>ksymoops, 'man insmod' and read section 'KSYMOOPS ASSISTANCE'.

OK, I added the cron task and directory, perhaps I need them sometime.
In any event, thanks for the info.  This certainly seems very well
thought out!


-- 
"Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen..."  -- Jason McMullan

ditto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.5-ac12 kernel oops

[Colonel]

Hmm, I would have thought that /proc was more up to date, because it
would reflect changes.  No reboot, never even considered it (I've
rescued too many junior sysadmins that think rebooting is _the_ answer).

/proc/ksyms is dynamic, it changes as modules are loaded and unloaded.
And often the oops is so bad that the machine is dead so reboot is the
only option, ksyms after reboot may be for a completely different
kernel.  If you want accurate ksyms and lsmod data to feed into
ksymoops, 'man insmod' and read section 'KSYMOOPS ASSISTANCE'.

OK, I added the cron task and directory, perhaps I need them sometime.
In any event, thanks for the info.  This certainly seems very well
thought out!


-- 
Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen...  -- Jason McMullan

ditto
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] Re: Thrashing WITHOUT swap.

[Colonel]

In clouddancer.list.kernel, you wrote:
>
>Further to that, I followed Alan's lead and installed xfce.  My laptop, which 
>was really suffering under Gnome with 64 meg (much more so under KDE) is 
>suddenly light on its feet.  Not to mention that it built from source in 
>under 10 minutes and installed with zero 'interesting problems'.
>
>After another year of optimizing the kernel to handle bloatware better, and 
>at the same time encouraging the 'big desktop' side of Linux to follow the 
>lead of these lightweight alternatives[1] we will be looking pretty good.


Had you tried fvwm-1.24r (the original) ?  It was designed long ago to
be lean and fast on the desktop.  I know it whips KDE.

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

[Colonel]

In clouddancer.list.kernel, you wrote:
>
>Hi all,
>
>Haven't been on this list for a while, and don't really know if this is the 
>right place for this message... If not, pls let me know.
>...
>Hope you guys can do something with this message!

Nope.  You need to run it thru ksymoops before the wizard's crystal
balls will clear sufficiently to help.  Look in /usr/src/linux/scripts
for clues.

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

[Colonel]

In clouddancer.list.kernel, you wrote:
>
>On Mon, 25 Jun 2001 08:15:49 -0700 (PDT), 
>[EMAIL PROTECTED] (Colonel) wrote:
>>ksymoops 2.4.1 on i686 2.4.5-ac12.  Options used
>>Warning (compare_maps): mismatch on symbol partition_name  , ksyms_base says 
>c01aad00, System.map says c014cba0.  Ignoring ksyms_base entry
>>Why the symbol mismatch?
>
>The mismatch is caused by two variables called partition_name.  What
>does 'nm vmlinux | grep partition_name' show?  Probably one

Can't run that, but : 

grep "partition_name" System.map-2.4.5-ac12 
c014cba0 t partition_name
c01aad00 T partition_name


>partition_name at c01aad00 and another at c014cba0.  Both
>fs/partitions/msdos.c and drivers/md/md.c define that symbol, md

and I have both in the kernel.

>exports its version.  A good reason why exported symbols should have
>unique names.

Only the raid5 was active, the msdos stuff is a module for 'just in
case'.  Something else triggered this, I've run raid for a long time
without problems.



>>Why ignore /proc over the System.map?
>
>ksymoops has a hierarchy of trust.  System.map is more trustworthy than
>/proc/ksyms because ksyms changes, especially if you rebooted after the
>oops and before running ksymoops.

Hmm, I would have thought that /proc was more up to date, because it
would reflect changes.  No reboot, never even considered it (I've
rescued too many junior sysadmins that think rebooting is _the_ answer).




-- 
"Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen..."  -- Jason McMullan

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

Re: What are the VM motivations??

[Colonel]

>> POST IT.  Give the rest of us some clues and the opportunity to check
>> evaluator's replies.
>
>Well, if you try that strategy you'll find you never get around to posting it 
>because you'll be too worried about getting it right.  The point is not to 
>get it right, it's to get a starting point down on (virtual) paper.  I'd 
>strongly suggest passing something like that around for comment privately 
>first.

Well, it does seem that some ego is involved here...

>
>*Then* post it.
>
>(and convince me you're not just talking)

As a physicist, I learned long ago that if you cannot use the back of
an envelope and explain your theory to a secretary, you do not
understand it.  It has only been revealed recently where some VM
design information may be hidden, and it's apparently out of date.
Maintenance requires good documentation, especially in critical areas.
I hope that your suggestion succeeds, and that a document is passed
around, but I'll bet a large amount that it doesn't happen.

If everyone is in the dark, it gets difficult to criticize the guy
with a match and leaves the matchholder in charge.  Some matchholders
want it that way.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.5-ac12 kernel oops

[Colonel]

Why the symbol mismatch?  Why ignore /proc over the System.map?

The system had very little running (because of prior lockups) during
the morning SQL activity. About 3/4 of a megabyte was being added to
the SQL databases, and that activity had been going on for 45 minutes
prior to the oops.  No X, and I was reading email as the only other
load.  Daemons: postfix, raid5, xntpd, syslog, cron & kernel.  SMP
kernel, built with gcc 2.95.3 released 20010315.

At the time of the oops, there is an cron task that feeds postfix,
which deposits the email into a 3 meg file.



--

ksymoops 2.4.1 on i686 2.4.5-ac12.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.5-ac12/ (default)
 -m /System.map-2.4.5-ac12 (specified)

Warning (compare_maps): mismatch on symbol partition_name  , ksyms_base says c01aad00, 
System.map says c014cba0.  Ignoring ksyms_base entry
Unable to handle kernel NULL pointer dereference at virtual address 0015
c0147e62
*pde = 
Oops: 0002
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 0005   ebx: c6ef1800   ecx: c021ed64   edx: c291
esi: c021ee80   edi: 000b   ebp: c5e2f340   esp: c601fea4
ds: 0018   es: 0018   ss: 0018
Process ps (pid: 10454, stackpage=c601f000)
Stack: c0144eae c6ef1800 c291 c7ff6000 c0148ffd c6ef1800 c021f1c0 c5e2f3a4 
   c01f79b8 c0149246 c7ff6000 c291 000b fff4 c1e85220 c601e000 
   c5e2f340 ffea c013abae c1e85220 c5e2f340 c601ff34  c1e85220 
Call Trace: [] [] [] [] [] 
   [] [] [] [] [] 
Code: f0 ff 48 10 8b 42 24 80 48 14 08 52 e8 0d ff ff ff 83 c4 04 

>>EIP; c0147e62<=
Trace; c0144eae 
Trace; c0148ffd 
Trace; c0149246 
Trace; c013abae 
Trace; c013b2eb 
Trace; c013bb4e 
Trace; c014392a 
Trace; c012fe23 
Trace; c013013e 
Trace; c0106c63 
Code;  c0147e62 
 <_EIP>:
Code;  c0147e62<=
   0:   f0 ff 48 10   lock decl 0x10(%eax)   <=
Code;  c0147e66 
   4:   8b 42 24  mov0x24(%edx),%eax
Code;  c0147e69 
   7:   80 48 14 08   orb$0x8,0x14(%eax)
Code;  c0147e6d 
   b:   52push   %edx
Code;  c0147e6e 
   c:   e8 0d ff ff ffcall   ff1e <_EIP+0xff1e> c0147d80 

Code;  c0147e73 
  11:   83 c4 04  add$0x4,%esp


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

2.4.5-ac12 kernel oops

[Colonel]

Why the symbol mismatch?  Why ignore /proc over the System.map?

The system had very little running (because of prior lockups) during
the morning SQL activity. About 3/4 of a megabyte was being added to
the SQL databases, and that activity had been going on for 45 minutes
prior to the oops.  No X, and I was reading email as the only other
load.  Daemons: postfix, raid5, xntpd, syslog, cron  kernel.  SMP
kernel, built with gcc 2.95.3 released 20010315.

At the time of the oops, there is an cron task that feeds postfix,
which deposits the email into a 3 meg file.



--

ksymoops 2.4.1 on i686 2.4.5-ac12.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.5-ac12/ (default)
 -m /System.map-2.4.5-ac12 (specified)

Warning (compare_maps): mismatch on symbol partition_name  , ksyms_base says c01aad00, 
System.map says c014cba0.  Ignoring ksyms_base entry
Unable to handle kernel NULL pointer dereference at virtual address 0015
c0147e62
*pde = 
Oops: 0002
CPU:0
EIP:0010:[c0147e62]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 0005   ebx: c6ef1800   ecx: c021ed64   edx: c291
esi: c021ee80   edi: 000b   ebp: c5e2f340   esp: c601fea4
ds: 0018   es: 0018   ss: 0018
Process ps (pid: 10454, stackpage=c601f000)
Stack: c0144eae c6ef1800 c291 c7ff6000 c0148ffd c6ef1800 c021f1c0 c5e2f3a4 
   c01f79b8 c0149246 c7ff6000 c291 000b fff4 c1e85220 c601e000 
   c5e2f340 ffea c013abae c1e85220 c5e2f340 c601ff34  c1e85220 
Call Trace: [c0144eae] [c0148ffd] [c0149246] [c013abae] [c013b2eb] 
   [c013bb4e] [c014392a] [c012fe23] [c013013e] [c0106c63] 
Code: f0 ff 48 10 8b 42 24 80 48 14 08 52 e8 0d ff ff ff 83 c4 04 

EIP; c0147e62 proc_delete_inode+32/48   =
Trace; c0144eae iput+ba/178
Trace; c0148ffd proc_pid_make_inode+ad/b8
Trace; c0149246 proc_base_lookup+86/23c
Trace; c013abae real_lookup+7a/108
Trace; c013b2eb path_walk+58f/7c4
Trace; c013bb4e open_namei+86/598
Trace; c014392a destroy_inode+1a/20
Trace; c012fe23 filp_open+3b/5c
Trace; c013013e sys_open+36/cc
Trace; c0106c63 system_call+33/38
Code;  c0147e62 proc_delete_inode+32/48
 _EIP:
Code;  c0147e62 proc_delete_inode+32/48   =
   0:   f0 ff 48 10   lock decl 0x10(%eax)   =
Code;  c0147e66 proc_delete_inode+36/48
   4:   8b 42 24  mov0x24(%edx),%eax
Code;  c0147e69 proc_delete_inode+39/48
   7:   80 48 14 08   orb$0x8,0x14(%eax)
Code;  c0147e6d proc_delete_inode+3d/48
   b:   52push   %edx
Code;  c0147e6e proc_delete_inode+3e/48
   c:   e8 0d ff ff ffcall   ff1e _EIP+0xff1e c0147d80 
de_put+0/b0
Code;  c0147e73 proc_delete_inode+43/48
  11:   83 c4 04  add$0x4,%esp


1 warning 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: What are the VM motivations??

[Colonel]

 POST IT.  Give the rest of us some clues and the opportunity to check
 evaluator's replies.

Well, if you try that strategy you'll find you never get around to posting it 
because you'll be too worried about getting it right.  The point is not to 
get it right, it's to get a starting point down on (virtual) paper.  I'd 
strongly suggest passing something like that around for comment privately 
first.

Well, it does seem that some ego is involved here...


*Then* post it.

(and convince me you're not just talking)

As a physicist, I learned long ago that if you cannot use the back of
an envelope and explain your theory to a secretary, you do not
understand it.  It has only been revealed recently where some VM
design information may be hidden, and it's apparently out of date.
Maintenance requires good documentation, especially in critical areas.
I hope that your suggestion succeeds, and that a document is passed
around, but I'll bet a large amount that it doesn't happen.

If everyone is in the dark, it gets difficult to criticize the guy
with a match and leaves the matchholder in charge.  Some matchholders
want it that way.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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.5-ac12 kernel oops

[Colonel]

In clouddancer.list.kernel, you wrote:

On Mon, 25 Jun 2001 08:15:49 -0700 (PDT), 
[EMAIL PROTECTED] (Colonel) wrote:
ksymoops 2.4.1 on i686 2.4.5-ac12.  Options used
Warning (compare_maps): mismatch on symbol partition_name  , ksyms_base says 
c01aad00, System.map says c014cba0.  Ignoring ksyms_base entry
Why the symbol mismatch?

The mismatch is caused by two variables called partition_name.  What
does 'nm vmlinux | grep partition_name' show?  Probably one

Can't run that, but : 

grep partition_name System.map-2.4.5-ac12 
c014cba0 t partition_name
c01aad00 T partition_name


partition_name at c01aad00 and another at c014cba0.  Both
fs/partitions/msdos.c and drivers/md/md.c define that symbol, md

and I have both in the kernel.

exports its version.  A good reason why exported symbols should have
unique names.

Only the raid5 was active, the msdos stuff is a module for 'just in
case'.  Something else triggered this, I've run raid for a long time
without problems.



Why ignore /proc over the System.map?

ksymoops has a hierarchy of trust.  System.map is more trustworthy than
/proc/ksyms because ksyms changes, especially if you rebooted after the
oops and before running ksymoops.

Hmm, I would have thought that /proc was more up to date, because it
would reflect changes.  No reboot, never even considered it (I've
rescued too many junior sysadmins that think rebooting is _the_ answer).




-- 
Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen...  -- Jason McMullan

ditto
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 2.4.5 crash

[Colonel]

In clouddancer.list.kernel, you wrote:

Hi all,

Haven't been on this list for a while, and don't really know if this is the 
right place for this message... If not, pls let me know.
...
Hope you guys can do something with this message!

Nope.  You need to run it thru ksymoops before the wizard's crystal
balls will clear sufficiently to help.  Look in /usr/src/linux/scripts
for clues.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] Re: Thrashing WITHOUT swap.

[Colonel]

In clouddancer.list.kernel, you wrote:

Further to that, I followed Alan's lead and installed xfce.  My laptop, which 
was really suffering under Gnome with 64 meg (much more so under KDE) is 
suddenly light on its feet.  Not to mention that it built from source in 
under 10 minutes and installed with zero 'interesting problems'.

After another year of optimizing the kernel to handle bloatware better, and 
at the same time encouraging the 'big desktop' side of Linux to follow the 
lead of these lightweight alternatives[1] we will be looking pretty good.


Had you tried fvwm-1.24r (the original) ?  It was designed long ago to
be lean and fast on the desktop.  I know it whips KDE.

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

Re: What are the VM motivations??

[Colonel]

In clouddancer.list.kernel, you wrote:
>
>On Monday 25 June 2001 03:46, Russell Leighton wrote:
>> I read this thread as asking the question:
>>
>> If VM management is viewed as an optimization problem,
>> then what exactly is the function that you are optimizing and what are
>> the constraints?
>>
>> If you could express that well with a even a very loose model, then
>> the code could be reviewed to see if it was really doing what was intended
>> and assumptions could be tested.
>
>May I suggested an algorithm?
>
>  - Write down what you think the optimization constraints are.
>(be specific, for example, enumerate all the flavors of page types -
>process code, process data, page cache file data, page cache swap
>cache, anonymous, shmem, etc.)
>
>  - Write down what you think the current algorithms are.
>(again, be specific, use file names, function names, pseudocode and 
>snippets of existing code.)
>
>  - Send it to Rik.  He'll tell you if it's right.

POST IT.  Give the rest of us some clues and the opportunity to check
evaluator's replies.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: What are the VM motivations??

[Colonel]

In clouddancer.list.kernel, you wrote:
>
>On Sun, 24 Jun 2001, Colonel wrote:
>
>> It's simple.  I want the old reliable behavior back, the one I found
>> in kernels from 1.1.41 thru 2.2.14.
>
>And which one would that be ?   Note that there have been
>4 different VM subsystems in that time and the kernel has
>made the transition from the buffer cache to the page cache
>in that period.

Once again a typical Rik comment.  Completely misses the point and
picks something obscure to comment upon, after carefully removing the
remaining text.  PICK ONE!


>Please make up your mind before making feature requests ;)

Try OPENING yours.  There really is a world beyond your nose.


-- 
"Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen..."  -- Jason McMullan

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

Re: Annoying kernel behaviour

[Colonel]

In clouddancer.list.kernel, you wrote:
>
>Colonel wrote:
>> Ah, notice that the IRQ shifted?  Perhaps there is something else on
>> irq 10, such as the SCSI controller?  My video cards always end up on
>> that IRQ, perhaps the computer is still accessible via the network?
>
>I would expect the IRQ to shift as the system has a different
>motherboard/processor than it did in December.
>
>There are no conflicts, and PCI should be able to share anyways.

That's the theory now for some time, has never worked.  Even hacking
the SCSI driver, any attempted IRQ sharing kills my systems.  Even my
quad ethernet is not successful at sharing IRQs with itself, in 2+ very
different motherboards.


>Waht part of this do you fail to grasp?

Hehe.  The only reason you got a reply from me was that I run
video4linux with 2.4 kernels without a problem (or at least I think I
do, there are some problems but never when using xawtv).
Additionally, I've run the new RAID since the initrd period and
mingo's patches have never failed.  Any problems with RAID mentioned
on the mailing list were always traced to user error.  In short, what
you were trying to run worked fine here.

Replies afterwards were merely some guesses based on the
information you supplied.  Such as: try pulling out some hardware and
seeing if that helps.  You need to troubleshoot down to something
repeatable in order to get additional help.



-- 
"Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen..."  -- Jason McMullan

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

Re: What are the VM motivations??

[Colonel]

In clouddancer.list.kernel, you wrote:
>
>On Thu, 21 Jun 2001, Jason McMullan wrote:
>
>>  One we know how we would 'train' our little VM critter, we 
>> will know how to measure its performance. Once we have measures, we
>> can have good benchmarks. Once we have good benchmarks - we can pick
>> a good VM alg. 
>> 
>>  Or heck, let's just make the VM a _real_ Neural Network, that
>
>OK.  I challenge you to come up with:
>
>1) the set of inputs for the neural network
>2) the set of outputs
>3) the goal for training the thing
>
>I'm pretty fed up with people who want to "change the VM"
>but never give any details of their ideas.


It's simple.  I want the old reliable behavior back, the one I found
in kernels from 1.1.41 thru 2.2.14.  The behavior that I have enjoyed
for 7 years, the one that allows me to chuckle when listening to
windoze user's expressing their woes.  Not the one that kills
important processes because of some fantasy AI, not the one that locks
up the machine.  The one that lets me run an unattended machine for
months rather than barely make it thru a week.

What you hear now is nothing compared to the roar that will occur
shortly (as the distributions start releasing 2.4 versions) when the
masses encounter the current surprises.  They will not be able to say
in detail how to change the VM, other than the above.  We want to USE
linux and depend upon it, not become VM gurus to fix our kernels.



-- 
"Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen..."  -- Jason McMullan

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

Re: Annoying kernel behaviour

[Colonel]

In clouddancer.list.kernel, you wrote:


>bttv0: Bt848 (rev 18) at 00:0f.0, irq: 10, latency: 64, memory: 0xd79ff000

> ** ^^ this worked in 2.2.19 as 
>bttv0: Brooktree Bt848 (rev 18) bus: 0, devfn: 88, irq: 11, memory:
>
>It shouldn't matter, as userspace programs should not be able te fuck te
>kernel over in such a complete instant deadlock.  There is something


Ah, notice that the IRQ shifted?  Perhaps there is something else on
irq 10, such as the SCSI controller?  My video cards always end up on
that IRQ, perhaps the computer is still accessible via the network?



-- 
"Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen..."  -- Jason McMullan

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

Re: Annoying kernel behaviour

[Colonel]

In clouddancer.list.kernel, you wrote:


bttv0: Bt848 (rev 18) at 00:0f.0, irq: 10, latency: 64, memory: 0xd79ff000

 ** ^^ this worked in 2.2.19 as 
bttv0: Brooktree Bt848 (rev 18) bus: 0, devfn: 88, irq: 11, memory:

It shouldn't matter, as userspace programs should not be able te fuck te
kernel over in such a complete instant deadlock.  There is something


Ah, notice that the IRQ shifted?  Perhaps there is something else on
irq 10, such as the SCSI controller?  My video cards always end up on
that IRQ, perhaps the computer is still accessible via the network?



-- 
Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen...  -- Jason McMullan

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

Re: What are the VM motivations??

[Colonel]

In clouddancer.list.kernel, you wrote:

On Thu, 21 Jun 2001, Jason McMullan wrote:

  One we know how we would 'train' our little VM critter, we 
 will know how to measure its performance. Once we have measures, we
 can have good benchmarks. Once we have good benchmarks - we can pick
 a good VM alg. 
 
  Or heck, let's just make the VM a _real_ Neural Network, that

OK.  I challenge you to come up with:

1) the set of inputs for the neural network
2) the set of outputs
3) the goal for training the thing

I'm pretty fed up with people who want to change the VM
but never give any details of their ideas.


It's simple.  I want the old reliable behavior back, the one I found
in kernels from 1.1.41 thru 2.2.14.  The behavior that I have enjoyed
for 7 years, the one that allows me to chuckle when listening to
windoze user's expressing their woes.  Not the one that kills
important processes because of some fantasy AI, not the one that locks
up the machine.  The one that lets me run an unattended machine for
months rather than barely make it thru a week.

What you hear now is nothing compared to the roar that will occur
shortly (as the distributions start releasing 2.4 versions) when the
masses encounter the current surprises.  They will not be able to say
in detail how to change the VM, other than the above.  We want to USE
linux and depend upon it, not become VM gurus to fix our kernels.



-- 
Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen...  -- Jason McMullan

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

Re: Annoying kernel behaviour

[Colonel]

In clouddancer.list.kernel, you wrote:

Colonel wrote:
 Ah, notice that the IRQ shifted?  Perhaps there is something else on
 irq 10, such as the SCSI controller?  My video cards always end up on
 that IRQ, perhaps the computer is still accessible via the network?

I would expect the IRQ to shift as the system has a different
motherboard/processor than it did in December.

There are no conflicts, and PCI should be able to share anyways.

That's the theory now for some time, has never worked.  Even hacking
the SCSI driver, any attempted IRQ sharing kills my systems.  Even my
quad ethernet is not successful at sharing IRQs with itself, in 2+ very
different motherboards.


Waht part of this do you fail to grasp?

Hehe.  The only reason you got a reply from me was that I run
video4linux with 2.4 kernels without a problem (or at least I think I
do, there are some problems but never when using xawtv).
Additionally, I've run the new RAID since the initrd period and
mingo's patches have never failed.  Any problems with RAID mentioned
on the mailing list were always traced to user error.  In short, what
you were trying to run worked fine here.

Replies afterwards were merely some guesses based on the
information you supplied.  Such as: try pulling out some hardware and
seeing if that helps.  You need to troubleshoot down to something
repeatable in order to get additional help.



-- 
Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen...  -- Jason McMullan

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

Re: What are the VM motivations??

[Colonel]

In clouddancer.list.kernel, you wrote:

On Sun, 24 Jun 2001, Colonel wrote:

 It's simple.  I want the old reliable behavior back, the one I found
 in kernels from 1.1.41 thru 2.2.14.

And which one would that be ?   Note that there have been
4 different VM subsystems in that time and the kernel has
made the transition from the buffer cache to the page cache
in that period.

Once again a typical Rik comment.  Completely misses the point and
picks something obscure to comment upon, after carefully removing the
remaining text.  PICK ONE!


Please make up your mind before making feature requests ;)

Try OPENING yours.  There really is a world beyond your nose.


-- 
Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen...  -- Jason McMullan

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

Re: What are the VM motivations??

[Colonel]

In clouddancer.list.kernel, you wrote:

On Monday 25 June 2001 03:46, Russell Leighton wrote:
 I read this thread as asking the question:

 If VM management is viewed as an optimization problem,
 then what exactly is the function that you are optimizing and what are
 the constraints?

 If you could express that well with a even a very loose model, then
 the code could be reviewed to see if it was really doing what was intended
 and assumptions could be tested.

May I suggested an algorithm?

  - Write down what you think the optimization constraints are.
(be specific, for example, enumerate all the flavors of page types -
process code, process data, page cache file data, page cache swap
cache, anonymous, shmem, etc.)

  - Write down what you think the current algorithms are.
(again, be specific, use file names, function names, pseudocode and 
snippets of existing code.)

  - Send it to Rik.  He'll tell you if it's right.

POST IT.  Give the rest of us some clues and the opportunity to check
evaluator's replies.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Annoying kernel behaviour

[Colonel]

In clouddancer.list.kernel, you wrote:
>
>   I upgraded a fileserver to 2.4.5 because of the RAID support (the 0.90
>patch I grabbed did not apply cleanly to 2.2.19, despite it being a fresh
>copy).

Look in the people/mingo directory for a patch

>  Besides a nice speed increase (the EEPro now pumps 10 megs a second,
>instead of 2 or 3), there is a problem with the video4linux in it.  The box
>has a bttv card hooked up to a camera.  Under 2.2.19, Apache had mod_video
>installed, which would produce a jpeg of the composite in on the card (a
>cheapy CCD camera is hooked up).  Upon insmoding:

I have:

Linux video capture interface: v1.00
bttv: driver version 0.7.63 loaded
bttv: using 2 buffers with 2080k (4160k total) for capture
bttv: Host bridge needs ETBF enabled.
bttv: Bt8xx card found (0).
bttv0: Bt878 (rev 2) at 00:0b.0, irq: 10, latency: 32, memory: 0xe300
bttv0: subsystem: 144f:3000  =>  TView 99 (CPH063)  =>  card=38
bttv0: model: BT878(TView99 CPH063) [autodetected]
bttv0: enabling ETBF (430FX/VP3 compatibilty)
i2c-core.o: adapter bt848 #0 registered as adapter 0.

 working in 2.4.5-ac12 SMP+RAID.  I used

Bttv-0.7.63-2.4.3.patch.bz2

from the website.  Video4linux has always worked in the various 2.4
kernels I've tried.


>and accesing mod_video, the box locked up hard (not even sysrq worked).  And

I don't run mod_video, but xawtv works fine.  Did you try that or
rebuilding mod_video?


>when I rebooted, I found that some files is /etc were eaten -- even though

You must have grues.


-- 
"Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen..."  -- Jason McMullan

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

Re: Annoying kernel behaviour

[Colonel]

In clouddancer.list.kernel, you wrote:

   I upgraded a fileserver to 2.4.5 because of the RAID support (the 0.90
patch I grabbed did not apply cleanly to 2.2.19, despite it being a fresh
copy).

Look in the people/mingo directory for a patch

  Besides a nice speed increase (the EEPro now pumps 10 megs a second,
instead of 2 or 3), there is a problem with the video4linux in it.  The box
has a bttv card hooked up to a camera.  Under 2.2.19, Apache had mod_video
installed, which would produce a jpeg of the composite in on the card (a
cheapy CCD camera is hooked up).  Upon insmoding:

I have:

Linux video capture interface: v1.00
bttv: driver version 0.7.63 loaded
bttv: using 2 buffers with 2080k (4160k total) for capture
bttv: Host bridge needs ETBF enabled.
bttv: Bt8xx card found (0).
bttv0: Bt878 (rev 2) at 00:0b.0, irq: 10, latency: 32, memory: 0xe300
bttv0: subsystem: 144f:3000  =  TView 99 (CPH063)  =  card=38
bttv0: model: BT878(TView99 CPH063) [autodetected]
bttv0: enabling ETBF (430FX/VP3 compatibilty)
i2c-core.o: adapter bt848 #0 registered as adapter 0.

 working in 2.4.5-ac12 SMP+RAID.  I used

Bttv-0.7.63-2.4.3.patch.bz2

from the website.  Video4linux has always worked in the various 2.4
kernels I've tried.


and accesing mod_video, the box locked up hard (not even sysrq worked).  And

I don't run mod_video, but xawtv works fine.  Did you try that or
rebuilding mod_video?


when I rebooted, I found that some files is /etc were eaten -- even though

You must have grues.


-- 
Or heck, let's just make the VM a _real_ Neural Network, that self
trains itself to the load you put on the system. Hideously complex and
evil?  Well, why not wire up that roach on the floor, eating that stale
cheese doodle. It can't do any worse job on VM that some of the VM
patches I've seen...  -- Jason McMullan

ditto
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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.6 pre5 Stillborn

[Colonel]

Attempting to boot my 2.4 test box got as far as:

"Uncompressing Linux... Ok, booting the kernel"


It has been running previous versions of (working) 2.4 releases.




--My pid is Inigo Montoya.  You killed -9 my parent process.  Prepare to 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/

2.4.6 pre5 Stillborn

[Colonel]

Attempting to boot my 2.4 test box got as far as:

Uncompressing Linux... Ok, booting the kernel


It has been running previous versions of (working) 2.4 releases.




--My pid is Inigo Montoya.  You killed -9 my parent process.  Prepare to 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/

Re: a memory-related problem?

[Colonel]

In clouddancer.list.kernel, you wrote:
>
>Hi,
>
>I just added 128 MB of RAM to my machine which already had 128 MB and
>which has 128 MB swap. 128 MB RAM + 128 MB swap (either the new or the
>old 128 MB RAM) works, but the combination of that, 256 MB RAM + 128 MB
>swap, crashes the compu during startup with either an "unresolved-
>symbols in init" message (which is completely random, each boot shows
>different unresolved references) or with oopses right after starting
>init.

It's more likely that the two RAM sticks differ.  I had a similar
problem in a Windoze machine awhile ago.  Move one stick of RAM into
another bank, i.e. with 4 memory slots, use #1 and #3.  If you only
have 2 memory slots, return/sell what you have and buy 2 sticks at the
same time.


--My pid is Inigo Montoya.  You killed -9 my parent process.  Prepare to 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/

Re: Kernel configuration. It's not just a job, it's an adventure!

[Colonel]

In clouddancer.list.kernel, you wrote:
>
>[EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>> I have to ask, is this something you wrote, or an actual log from
>> something you wrote? (=:]
>
>What?  Moi, perpetrate a trifling and crude hoax?  You wound me, sir,
>by supposing I would ever stoop to such gaucherie.  It is so much more
>*elegantly* absurd to actually write the program, is it not?
>
>CML2 Adventure is part of the 1.6.1 release of CML2.  You can download
>it from  and try it out yourself.


It this doesn't get people to try CML2, nothing will.  I still
remember many years ago walking into the labs and hearing the graduate
students.  They were shouting stuff like "jump thru the window" and
"wave rod".  A roomful was engaged in solving "adventr", no useful
work was accomplished for 3+ days and close to a $100,000 in computer
dollars was spent after this virus ^h^h^h^h^h^h game appeared on the
mainframe.

I keep wondering if the Pirate was includednot to mention, "Witt's
End".


--My pid is Inigo Montoya.  You killed -9 my parent process.  Prepare to 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/

Re: Kernel configuration. It's not just a job, it's an adventure!

[Colonel]

In clouddancer.list.kernel, you wrote:

[EMAIL PROTECTED] [EMAIL PROTECTED]:
 I have to ask, is this something you wrote, or an actual log from
 something you wrote? (=:]

What?  Moi, perpetrate a trifling and crude hoax?  You wound me, sir,
by supposing I would ever stoop to such gaucherie.  It is so much more
*elegantly* absurd to actually write the program, is it not?

CML2 Adventure is part of the 1.6.1 release of CML2.  You can download
it from http://www.tuxedo.org/~esr/cml2/ and try it out yourself.


It this doesn't get people to try CML2, nothing will.  I still
remember many years ago walking into the labs and hearing the graduate
students.  They were shouting stuff like jump thru the window and
wave rod.  A roomful was engaged in solving adventr, no useful
work was accomplished for 3+ days and close to a $100,000 in computer
dollars was spent after this virus ^h^h^h^h^h^h game appeared on the
mainframe.

I keep wondering if the Pirate was includednot to mention, Witt's
End.


--My pid is Inigo Montoya.  You killed -9 my parent process.  Prepare to 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/

Re: a memory-related problem?

[Colonel]

In clouddancer.list.kernel, you wrote:

Hi,

I just added 128 MB of RAM to my machine which already had 128 MB and
which has 128 MB swap. 128 MB RAM + 128 MB swap (either the new or the
old 128 MB RAM) works, but the combination of that, 256 MB RAM + 128 MB
swap, crashes the compu during startup with either an unresolved-
symbols in init message (which is completely random, each boot shows
different unresolved references) or with oopses right after starting
init.

It's more likely that the two RAM sticks differ.  I had a similar
problem in a Windoze machine awhile ago.  Move one stick of RAM into
another bank, i.e. with 4 memory slots, use #1 and #3.  If you only
have 2 memory slots, return/sell what you have and buy 2 sticks at the
same time.


--My pid is Inigo Montoya.  You killed -9 my parent process.  Prepare to 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/

Re: obsolete code must die

[Colonel]

In list.kernel, you wrote:

>i think we are all missing the ball here: i am happy when i see driver
>support for a piece of hardware that i have _NEVER_ heard of and at most
>_ONE_ person uses it.  why?  it means more stuff works in linux.  we
>dont need to defend how many people use hardware X.  if you have X, good
>for you.  if not, you dont care, but at least good for linux as a whole.

Good Point!

>lets stop fanning the flames and let this (Microsoft-using, as Rik
>pointed out) troll die off.

Agreed, he made the filter already.  But it was good for some laughs,
checking a few cobwebs and I really didn't see flames.  Plus I got to
test my new mailing list archive.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: obsolete code must die

[Colonel]

In list.kernel, you wrote:
>
>Anyone concerned about the current size of the kernel source code? I am, and

No.  Since you are up to date with the latest in everything, I cannot
see why you would be concerned about a few megabytes in your gigabyte
drives.


>i386, i486
>The Pentium processor has been around since 1995. Support for these older

No.  Both of my cheap on-site systems for occasional access are 486s.
Why would I spend money for a system that is hardly ever used?


>ISA bus, MCA bus, EISA bus
>PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
>CONFIG_ISAPNP, etc

No.  There are still plenty of unique ISA cards around.


>MFM/RLL/XT/ESDI hard drive support
>Does anyone still *have* an RLL drive that works? At the very least get rid

OK, I haven't seen one of these for nearly 10 years.


>parallel/serial/game ports
>More controversial to remove this, since they are *still* in pretty wide
>use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts.

Send me the funds to replace my laser printers please.


>a.out
>Who needs it anymore. I love ELF.

OK, everything that I had in a.out was converted within a year of
ELF's introduction.


>I really think doing a clean up is worthwhile. Maybe while looking for stuff

You left out all the old non-IDE CDROM drives.
 


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

No Subject

[Colonel]

From: Colonel <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
In-reply-to: <[EMAIL PROTECTED]>
(message from Luigi Genoni on Wed, 13 Jun 2001 11:32:35 +0200 (CEST))
Subject: Re: your mail
Reply-to: [EMAIL PROTECTED]
References:  <[EMAIL PROTECTED]>

   Date: Wed, 13 Jun 2001 11:32:35 +0200 (CEST)
   From: Luigi Genoni <[EMAIL PROTECTED]>
   Cc: <[EMAIL PROTECTED]>
   Content-Type: TEXT/PLAIN; charset=US-ASCII

   I have the sound blaster 16 card on one of my athlon (on PIII i have
   es1731), that has one isa slot on its MB.
   It works well, but i do not use isapnp nor any pnp support is enabled
   inside of the kernel.
   running 2.4.5/2.4.6-pre2

   Luigi


Yes, dropping any PNP support does resolve the problem.  For my
installation, I don't need PNP support, so it's OK.  The bug is in the
communication between the 2 modules.




   On Tue, 12 Jun 2001, Colonel wrote:

   > From: Colonel <[EMAIL PROTECTED]>
   > To: [EMAIL PROTECTED]
   > Subject: ISA Soundblaster problem
   > Reply-to: [EMAIL PROTECTED]
   >
   >
   > The Maintainers list does not contain anyone for 2.4 Soundblaster
   > modules, so perhaps some one on the mailing list is aware of a
   > solution.  My ISA Soundblaster 16waveffects worked fine in kernel 2.2
   > with XMMS.  But I have never been successful in a varity of 2.4
   > kernels, the latest being 2.4.5-ac12.  This is what I know:
   >
   > [DMESG]
   > isapnp: Scanning for PnP cards...
   > isapnp: Calling quirk for 01:00
   > isapnp: SB audio device quirk - increasing port range
   > isapnp: Card 'Creative SB16 PnP'
   > isapnp: 1 Plug & Play card detected total
   >
   > }modprobe sb
   > /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: init_module: No such device
   > /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: Hint: insmod errors can be 
caused by incorrect module parameters, including invalid IO or IRQ parameters
   > /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod 
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o failed
   > /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod sb failed
   >
   >
   > [/etc/modules.conf]
   > options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
   >
   >
   > [DMESG}
   > Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
   > sb: No ISAPnP cards found, trying standard ones...
   > sb: dsp reset failed.
   >
   >
   > So it seems that PnP finds the card, but the connections (or even the
   > forced values) to the sb module fail.  Back when this was a single
   > processor machine, but still running 2.4 kernel, a windoze
   > installation found the SB at the listed interface parameters.
   >
   >
   > Anyone have a solution?
   >
   > Same problem without modules.conf settings, valid version of mod
   > utilities, a web search did not help,...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

No Subject

[Colonel]

From: Colonel [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
In-reply-to: [EMAIL PROTECTED]
(message from Luigi Genoni on Wed, 13 Jun 2001 11:32:35 +0200 (CEST))
Subject: Re: your mail
Reply-to: [EMAIL PROTECTED]
References:  [EMAIL PROTECTED]

   Date: Wed, 13 Jun 2001 11:32:35 +0200 (CEST)
   From: Luigi Genoni [EMAIL PROTECTED]
   Cc: [EMAIL PROTECTED]
   Content-Type: TEXT/PLAIN; charset=US-ASCII

   I have the sound blaster 16 card on one of my athlon (on PIII i have
   es1731), that has one isa slot on its MB.
   It works well, but i do not use isapnp nor any pnp support is enabled
   inside of the kernel.
   running 2.4.5/2.4.6-pre2

   Luigi


Yes, dropping any PNP support does resolve the problem.  For my
installation, I don't need PNP support, so it's OK.  The bug is in the
communication between the 2 modules.




   On Tue, 12 Jun 2001, Colonel wrote:

From: Colonel [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: ISA Soundblaster problem
Reply-to: [EMAIL PROTECTED]
   
   
The Maintainers list does not contain anyone for 2.4 Soundblaster
modules, so perhaps some one on the mailing list is aware of a
solution.  My ISA Soundblaster 16waveffects worked fine in kernel 2.2
with XMMS.  But I have never been successful in a varity of 2.4
kernels, the latest being 2.4.5-ac12.  This is what I know:
   
[DMESG]
isapnp: Scanning for PnP cards...
isapnp: Calling quirk for 01:00
isapnp: SB audio device quirk - increasing port range
isapnp: Card 'Creative SB16 PnP'
isapnp: 1 Plug  Play card detected total
   
}modprobe sb
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: init_module: No such device
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: Hint: insmod errors can be 
caused by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod 
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o failed
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod sb failed
   
   
[/etc/modules.conf]
options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
   
   
[DMESG}
Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
sb: No ISAPnP cards found, trying standard ones...
sb: dsp reset failed.
   
   
So it seems that PnP finds the card, but the connections (or even the
forced values) to the sb module fail.  Back when this was a single
processor machine, but still running 2.4 kernel, a windoze
installation found the SB at the listed interface parameters.
   
   
Anyone have a solution?
   
Same problem without modules.conf settings, valid version of mod
utilities, a web search did not help,...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: obsolete code must die

[Colonel]

In list.kernel, you wrote:

Anyone concerned about the current size of the kernel source code? I am, and

No.  Since you are up to date with the latest in everything, I cannot
see why you would be concerned about a few megabytes in your gigabyte
drives.


i386, i486
The Pentium processor has been around since 1995. Support for these older

No.  Both of my cheap on-site systems for occasional access are 486s.
Why would I spend money for a system that is hardly ever used?


ISA bus, MCA bus, EISA bus
PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP,
CONFIG_ISAPNP, etc

No.  There are still plenty of unique ISA cards around.


MFM/RLL/XT/ESDI hard drive support
Does anyone still *have* an RLL drive that works? At the very least get rid

OK, I haven't seen one of these for nearly 10 years.


parallel/serial/game ports
More controversial to remove this, since they are *still* in pretty wide
use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts.

Send me the funds to replace my laser printers please.


a.out
Who needs it anymore. I love ELF.

OK, everything that I had in a.out was converted within a year of
ELF's introduction.


I really think doing a clean up is worthwhile. Maybe while looking for stuff

You left out all the old non-IDE CDROM drives.
 

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

Re: obsolete code must die

[Colonel]

In list.kernel, you wrote:

i think we are all missing the ball here: i am happy when i see driver
support for a piece of hardware that i have _NEVER_ heard of and at most
_ONE_ person uses it.  why?  it means more stuff works in linux.  we
dont need to defend how many people use hardware X.  if you have X, good
for you.  if not, you dont care, but at least good for linux as a whole.

Good Point!

lets stop fanning the flames and let this (Microsoft-using, as Rik
pointed out) troll die off.

Agreed, he made the filter already.  But it was good for some laughs,
checking a few cobwebs and I really didn't see flames.  Plus I got to
test my new mailing list archive.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

No Subject

[Colonel]

From: Colonel <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: ISA Soundblaster problem
Reply-to: [EMAIL PROTECTED]


The Maintainers list does not contain anyone for 2.4 Soundblaster
modules, so perhaps some one on the mailing list is aware of a
solution.  My ISA Soundblaster 16waveffects worked fine in kernel 2.2
with XMMS.  But I have never been successful in a varity of 2.4
kernels, the latest being 2.4.5-ac12.  This is what I know:

[DMESG]
isapnp: Scanning for PnP cards...
isapnp: Calling quirk for 01:00
isapnp: SB audio device quirk - increasing port range
isapnp: Card 'Creative SB16 PnP'
isapnp: 1 Plug & Play card detected total

}modprobe sb  
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: init_module: No such device
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: Hint: insmod errors can be caused 
by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod 
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o failed
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod sb failed


[/etc/modules.conf]
options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330


[DMESG}
Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
sb: No ISAPnP cards found, trying standard ones...
sb: dsp reset failed.


So it seems that PnP finds the card, but the connections (or even the
forced values) to the sb module fail.  Back when this was a single
processor machine, but still running 2.4 kernel, a windoze
installation found the SB at the listed interface parameters.


Anyone have a solution?

Same problem without modules.conf settings, valid version of mod
utilities, a web search did not help,...



TIA


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

No Subject

[Colonel]

From: Colonel [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: ISA Soundblaster problem
Reply-to: [EMAIL PROTECTED]


The Maintainers list does not contain anyone for 2.4 Soundblaster
modules, so perhaps some one on the mailing list is aware of a
solution.  My ISA Soundblaster 16waveffects worked fine in kernel 2.2
with XMMS.  But I have never been successful in a varity of 2.4
kernels, the latest being 2.4.5-ac12.  This is what I know:

[DMESG]
isapnp: Scanning for PnP cards...
isapnp: Calling quirk for 01:00
isapnp: SB audio device quirk - increasing port range
isapnp: Card 'Creative SB16 PnP'
isapnp: 1 Plug  Play card detected total

}modprobe sb  
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: init_module: No such device
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: Hint: insmod errors can be caused 
by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod 
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o failed
/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod sb failed


[/etc/modules.conf]
options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330


[DMESG}
Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996
sb: No ISAPnP cards found, trying standard ones...
sb: dsp reset failed.


So it seems that PnP finds the card, but the connections (or even the
forced values) to the sb module fail.  Back when this was a single
processor machine, but still running 2.4 kernel, a windoze
installation found the SB at the listed interface parameters.


Anyone have a solution?

Same problem without modules.conf settings, valid version of mod
utilities, a web search did not help,...



TIA


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

OOM stupidity

[Colonel]

When the OOM kills the process that I am currently composing within
(an active character stream), that is a MICROSOFT WINDOWS behavior.  
I don't care if it's hogging the machine, *I'M* using it!  That is the
point after all, isn't it?  A human sysadmin could kill my process
(and then I would have dealings with him), but the logic here is badly
flawed.

If this is what Linux will become in the 2.4 kernel, *FORGET IT*.
Swap was hardly filled up, and remember it's the 2xRAM swap size now!
Has Linux been too eager to accept recent windows converts (and prior
to their recovery from that brain damage) and lost it's sharp edge of
careful thought and tooling that was it's hallmark in the beginning??
Are the maintainers of this area too busy "protecting their turf" to
allow some options to the end user?  Seem like Linus better kick some
butt before it's too late.  Microsoft has been running a
disinformation campaign against Linux for awhile, but the current OOM
behavior could allow them to make a major capitalization against
Linux.

Just think of the Microsoft campaign :
"We don't pull the rug out from underneath you".

(Note to all those that will jump up and claim that Microsoft has
problems -- I see, you are saying because MS is faulty, it's OK that
Linux is faulty)

Where is a patch to allow the sensible OOM I had in prior kernels?
(cause this crap is getting pitched)



(kernel 2.4.4-pre6, not noticed in eariler kernels, but machine was
not that heavily used.  Hardware has been rock solid for years.  Load
at the time was trivial compared to 2.0 series kernels workload.)


ron

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

OOM stupidity

[Colonel]

When the OOM kills the process that I am currently composing within
(an active character stream), that is a MICROSOFT WINDOWS behavior.  
I don't care if it's hogging the machine, *I'M* using it!  That is the
point after all, isn't it?  A human sysadmin could kill my process
(and then I would have dealings with him), but the logic here is badly
flawed.

If this is what Linux will become in the 2.4 kernel, *FORGET IT*.
Swap was hardly filled up, and remember it's the 2xRAM swap size now!
Has Linux been too eager to accept recent windows converts (and prior
to their recovery from that brain damage) and lost it's sharp edge of
careful thought and tooling that was it's hallmark in the beginning??
Are the maintainers of this area too busy protecting their turf to
allow some options to the end user?  Seem like Linus better kick some
butt before it's too late.  Microsoft has been running a
disinformation campaign against Linux for awhile, but the current OOM
behavior could allow them to make a major capitalization against
Linux.

Just think of the Microsoft campaign :
We don't pull the rug out from underneath you.

(Note to all those that will jump up and claim that Microsoft has
problems -- I see, you are saying because MS is faulty, it's OK that
Linux is faulty)

Where is a patch to allow the sensible OOM I had in prior kernels?
(cause this crap is getting pitched)



(kernel 2.4.4-pre6, not noticed in eariler kernels, but machine was
not that heavily used.  Hardware has been rock solid for years.  Load
at the time was trivial compared to 2.0 series kernels workload.)


ron

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

Re: compile error 2.4.4pre6: inconsistent operand constraints in an

[Colonel]

In list.kernel, axel <[EMAIL PROTECTED]> wrote:
>
>How about correcting the needed gcc version in Documentation/Changes?


Linux, with up to date documention??  In your dreams perhaps.


>On Mon, 23 Apr 2001, Alan Cox wrote:
>
>> > after having had trouble with compilation due to old gcc version, i have
>> > updated to gcc 3.0 and received the following error:
>> 
>> 2.4.4pre6 only builds with gcc 2.96. If you apply the __builtin_expect fixes
>> it builds and runs fine with 2.95. Not tried egcs. The gcc 3.0 asm constraints
>> one I've yet to see a fix for.


BTW.  The above attitude was fostered by informing the Changes
maintainer that the recommended NFS userspace server was on the
exploits list (back in the 2.0 kernel days when knfs was new) and
getting a "I don't use that, so what" response.

...and the documentation continued to recommend an exploitable NFS
server... in short: you must cross-check to be sure, at least in linux
you have a few more options.


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

Compiled sound causes loss of scrollback console : 2.4.4-p6

[Colonel]

While tracking down a sound problem, I decided to compile in the
soundblaster rather than use modules.  It's been a long time since I
ran sound under linux, but that used to work fine.

I watched the reboot, noticed the usual isapnp stuff (part of problem)

...
PCI: Probing PCI hardware
Limiting direct PCI/PCI transfers.
Activating ISA DMA hang workarounds.
isapnp: Scanning for PnP cards...
isapnp: Calling quirk for 01:00
isapnp: SB audio device quirk - increasing port range
isapnp: Card 'Creative SB16 PnP'
isapnp: 1 Plug & Play card detected total
...

and then noticed that there were no soundblaster messages and tried to
scrollback to verify.  Pressing Shift-PageUp did absolutely nothing.

The only change was to move from modules to compiled for sound, OSS,
and soundblaster.  Booting the previous kernel(s) showed a working
scrollback.  2.4.4-pre6 compiled under gcc 2.95.3 20010315 release.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Compiled sound causes loss of scrollback console : 2.4.4-p6

[Colonel]

While tracking down a sound problem, I decided to compile in the
soundblaster rather than use modules.  It's been a long time since I
ran sound under linux, but that used to work fine.

I watched the reboot, noticed the usual isapnp stuff (part of problem)

...
PCI: Probing PCI hardware
Limiting direct PCI/PCI transfers.
Activating ISA DMA hang workarounds.
isapnp: Scanning for PnP cards...
isapnp: Calling quirk for 01:00
isapnp: SB audio device quirk - increasing port range
isapnp: Card 'Creative SB16 PnP'
isapnp: 1 Plug  Play card detected total
...

and then noticed that there were no soundblaster messages and tried to
scrollback to verify.  Pressing Shift-PageUp did absolutely nothing.

The only change was to move from modules to compiled for sound, OSS,
and soundblaster.  Booting the previous kernel(s) showed a working
scrollback.  2.4.4-pre6 compiled under gcc 2.95.3 20010315 release.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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-pre6 : THANKS! very snappy here [nt]

[Colonel]

NT = no text

but since you read it, system seems like it's running twice as fast

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

Re: rwsem.o undefined reference to __builtin_expect

[Colonel]

In list.kernel, you wrote:
>
>
>cannot compile 2.4.4-pre6. This may have been reported, but I
>haven't seen it.

There was a solution mentioned Saturday.


>rwsem.o(.text+0x30): undefined reference to `__builtin_expect'
>rwsem.o(.text+0x73): undefined reference to `__builtin_expect'
>make: *** [vmlinux] Error 1

in asm-alpha/compiler.h you will find a definition.  The above
solution created a new file (asm-i386/compiler.h) with the definition,
I just added it to rwsem.c.


BTW: 2.4.4-pre6 is the fastest kernel yet!  YMMV

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

Re: rwsem.o undefined reference to __builtin_expect

[Colonel]

In list.kernel, you wrote:


cannot compile 2.4.4-pre6. This may have been reported, but I
haven't seen it.

There was a solution mentioned Saturday.


rwsem.o(.text+0x30): undefined reference to `__builtin_expect'
rwsem.o(.text+0x73): undefined reference to `__builtin_expect'
make: *** [vmlinux] Error 1

in asm-alpha/compiler.h you will find a definition.  The above
solution created a new file (asm-i386/compiler.h) with the definition,
I just added it to rwsem.c.


BTW: 2.4.4-pre6 is the fastest kernel yet!  YMMV

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

Re: fsck, raid reconstruction & bad bad 2.4.3

[Colonel]

In list.kernel, linas wrote:
>
>First problem:  In kernel-2.4.2 and earlier, if the machine is not cleanly
>shut down, then upon reboot, RAID reconstruction is automatically started.
>(For RAID-1, this more-or-less ammounts to copying the entire contents
>of one disk partition on one disk to another).   The reconstruction
>code seems to be clever: it will try to use the full bandwidth when
>the system is idle, and it will throttle back when busy.  It will
>only throttle back so far: it tries to maintain at least a minimum amount
>of work going, in order to gaurentee forward progress even on a busy system.

And it works great!

>The problem:  this dramatically slows fsck after an unclean shut-down.
>You can hear the drives machine-gunning.  I haven't stop-watch timed it,
>but its on the order of 5x slower to fsck a raid partition when there's
>reconstruction going on, then when the raid thinks its clean.  This
>makes unclean reboots quite painful.

Since the alternative is to sit there and do NOTHING until the
reconstruction is complete, ala Solaris 2.5, it's WONDERFUL the way it
is.  This change was extensively discussed on the raid mailing list a
couple of years ago.  You can look it up for review.

>(There is no config file to disable/alter this .. no work-around that I
>know of ..)

You can't be serious.  Go sit down and think about what's going on.


>
>The second problem: oparallelizing fsck doesn't realize that different
>/dev/md raid volumes are on the same physical disks, and thus tries
>to parallelize  again slowing things down.   There is a work-around,
>modify /etc/fstab to set the rder of fsck's. However, I doubt the HOWTO
>really gets into this   it would be nice to get fsck to 'do the
>right thing'.

You probably have your fstab incorrectly setup.


#> In particular, how does fsck deal with md devices? It parallelizes
#> itself for multiple disks, but if the volumes are all actually striped 
#> over the same disks, fsck will perform better if it's serial.
#
#The "pass" field in /etc/fstab is for exactly this: fsck -a will
#serialise devices with different pass numbers.  Pass==1 is for root,
#pass==2 is for normal devices which fsck knows how to serialise.  If you
#want to force serialisation on md devices, use larger pass numbers.


Do a little work, it won't hurt you.  Fsck should not (and may not be
able to) decode metadevice structures.


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

Re: fsck, raid reconstruction bad bad 2.4.3

[Colonel]

In list.kernel, linas wrote:

First problem:  In kernel-2.4.2 and earlier, if the machine is not cleanly
shut down, then upon reboot, RAID reconstruction is automatically started.
(For RAID-1, this more-or-less ammounts to copying the entire contents
of one disk partition on one disk to another).   The reconstruction
code seems to be clever: it will try to use the full bandwidth when
the system is idle, and it will throttle back when busy.  It will
only throttle back so far: it tries to maintain at least a minimum amount
of work going, in order to gaurentee forward progress even on a busy system.

And it works great!

The problem:  this dramatically slows fsck after an unclean shut-down.
You can hear the drives machine-gunning.  I haven't stop-watch timed it,
but its on the order of 5x slower to fsck a raid partition when there's
reconstruction going on, then when the raid thinks its clean.  This
makes unclean reboots quite painful.

Since the alternative is to sit there and do NOTHING until the
reconstruction is complete, ala Solaris 2.5, it's WONDERFUL the way it
is.  This change was extensively discussed on the raid mailing list a
couple of years ago.  You can look it up for review.

(There is no config file to disable/alter this .. no work-around that I
know of ..)

You can't be serious.  Go sit down and think about what's going on.



The second problem: oparallelizing fsck doesn't realize that different
/dev/md raid volumes are on the same physical disks, and thus tries
to parallelize  again slowing things down.   There is a work-around,
modify /etc/fstab to set the rder of fsck's. However, I doubt the HOWTO
really gets into this   it would be nice to get fsck to 'do the
right thing'.

You probably have your fstab incorrectly setup.

snip
# In particular, how does fsck deal with md devices? It parallelizes
# itself for multiple disks, but if the volumes are all actually striped 
# over the same disks, fsck will perform better if it's serial.
#
#The "pass" field in /etc/fstab is for exactly this: fsck -a will
#serialise devices with different pass numbers.  Pass==1 is for root,
#pass==2 is for normal devices which fsck knows how to serialise.  If you
#want to force serialisation on md devices, use larger pass numbers.
/snip

Do a little work, it won't hurt you.  Fsck should not (and may not be
able to) decode metadevice structures.


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

Re: goodbye

[Colonel]

In list.kernel, you wrote:
>
>On Tue, Apr 03, 2001 at 06:14:33PM -0700, Michael Peddemors wrote:
>> I think that this is one list where we have to keep the ability to post
>> from individuals separate from the need to make sure that their ISP or
>> company is compliant to a set a of rules..  The LKML can't toe the
>> strictest of lines, without loosing some possibly valuable
>> contributors..
>
>   Well, comparing how much spam goes thru linux-mm vs. linux-kernel,
>   I would say our methods are fairly effective.

A stupid measure, since you cannot determine what was rejected, i.e. how
many babies you threw out with the bathwater.

>   The incentive behind the DUL is to force users not to post
>   straight out to the world, but to use their ISP's servers
>   for outbound email --- normal M$ users do that, after all.


Some ISPs rely on crap software & OS to process email, and have other
bad habits besides.  Censorship usually does more bad than good
(especially since dealing with 80% of the spam is trivial for
procmail), as has been pointed out in this case.  The stupidity of the
this approach is well shown by the email-blacklist groups blacklisting
each other, I would think that lkml had more brains.

Controlling email is a power game, where you set yourself up as a tin
god and proclaim that you alone know what is safe for the "dumb"
masses to read.  Perhaps the lkml sheep will abide by such control, but
I would think that 'free software' would have 'free discussions'.


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

Re: goodbye

[Colonel]

In list.kernel, you wrote:

On Tue, Apr 03, 2001 at 06:14:33PM -0700, Michael Peddemors wrote:
 I think that this is one list where we have to keep the ability to post
 from individuals separate from the need to make sure that their ISP or
 company is compliant to a set a of rules..  The LKML can't toe the
 strictest of lines, without loosing some possibly valuable
 contributors..

   Well, comparing how much spam goes thru linux-mm vs. linux-kernel,
   I would say our methods are fairly effective.

A stupid measure, since you cannot determine what was rejected, i.e. how
many babies you threw out with the bathwater.

   The incentive behind the DUL is to force users not to post
   straight out to the world, but to use their ISP's servers
   for outbound email --- normal M$ users do that, after all.


Some ISPs rely on crap software  OS to process email, and have other
bad habits besides.  Censorship usually does more bad than good
(especially since dealing with 80% of the spam is trivial for
procmail), as has been pointed out in this case.  The stupidity of the
this approach is well shown by the email-blacklist groups blacklisting
each other, I would think that lkml had more brains.

Controlling email is a power game, where you set yourself up as a tin
god and proclaim that you alone know what is safe for the "dumb"
masses to read.  Perhaps the lkml sheep will abide by such control, but
I would think that 'free software' would have 'free discussions'.


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

Re: Stuck: What to do with solid locks?

[Colonel]

In kernel.list, you wrote:
>
>Oh, I realize this.  I don't mind and even expect the occational crash
>right now in the 2.4.x series, but the frequency of these crashes fall

Well, you say this, but
...more whinny post deleted...

>to begin to help fix this problem (or these problems).

Twice your tone plays different from your words.  A scan of lkml
should have shown you that your problem is not a major problem, it's
far more likely to be unique than general.

- ---

1) try a different distribution, RH is bleeding edge at times and the
problems may not be entirely within the kernel.  For example,
Slackware-current is a base (without any additions it runs a 2.4
kernel) I've used with 4 machines now, and the only problem was the
loopback fs hang of a month ago.

2) remove drivers & hardware goodies to see if stability improves.
change your typical application load to see what happens.  I actually
do this the other way, run a simple kernel and then add to it.

3) there are a lot of 2.4 kernels, over 40 variants, look thru the
ChangeLogs, maybe your hardware is mentioned someplace.  try them to
see if stability improves.


In short, try the reduce the possible areas for a bug, ideally getting
to a point where you can state : 2.4.X-Y with AAA locks while 2.4.X-Y
without AAA does not lock.  That will bring more attention.

oh, and

4) boot into your last working kernel when you want to accomplish
something.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Stuck: What to do with solid locks?

[Colonel]

In kernel.list, you wrote:

Oh, I realize this.  I don't mind and even expect the occational crash
right now in the 2.4.x series, but the frequency of these crashes fall

Well, you say this, but
...more whinny post deleted...

to begin to help fix this problem (or these problems).

Twice your tone plays different from your words.  A scan of lkml
should have shown you that your problem is not a major problem, it's
far more likely to be unique than general.

- ---

1) try a different distribution, RH is bleeding edge at times and the
problems may not be entirely within the kernel.  For example,
Slackware-current is a base (without any additions it runs a 2.4
kernel) I've used with 4 machines now, and the only problem was the
loopback fs hang of a month ago.

2) remove drivers  hardware goodies to see if stability improves.
change your typical application load to see what happens.  I actually
do this the other way, run a simple kernel and then add to it.

3) there are a lot of 2.4 kernels, over 40 variants, look thru the
ChangeLogs, maybe your hardware is mentioned someplace.  try them to
see if stability improves.


In short, try the reduce the possible areas for a bug, ideally getting
to a point where you can state : 2.4.X-Y with AAA locks while 2.4.X-Y
without AAA does not lock.  That will bring more attention.

oh, and

4) boot into your last working kernel when you want to accomplish
something.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [RESEND] update chipsfb driver

[Colonel]

> Linus,

> At present, drivers/video/chipsfb.c can only be used on PPC, and it
> doesn't compile even on PPC.  The patch below makes it compile, and
> by changing it to use the generic inb/outb, means that there is at
> least a chance it can be used on other platforms.  The patch is
> against 2.4.3-pre7, could you apply it please?   
>  

I have an old Planar wall mount with Chips & Tech video, powered by a
T.I. 486DX100 (the BIOS is 7 years old).  I originally bought it to
use the frame buffer in a portable application, and this patch is the
FIRST time I've ever obtained an image.  Thanks!

The colormap is wrong, but at least I have some sort of working device
now.  I shelved the project over a year ago, what's a good site to
come up to speed on?

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

[PATCH] [RESEND] update chipsfb driver

[Colonel]

 Linus,

 At present, drivers/video/chipsfb.c can only be used on PPC, and it
 doesn't compile even on PPC.  The patch below makes it compile, and
 by changing it to use the generic inb/outb, means that there is at
 least a chance it can be used on other platforms.  The patch is
 against 2.4.3-pre7, could you apply it please?   
  

I have an old Planar wall mount with Chips  Tech video, powered by a
T.I. 486DX100 (the BIOS is 7 years old).  I originally bought it to
use the frame buffer in a portable application, and this patch is the
FIRST time I've ever obtained an image.  Thanks!

The colormap is wrong, but at least I have some sort of working device
now.  I shelved the project over a year ago, what's a good site to
come up to speed on?

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

Re: Loop dev & 2.4.2

[Colonel]

In list.kernel.owner, you wrote:
>
>I want to report a constant problem I'm having with the loopback block driver
>in the new releases of the 2.4.x series of the Linux kernel.

Pick up the loop patches from Axboe at :

*.kernel.org/pub/linux/kernel/people/axboe/patches/

I solved all my problems with 2.4.2-pre4 and loop6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Loop dev 2.4.2

[Colonel]

In list.kernel.owner, you wrote:

I want to report a constant problem I'm having with the loopback block driver
in the new releases of the 2.4.x series of the Linux kernel.

Pick up the loop patches from Axboe at :

*.kernel.org/pub/linux/kernel/people/axboe/patches/

I solved all my problems with 2.4.2-pre4 and loop6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Colonel]

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

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

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


If you caught the end of the thread, james (the initial poster) added
memory, had no problems, removed the extra memory and still had no
problems.  His spare memory is greater than my memory total.  I too
cannot repeat the freeze.  It makes me wonder if there is some
parameter updating in the kernel somehow.

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

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

[Colonel]

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

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

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


If you caught the end of the thread, james (the initial poster) added
memory, had no problems, removed the extra memory and still had no
problems.  His spare memory is greater than my memory total.  I too
cannot repeat the freeze.  It makes me wonder if there is some
parameter updating in the kernel somehow.

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

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

[Colonel]

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

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

   /RogerL

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


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

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

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

[Colonel]

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

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

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


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


[1]  Since I decided to try to catch up on kernels, I had just grabbed
-ac18, cd to ~linux and run "rm -r *" via an ssh connection.  In a
second connection, I tried a simple "dmesg" and waited over a minute
for results (long enough to log in directly on the box and bring up
top) followed by loading emacs for ftp transfers from kernel.org,
which again 'went to sleep'.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Colonel]

   Sender: [EMAIL PROTECTED]
   Date: Tue, 20 Feb 2001 11:32:19 -0600
   From: "James A. Pattie" <[EMAIL PROTECTED]>
   X-Accept-Language: en
   Content-Type: text/plain; charset=us-ascii

   Colonel wrote:

   > In clouddancer.list.kernel.owner, you wrote:
   > >
   > >I'm not subscribed to the kernel mailing list, so please cc any replies
   > >to me.
   > >
   > >I'm building a firewall on a P133 with 48 MB of memory using RH 7.0,
   > >latest updates, etc. and kernel 2.4.1.
   > >I've built a customized install of RH (~200MB)  which I untar onto the
   > >system after building my raid arrays, etc. via a Rescue CD which I
   > >created using Timo's Rescue CD project.  The booting kernel is
   > >2.4.1-ac10, no networking, raid compiled in but raid1 as a module
   >
   > Hmm, raid as a module was always a Bad Idea(tm) in the 2.2 "alpha"
   > raid (which was misnamed and is 2.4 raid).  I suggest you change that
   > and update, as I had no problems with 2.4.2-pre2/3, nor have any been
   > posted to the raid list.

   I just tried with 2.4.1-ac14, raid and raid1 compiled in and it did the
   same thing.  I'm going to try to compile reiserfs in (if I have enough room
   to still fit the kernel on the floppy with it's initial ramdisk, etc.) and
   see what that does.


Hmm.  reiserfs is probably OK as a module.  ac14 is 5 versions
'behind'.  I'd start looking for a distribution problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Colonel]

   Sender: [EMAIL PROTECTED]
   Date: Tue, 20 Feb 2001 11:32:19 -0600
   From: "James A. Pattie" [EMAIL PROTECTED]
   X-Accept-Language: en
   Content-Type: text/plain; charset=us-ascii

   Colonel wrote:

In clouddancer.list.kernel.owner, you wrote:

I'm not subscribed to the kernel mailing list, so please cc any replies
to me.

I'm building a firewall on a P133 with 48 MB of memory using RH 7.0,
latest updates, etc. and kernel 2.4.1.
I've built a customized install of RH (~200MB)  which I untar onto the
system after building my raid arrays, etc. via a Rescue CD which I
created using Timo's Rescue CD project.  The booting kernel is
2.4.1-ac10, no networking, raid compiled in but raid1 as a module
   
Hmm, raid as a module was always a Bad Idea(tm) in the 2.2 "alpha"
raid (which was misnamed and is 2.4 raid).  I suggest you change that
and update, as I had no problems with 2.4.2-pre2/3, nor have any been
posted to the raid list.

   I just tried with 2.4.1-ac14, raid and raid1 compiled in and it did the
   same thing.  I'm going to try to compile reiserfs in (if I have enough room
   to still fit the kernel on the floppy with it's initial ramdisk, etc.) and
   see what that does.


Hmm.  reiserfs is probably OK as a module.  ac14 is 5 versions
'behind'.  I'd start looking for a distribution problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Colonel]

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

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

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


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


[1]  Since I decided to try to catch up on kernels, I had just grabbed
-ac18, cd to ~linux and run "rm -r *" via an ssh connection.  In a
second connection, I tried a simple "dmesg" and waited over a minute
for results (long enough to log in directly on the box and bring up
top) followed by loading emacs for ftp transfers from kernel.org,
which again 'went to sleep'.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Colonel]

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

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

   /RogerL

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


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

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

2.4.1 loopback FS partial fix

[Colonel]

For the other list readers with problems:

I used patch 2.4.2-pre2  (not pre3) 

plus axboe's loop-4 patch  (in the people directory).

  [EMAIL PROTECTED]:/pub/linux/kernel/people/axboe/patches/2.4.2-pre1

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

2.4.1 loopback FS partial fix

[Colonel]

For the other list readers with problems:

I used patch 2.4.2-pre2  (not pre3) 

plus axboe's loop-4 patch  (in the people directory).

  [EMAIL PROTECTED]:/pub/linux/kernel/people/axboe/patches/2.4.2-pre1

It solves most problems here.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.2-pre2(&3) loopback fs hang

[Colonel]

>mount -o loop=/dev/loop1 net.i /var/mnt/image/

ends up in an uninterruptable sleep state (system cannot umount /
during shutdown).

The test system is a 100MHz 486 Planar wall mount, same problem with
or without modules.  The proper fs support is present in the kernel,
while CONFIG_DEVFS_FS is not set.  The linux distribution base was a
fresh slackware-current, it meets all requirements mentioned in
linux/Documentation/Changes.  Everything else tested has worked fine
so far, the 2.2.18 kernel did not have this loopback problem.


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

2.4.2-pre2(3) loopback fs hang

[Colonel]

mount -o loop=/dev/loop1 net.i /var/mnt/image/

ends up in an uninterruptable sleep state (system cannot umount /
during shutdown).

The test system is a 100MHz 486 Planar wall mount, same problem with
or without modules.  The proper fs support is present in the kernel,
while CONFIG_DEVFS_FS is not set.  The linux distribution base was a
fresh slackware-current, it meets all requirements mentioned in
linux/Documentation/Changes.  Everything else tested has worked fine
so far, the 2.2.18 kernel did not have this loopback problem.


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