hat would be a
> good scheduler benchmark for these low task count situations.
> I could undo the optimizations in sys_sched_yield() (for testing
> purposes only!), and run the existing benchmarks. Can anyone
> suggest a better solution?
>
> Thanks,
--
Joe deBlaquiere
Red Hat, In
ould be obtained from the tree or the tree could be
> picked based on the architecture. This is a policy decision that could
> be hidden in the script.
>
> - Werner
--
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax : (256)-837-3839
-
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/
Werner Almesberger wrote:
> Joe deBlaquiere wrote:
>
>> My solution to this has always been to make a cross compiler environment
>
>
> ;-))) I think lots of people would really enjoy to have "build a
> cross-gcc" added to the prerequisites for installing so
least for x86 these days... other arches sure to follow)
Peter Samuelson wrote:
> [Joe deBlaquiere]
>
>> might be a good newbie filter... but actually the best thing about it
>> is that the compiler people of the work might make generating a
>> proper cross-toolc
}
QUESTION 3) I notice that the code for this particular case of sysmips
has changed recently. The old code looked more like the 'll/sc' version
of glibc above. I would think that the 'll/sc' code would be better on
SMP systems. Is there a good reason why this revert
reverted?
>
Looking at 2.4.0-test5 I see the ll/sc code, but -test12 doesn't use it.
I was just curious at why it was taken out.
>
> Above code will break if the old content of memory has bit 31 set or you take
> pagefaults. The latter problem is a problem even on UP - think multi-
=
>> K&R C, with 6 or 7
>> character variable names that demand some =
>> explanation. Maybe some day
>> they will awake to the expressive power of long (and =
>> well chosen) names.
>>
>>
>>
>>
>> --_=_NextPart_001_01C08552.F
I'm trying to test a communications path to a remote system and was
wondering if I could force the DF bit on some UDP traffic. Does anybody
know of a way to do this??
TIA,
Joe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
A few things come to mind:
1. Is your init statically linked or linked with shared libraries? If
it's shared, do you have all the shared objects on your disk image in a
place where they can be found (/lib, I hope)? You might try linking it
statically (but stripped) just to make sure.
2. Is it
off,
for instance? I know this has to have been quantified to some extent, right?
--
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax : (256)-837-3839
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
There is a rather informative discussion of wireless support at :
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.drivers.html
Though possibly a little out of date, the author of this obviously did
their research. Kudos!
--
Joe
Michael H. Warfield wrote:
> On Sun, Jan 28,
aparently the debug and kdebug options no longer work ('debug'
> produces the LCP traffic, yes, but thats working fine).
>
> af
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
&
David Woodhouse wrote:
> On Thu, 1 Feb 2001, Pavel Machek wrote:
>
>
>> I thought that Vtech Helio folks already have XIP supported...
>
>
> Plenty of people are doing XIP of the kernel. I'm not aware of anyone
> doing XIP of userspace pages.
uClinux does XIP (readonly) for userspace pro
Hi Alex!
I'm a little confused here... why are we overrunning? This thing is
running externally at 19200 at best, even if it does all come in as a
packet. I would think the flip buffer would never contain more than a
few characters. Are you running it at a higher rate internally? Does
Alex Belits wrote:
> On Thu, 1 Feb 2001, Joe deBlaquiere wrote:
>
>
>> Hi Alex!
>>
>> I'm a little confused here... why are we overrunning? This thing is
>> running externally at 19200 at best, even if it does all come in as a
>> packet.
&
15 matches
Mail list logo