Re: A Possible 2.5 Idea, maybe?

2001-06-29 Thread Brent D. Norris

> Thats why we have /proc/... To echo things into it.

I don't know of a proc entry that lets the user tell the VM not to cache
as much or use swap in a different manner.

> Several kernel threads are hard to maintain, hard to evolve, hard to
> bugfix, modify patches, etc. Mainly, we should have a single kernel that
> can be tuned to fit people's needs.

I agree that keeping several threads would be difficult, but is there not
a way to have certain values plugged into the code for something like
cache pressure before swapping, or extended boot messages instead of a
quiet boot?  These values would be dependant on the config options that
were selected in the config.  I am not talking about forking the kernel.
I am instead talking about a process to select a different concept that
the same kernel runs under and have this concept selected at compile time.

> IMO, the Linux distributions out there should configure the kernel based
> on the type of system the (l[inux])user wants. Those who have the balls to
> compile their own system should know such things anyway. The rest, better
> rely on the distribution default and/or ask around and get some more
> info [the kernel configuration help is explicit enough anyway, given a
> decent level of common sense is used].

This leaves several people out in the rain though.  First how would a
distro make a system that works well for the desktop users if the kernel
is designed to work well on servers?  Also I should be able to run debian
on my desktop if I want without having to suffer through interactivity
issues, because debian builds their distros for servers and has most of
the hard drives cached.  Also I know several people that recompile kernels
and such, but have no clue as the process to go through to optimize it for
their particular setup.  If people are hoping that linux will move into
other markets besides servers then you cannot have the attitude that
everyone has to suffer with a) what the distros give them or b) be come
fluent enought in kernel programming and desgin to be able to edit the
code so that it works better for them.

Brent Norris

Executive Advisor -- WKU-Linux

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



A Possible 2.5 Idea, maybe?

2001-06-29 Thread Brent D. Norris

Recently one more than one subject there have been comments along the
lines of, "Do x, y and z because it would be great on desktops" and then
someone else will say "NO! becausing doing x, y, and z will make servers
run slow."  Then as a final note someone else will say "Do y and z, but
not x, because that will make my handheld linux project a lot better."
Now whatever is eventually decided in each discusion, normally one
group/user walks away feeling they are getting the shortend of the stick.

Now many of these things are configurable.  If it is the amount of
messages that the boot of the kernel makes or even the "motivation" and
actions that the VM takes.  It seems possible to configure the kernel so
that it would work optimally for each of the groups.  The problem is that
the code in these sections is having to work in too different of
situations.  Example : The VM is now somewhat more tweaked for servers
than it was previously.  Many people were concerned about the
"interactivity" of it.  Now it seems that it would be possible to change
the vm code so that it worked better for desktop users, but the
maintainers are not eager to do that because it would slow linux down in
the server market.

This all stems from one problem, which is a really great problem to have
if you must have a problem.  Linux is spreading to largely different
kinds of machines with many different purposes.  Microsoft solved this
problem by having several different kernels (NT code base for servers, 9x
code base for desktops, CE code base for handhelds), and this is somewhat
like what the "forking is a good thing" messge recommended for linux.  I
disagree with that concept though.  It is easy to see the trouble
microsoft is having with that and now they are trying to slowly merge the
two (NT,9x) together.

Instead of forking the kernel or catering only to one group, instead why
not try this:  Using the new CML2 tools and rulesets, make it possible to
have the kernel configured for the type of job it will be doing?  Just
like CML2 asks our CPU type (i386, alpha, althon ...) and then goes out
and configures options for that, have it ask people "Is your machine a
server, workstation, embedded/handheld?" and configure things in the
kernel like the VM, bootup and others to optimize it for that job type?

Brent Norris

Executive Advisor -- WKU-Linux

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



A Possible 2.5 Idea, maybe?

2001-06-29 Thread Brent D. Norris

Recently one more than one subject there have been comments along the
lines of, Do x, y and z because it would be great on desktops and then
someone else will say NO! becausing doing x, y, and z will make servers
run slow.  Then as a final note someone else will say Do y and z, but
not x, because that will make my handheld linux project a lot better.
Now whatever is eventually decided in each discusion, normally one
group/user walks away feeling they are getting the shortend of the stick.

Now many of these things are configurable.  If it is the amount of
messages that the boot of the kernel makes or even the motivation and
actions that the VM takes.  It seems possible to configure the kernel so
that it would work optimally for each of the groups.  The problem is that
the code in these sections is having to work in too different of
situations.  Example : The VM is now somewhat more tweaked for servers
than it was previously.  Many people were concerned about the
interactivity of it.  Now it seems that it would be possible to change
the vm code so that it worked better for desktop users, but the
maintainers are not eager to do that because it would slow linux down in
the server market.

This all stems from one problem, which is a really great problem to have
if you must have a problem.  Linux is spreading to largely different
kinds of machines with many different purposes.  Microsoft solved this
problem by having several different kernels (NT code base for servers, 9x
code base for desktops, CE code base for handhelds), and this is somewhat
like what the forking is a good thing messge recommended for linux.  I
disagree with that concept though.  It is easy to see the trouble
microsoft is having with that and now they are trying to slowly merge the
two (NT,9x) together.

Instead of forking the kernel or catering only to one group, instead why
not try this:  Using the new CML2 tools and rulesets, make it possible to
have the kernel configured for the type of job it will be doing?  Just
like CML2 asks our CPU type (i386, alpha, althon ...) and then goes out
and configures options for that, have it ask people Is your machine a
server, workstation, embedded/handheld? and configure things in the
kernel like the VM, bootup and others to optimize it for that job type?

Brent Norris

Executive Advisor -- WKU-Linux

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 Possible 2.5 Idea, maybe?

2001-06-29 Thread Brent D. Norris

 Thats why we have /proc/... To echo things into it.

I don't know of a proc entry that lets the user tell the VM not to cache
as much or use swap in a different manner.

 Several kernel threads are hard to maintain, hard to evolve, hard to
 bugfix, modify patches, etc. Mainly, we should have a single kernel that
 can be tuned to fit people's needs.

I agree that keeping several threads would be difficult, but is there not
a way to have certain values plugged into the code for something like
cache pressure before swapping, or extended boot messages instead of a
quiet boot?  These values would be dependant on the config options that
were selected in the config.  I am not talking about forking the kernel.
I am instead talking about a process to select a different concept that
the same kernel runs under and have this concept selected at compile time.

 IMO, the Linux distributions out there should configure the kernel based
 on the type of system the (l[inux])user wants. Those who have the balls to
 compile their own system should know such things anyway. The rest, better
 rely on the distribution default and/or ask around and get some more
 info [the kernel configuration help is explicit enough anyway, given a
 decent level of common sense is used].

This leaves several people out in the rain though.  First how would a
distro make a system that works well for the desktop users if the kernel
is designed to work well on servers?  Also I should be able to run debian
on my desktop if I want without having to suffer through interactivity
issues, because debian builds their distros for servers and has most of
the hard drives cached.  Also I know several people that recompile kernels
and such, but have no clue as the process to go through to optimize it for
their particular setup.  If people are hoping that linux will move into
other markets besides servers then you cannot have the attitude that
everyone has to suffer with a) what the distros give them or b) be come
fluent enought in kernel programming and desgin to be able to edit the
code so that it works better for them.

Brent Norris

Executive Advisor -- WKU-Linux

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: One more ZDNet article with BillG hammering Linux and OpenSource.

2001-06-21 Thread Brent D. Norris

> simple source access. I don't know that anyone has ever asked for the source
> code for Word. If they did, we would give it to them. But it's not a typical
> request.

So who wants to go ask for the source code to word then?  I mean we have
Bill's word that they will give it to us.

Brent Norris

Executive Advisor -- WKU-Linux

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: One more ZDNet article with BillG hammering Linux and OpenSource.

2001-06-21 Thread Brent D. Norris

 simple source access. I don't know that anyone has ever asked for the source
 code for Word. If they did, we would give it to them. But it's not a typical
 request.

So who wants to go ask for the source code to word then?  I mean we have
Bill's word that they will give it to us.

Brent Norris

Executive Advisor -- WKU-Linux

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



[OT] Re: 3com Driver and the 3XP Processor

2001-06-14 Thread Brent D. Norris

Insteresting that this thread fell into this.  I just had one of those
cards that came across my desk phreak out.  It was 2 days old and placed
in a win2k server.  Last night it started dumping errors about firmware
and bad microcde.
Have yet to test it out on another machine, but I beleive the card went
bad.  first 3com I have had go bad and first card I have ever had go bad
inside of 2 days :)

> I've installed several thousand 3com cards of variousages and types.
> I've had less than 20 bad cards.
>   Nick

Brent Norris
Executive Advisor -- WKU-Linux

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: 3com Driver and the 3XP Processor

2001-06-14 Thread Brent D. Norris

> Now, if the NIC were to integrate with OpenSSL and offload some of THAT
> donkey work... Just offloading DES isn't terribly useful, as Pavel says:
> apart from anything else, DES is a bit elderly now - SSH using 3DES or
> Blowfish etc... How dedicated is this card? Could it be used to offload
> other work?

Sorry my bad it is 3DES that they have on it, but I don't know how
in-grained it is in it.  Like I sad it just floated across my desk a few
days ago and it sounded like a cool bit of hardware.

Brent Norris

Executive Advisor -- WKU-Linux

System Administrator -- WKU-Center for Biodiversity
Best Mechanical

W: 270-745-8864
H: 270-563-9226

"The problem with the Linux learning curve is that it is _so_ steep once
 at the top you can't see the people at the bottom"  --Doug Hagan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: 3com Driver and the 3XP Processor

2001-06-14 Thread Brent D. Norris

 Now, if the NIC were to integrate with OpenSSL and offload some of THAT
 donkey work... Just offloading DES isn't terribly useful, as Pavel says:
 apart from anything else, DES is a bit elderly now - SSH using 3DES or
 Blowfish etc... How dedicated is this card? Could it be used to offload
 other work?

Sorry my bad it is 3DES that they have on it, but I don't know how
in-grained it is in it.  Like I sad it just floated across my desk a few
days ago and it sounded like a cool bit of hardware.

Brent Norris

Executive Advisor -- WKU-Linux

System Administrator -- WKU-Center for Biodiversity
Best Mechanical

W: 270-745-8864
H: 270-563-9226

The problem with the Linux learning curve is that it is _so_ steep once
 at the top you can't see the people at the bottom  --Doug Hagan

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



[OT] Re: 3com Driver and the 3XP Processor

2001-06-14 Thread Brent D. Norris

Insteresting that this thread fell into this.  I just had one of those
cards that came across my desk phreak out.  It was 2 days old and placed
in a win2k server.  Last night it started dumping errors about firmware
and bad microcde.
Have yet to test it out on another machine, but I beleive the card went
bad.  first 3com I have had go bad and first card I have ever had go bad
inside of 2 days :)

 I've installed several thousand 3com cards of variousages and types.
 I've had less than 20 bad cards.
   Nick

Brent Norris
Executive Advisor -- WKU-Linux

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: 3com Driver and the 3XP Processor

2001-06-11 Thread Brent D. Norris

Thanks to Kip for clarifying why Linux doesn't use this feature, but now I
wonder why you beleive this?


[EMAIL PROTECTED] wrote:

> > hype it does DES without using the CPU, does linux take advantage of that?
>
> no, as far as I've heard.  and I wouldn't expect it to either.
> further, it's highly questionable whether the feature makes sense...

If they release the API for it why would you not expect it to use it, and
why would getting a complex computation and encryption off of the CPU to a
more specialized hardware not make sense?

Brent Norris

Executive Advisor -- WKU-Linux




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: 3com Driver and the 3XP Processor

2001-06-11 Thread Brent D. Norris

I thought 3com was pretty friendly to the Linux Community, was that a
misconception?

> It can't because 3com hasn't implemented in the driver and they won't
> publish the interface.
>   -Kip
>

Brent

Executive Advisor -- WKU-Linux


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



3com Driver and the 3XP Processor

2001-06-11 Thread Brent D. Norris

I just had one of the "3com Etherlink 10/100 PCI NIC with 3XP processor"
float accross my desk, I was wondering how much the linux kernel uses the
3xp processor for its encryption offloading and such.  According to the
hype it does DES without using the CPU, does linux take advantage of that?

Brent Norris

Executive Advisor -- WKU-Linux

System Administrator -- WKU-Center for Biodiversity
Best Mechanical

W: 270-745-8864
H: 270-563-9226

"The problem with the Linux learning curve is that it is _so_ steep once
 at the top you can't see the people at the bottom"  --Doug Hagan

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



3com Driver and the 3XP Processor

2001-06-11 Thread Brent D. Norris

I just had one of the 3com Etherlink 10/100 PCI NIC with 3XP processor
float accross my desk, I was wondering how much the linux kernel uses the
3xp processor for its encryption offloading and such.  According to the
hype it does DES without using the CPU, does linux take advantage of that?

Brent Norris

Executive Advisor -- WKU-Linux

System Administrator -- WKU-Center for Biodiversity
Best Mechanical

W: 270-745-8864
H: 270-563-9226

The problem with the Linux learning curve is that it is _so_ steep once
 at the top you can't see the people at the bottom  --Doug Hagan

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: 3com Driver and the 3XP Processor

2001-06-11 Thread Brent D. Norris

I thought 3com was pretty friendly to the Linux Community, was that a
misconception?

 It can't because 3com hasn't implemented in the driver and they won't
 publish the interface.
   -Kip


Brent

Executive Advisor -- WKU-Linux


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: 3com Driver and the 3XP Processor

2001-06-11 Thread Brent D. Norris

Thanks to Kip for clarifying why Linux doesn't use this feature, but now I
wonder why you beleive this?


[EMAIL PROTECTED] wrote:

  hype it does DES without using the CPU, does linux take advantage of that?

 no, as far as I've heard.  and I wouldn't expect it to either.
 further, it's highly questionable whether the feature makes sense...

If they release the API for it why would you not expect it to use it, and
why would getting a complex computation and encryption off of the CPU to a
more specialized hardware not make sense?

Brent Norris

Executive Advisor -- WKU-Linux




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

2001-05-23 Thread Brent D. Norris

> > sometimes one of my servers doesn't boot correctly. Lilo reads the
> > kernel-image, but doesn't decompress it. So the system won't
> > continue booting.
> >
> > Looks like:
> > Loading linux...
> > (at this point the machine freezes)
>
> Our experience of this has been with suspect hardware.  It was our first
> (pre-release) P4 system, so we puzzled over it for a short while; later
> testing on other P4 systems showed no such problem.

My machines have produced this result with memory sticks that needed to be
reseated.  Might make sure everything is seated down and all the contacts
are clean.

Brent Norris

Executive Advisor -- WKU-Linux

System Administrator -- WKU-Center for Biodiversity
Best Mechanical


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

2001-05-23 Thread Brent D. Norris

  sometimes one of my servers doesn't boot correctly. Lilo reads the
  kernel-image, but doesn't decompress it. So the system won't
  continue booting.
 
  Looks like:
  Loading linux...
  (at this point the machine freezes)

 Our experience of this has been with suspect hardware.  It was our first
 (pre-release) P4 system, so we puzzled over it for a short while; later
 testing on other P4 systems showed no such problem.

My machines have produced this result with memory sticks that needed to be
reseated.  Might make sure everything is seated down and all the contacts
are clean.

Brent Norris

Executive Advisor -- WKU-Linux

System Administrator -- WKU-Center for Biodiversity
Best Mechanical


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: ECN is on!

2001-05-22 Thread Brent D. Norris

> I veto, the whole point of moving to ECN was to make a statement and
> get people to fix their kit.
>
Isn't this a problem though because the messge saying that ECN was enabled
was set after ECN was enabled?  Thus these people have no idea what is
going on and they probably won't know what to fix until they do.

> We will remove these people, that's all.
>
> Later,
> David S. Miller
> [EMAIL PROTECTED]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Brent Norris

Executive Advisor -- WKU-Linux

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

2001-05-22 Thread Brent D. Norris

 I veto, the whole point of moving to ECN was to make a statement and
 get people to fix their kit.

Isn't this a problem though because the messge saying that ECN was enabled
was set after ECN was enabled?  Thus these people have no idea what is
going on and they probably won't know what to fix until they do.

 We will remove these people, that's all.

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


Brent Norris

Executive Advisor -- WKU-Linux

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [kbuild-devel] Re: CML2 design philosophy heads-up

2001-05-21 Thread Brent D. Norris

> #2 is fixed by rewriting tools in C

didn't Eric say that this has stalled though?  Is that not the case?

Brent Norris

Executive Advisor -- WKU-Linux

System Administrator -- WKU-Center for Biodiversity
Best Mechanical

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kbuild-devel] Re: CML2 design philosophy heads-up

2001-05-21 Thread Brent D. Norris

 #2 is fixed by rewriting tools in C

didn't Eric say that this has stalled though?  Is that not the case?

Brent Norris

Executive Advisor -- WKU-Linux

System Administrator -- WKU-Center for Biodiversity
Best Mechanical

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Sound issues with m805lr motheboard

2001-03-22 Thread Brent D. Norris

> It might be interesting to strace the realserver startup
> both under 2.2 and 2.4 -

Here you go.  Also sorry Alan for such a goofy email earlier.  Does anyone
have any ideas on the sound driver issue?

Brent Norris



execve("Bin/rmserver", ["Bin/rmserver", "rmserver.cfg"], [/* 23 vars */]) = 0
uname({sys="Linux", node="linux-wolf", ...}) = 0
brk(0)  = 0x823318c
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/lib/libNoVersion.so.1", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0755, st_size=15967, ...}) = 0
close(4)= 0
open("/lib/libNoVersion.so.1", O_RDONLY) = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\10"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=15967, ...}) = 0
old_mmap(NULL, 7272, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40018000
mprotect(0x40019000, 3176, PROT_NONE)   = 0
old_mmap(0x40019000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0) = 
0x40019000
close(4)= 0
open("/etc/ld.so.cache", O_RDONLY)  = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=23137, ...}) = 0
old_mmap(NULL, 23137, PROT_READ, MAP_PRIVATE, 4, 0) = 0x4001a000
close(4)= 0
open("/lib/libdl.so.2", O_RDONLY)   = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\34\0\000"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=60598, ...}) = 0
old_mmap(NULL, 12244, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x4002
mprotect(0x40022000, 4052, PROT_NONE)   = 0
old_mmap(0x40022000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x1000) = 
0x40022000
close(4)= 0
open("/usr/lib/libstdc++.so.2.8", O_RDONLY) = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\364\204"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=375773, ...}) = 0
old_mmap(NULL, 263568, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40023000
mprotect(0x40054000, 62864, PROT_NONE)  = 0
old_mmap(0x40054000, 57344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x3) = 
0x40054000
old_mmap(0x40062000, 5520, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 
-1, 0) = 0x40062000
close(4)= 0
open("/lib/libm.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20J\0\000"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=530027, ...}) = 0
old_mmap(NULL, 128792, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40064000
mprotect(0x40083000, 1816, PROT_NONE)   = 0
old_mmap(0x40083000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x1e000) = 
0x40083000
close(4)= 0
open("/lib/libc.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\300\1"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=5155229, ...}) = 0
old_mmap(NULL, 1214792, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40084000
mprotect(0x401a4000, 35144, PROT_NONE)  = 0
old_mmap(0x401a4000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x11f000) 
= 0x401a4000
old_mmap(0x401a9000, 14664, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 
-1, 0) = 0x401a9000
close(4)= 0
open("/lib/libc.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\300\1"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=5155229, ...}) = 0
close(4)= 0
open("/lib/libc.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\300\1"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=5155229, ...}) = 0
close(4)= 0
open("/lib/libm.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20J\0\000"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=530027, ...}) = 0
close(4)= 0
open("/lib/libc.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\300\1"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=5155229, ...}) = 0
close(4)= 0
open("/lib/libc.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\300\1"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=5155229, ...}) = 0
close(4)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x401ad000
munmap(0x4001a000, 23137)   = 0
getpid()= 807
brk(0)  = 0x823318c
brk(0x82331ac)  = 0x82331ac
brk(0x8234000)  = 0x8234000
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, 

Re: Sound issues with m805lr motheboard

2001-03-22 Thread Brent D. Norris

> That seems strange. What is realserver failing with ?

It isn't so much failing as it hangs.  I don't know if you have used it
or not.  On a startup of the realserver under a 2.2 kernel here is the
output:
*
RealServer (c) 1995-2000 RealNetworks, Inc. All rights reserved.
Version: RealServer 8 (8.0.0.149)
Platform: linux-2.0-libc6-i386

Creating Server Space...
Calibrating Timers...
Starting RealServer 8.0 Core...
Loading RealServer License Files...

Detecting Number of CPUs...
   Testing 1 CPU(s): 1 CPU Detected, Phew...
   Testing 2 CPU(s): 2 CPUs Not Detected (96% Work Produced)
Testing File Descriptors...
Setting per-process descriptor capacity to 676(1010), 11...

***
it then goes on to load libs and stuff.  Under a 2.4 kernel it gets to the

"Testing 1 CPU(s)" Line and just stops there and sits.  I have tried it on
3 different machines and 5 different installs, all with the same results.

Brent Norris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Sound issues with m805lr motheboard

2001-03-22 Thread Brent D. Norris

 That seems strange. What is realserver failing with ?

It isn't so much failing as it hangs.  I don't know if you have used it
or not.  On a startup of the realserver under a 2.2 kernel here is the
output:
*
RealServer (c) 1995-2000 RealNetworks, Inc. All rights reserved.
Version: RealServer 8 (8.0.0.149)
Platform: linux-2.0-libc6-i386

Creating Server Space...
Calibrating Timers...
Starting RealServer 8.0 Core...
Loading RealServer License Files...

Detecting Number of CPUs...
   Testing 1 CPU(s): 1 CPU Detected, Phew...
   Testing 2 CPU(s): 2 CPUs Not Detected (96% Work Produced)
Testing File Descriptors...
Setting per-process descriptor capacity to 676(1010), 11...

***
it then goes on to load libs and stuff.  Under a 2.4 kernel it gets to the

"Testing 1 CPU(s)" Line and just stops there and sits.  I have tried it on
3 different machines and 5 different installs, all with the same results.

Brent Norris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Sound issues with m805lr motheboard

2001-03-22 Thread Brent D. Norris

 It might be interesting to strace the realserver startup
 both under 2.2 and 2.4 -

Here you go.  Also sorry Alan for such a goofy email earlier.  Does anyone
have any ideas on the sound driver issue?

Brent Norris



execve("Bin/rmserver", ["Bin/rmserver", "rmserver.cfg"], [/* 23 vars */]) = 0
uname({sys="Linux", node="linux-wolf", ...}) = 0
brk(0)  = 0x823318c
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/lib/libNoVersion.so.1", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0755, st_size=15967, ...}) = 0
close(4)= 0
open("/lib/libNoVersion.so.1", O_RDONLY) = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\10"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=15967, ...}) = 0
old_mmap(NULL, 7272, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40018000
mprotect(0x40019000, 3176, PROT_NONE)   = 0
old_mmap(0x40019000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0) = 
0x40019000
close(4)= 0
open("/etc/ld.so.cache", O_RDONLY)  = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=23137, ...}) = 0
old_mmap(NULL, 23137, PROT_READ, MAP_PRIVATE, 4, 0) = 0x4001a000
close(4)= 0
open("/lib/libdl.so.2", O_RDONLY)   = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\34\0\000"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=60598, ...}) = 0
old_mmap(NULL, 12244, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x4002
mprotect(0x40022000, 4052, PROT_NONE)   = 0
old_mmap(0x40022000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x1000) = 
0x40022000
close(4)= 0
open("/usr/lib/libstdc++.so.2.8", O_RDONLY) = 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\364\204"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=375773, ...}) = 0
old_mmap(NULL, 263568, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40023000
mprotect(0x40054000, 62864, PROT_NONE)  = 0
old_mmap(0x40054000, 57344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x3) = 
0x40054000
old_mmap(0x40062000, 5520, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 
-1, 0) = 0x40062000
close(4)= 0
open("/lib/libm.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20J\0\000"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=530027, ...}) = 0
old_mmap(NULL, 128792, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40064000
mprotect(0x40083000, 1816, PROT_NONE)   = 0
old_mmap(0x40083000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x1e000) = 
0x40083000
close(4)= 0
open("/lib/libc.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\300\1"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=5155229, ...}) = 0
old_mmap(NULL, 1214792, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40084000
mprotect(0x401a4000, 35144, PROT_NONE)  = 0
old_mmap(0x401a4000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x11f000) 
= 0x401a4000
old_mmap(0x401a9000, 14664, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 
-1, 0) = 0x401a9000
close(4)= 0
open("/lib/libc.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\300\1"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=5155229, ...}) = 0
close(4)= 0
open("/lib/libc.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\300\1"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=5155229, ...}) = 0
close(4)= 0
open("/lib/libm.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20J\0\000"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=530027, ...}) = 0
close(4)= 0
open("/lib/libc.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\300\1"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=5155229, ...}) = 0
close(4)= 0
open("/lib/libc.so.6", O_RDONLY)= 4
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\300\1"..., 1024) = 1024
fstat64(4, {st_mode=S_IFREG|0755, st_size=5155229, ...}) = 0
close(4)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x401ad000
munmap(0x4001a000, 23137)   = 0
getpid()= 807
brk(0)  = 0x823318c
brk(0x82331ac)  = 0x82331ac
brk(0x8234000)  = 0x8234000
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, 

Sound issues with m805lr motheboard

2001-03-21 Thread Brent D. Norris

My LUG has had a machine donated with a PC Chips M805LR Motherboard (info
here http://www.eurocomla.com/m805lr.htm)  I have to get it working to
stream our meetings with realserver.  as such I cannot use the new 2.4
kernels with it since Realserver won't work with them.  I am having
trouble with the kernel drivers for its onboard sound card.  I have
compiled the driver for the VIA 82C686 and I can get sound, but it will
not recognize the line-in port.  If I use a 2.4 kernel on the machine then
it works fine, but I can't run the realserver with it.  Is this a known
issue with the VIA drivers in the 2.2.xx (i am using 2.2.18)? if so is
there a work around for it?  Any info would be helpful.
thanks,
Brent Norris

System Admin -  WKU-Center for BioDiversity (4)
WKU-Linux (3)
Best Mechanical (3)


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



Sound issues with m805lr motheboard

2001-03-21 Thread Brent D. Norris

My LUG has had a machine donated with a PC Chips M805LR Motherboard (info
here http://www.eurocomla.com/m805lr.htm)  I have to get it working to
stream our meetings with realserver.  as such I cannot use the new 2.4
kernels with it since Realserver won't work with them.  I am having
trouble with the kernel drivers for its onboard sound card.  I have
compiled the driver for the VIA 82C686 and I can get sound, but it will
not recognize the line-in port.  If I use a 2.4 kernel on the machine then
it works fine, but I can't run the realserver with it.  Is this a known
issue with the VIA drivers in the 2.2.xx (i am using 2.2.18)? if so is
there a work around for it?  Any info would be helpful.
thanks,
Brent Norris

System Admin -  WKU-Center for BioDiversity (4)
WKU-Linux (3)
Best Mechanical (3)


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



Mounting ISO via Loop Devices

2001-03-17 Thread Brent D. Norris

On my redhat 7.1 machine I have been using the 2.4.0 redhat kernel and
mounting ISO's to loop devices and it worked fine.  I upgraded to a 2.4.2
kernel and now none of the ISO's will mount.  They all hang when the
command is run.  Are there any other known occurences of this?

I am not on the list so if there some issue that you would like to tell me
or if you need more information please write me back directly.

Brent Norris

System Admin -  WKU-Center for BioDiversity (4)
WKU-Linux (3)
Best Mechanical (3)

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



Mounting ISO via Loop Devices

2001-03-17 Thread Brent D. Norris

On my redhat 7.1 machine I have been using the 2.4.0 redhat kernel and
mounting ISO's to loop devices and it worked fine.  I upgraded to a 2.4.2
kernel and now none of the ISO's will mount.  They all hang when the
command is run.  Are there any other known occurences of this?

I am not on the list so if there some issue that you would like to tell me
or if you need more information please write me back directly.

Brent Norris

System Admin -  WKU-Center for BioDiversity (4)
WKU-Linux (3)
Best Mechanical (3)

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