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.
>
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
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
es 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]
> Please read the FAQ at http://www.tux.org/lkml/
--
Joe deBlaquiere
Red Ha
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 programs in
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.
Different Merlin -- original Merlin is 19200
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
s 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 a message to [EMAIL PROTECTED]
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 a message to [EMAIL PROTECTED]
Please re
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
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
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
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
t;> explanation. Maybe some day
>> they will awake to the expressive power of long (and =
>> well chosen) names.
>>
>>
>>
>>
>> --_=_NextPart_001_01C08552.FFC336D0--
>> -
>> To unsubscribe from this list: send the line "unsubscribe l
-
-
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/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
r 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, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (25
ched_yield() (for testing
purposes only!), and run the existing benchmarks. Can anyone
suggest a better solution?
Thanks,
--
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 "un
c 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-
> threading.
>
> Finally, post such things to
nobody of the MIPS'ers might see your posting on l-k.
Ralf
--
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
ps
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 reverted?
Sorry For the Long Post (tm)! Thanks In Advance! Merry Xmas!
--
Joe deBlaquiere
Red Hat, In
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 reverted?
Sorry For the Long Post (tm)! Thanks In Advance! Merry Xmas!
--
Joe deBlaquiere
Red Hat, Inc.
307 W
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-toolchain less difficult
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
uld 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/
. with
export TARGET_KERNEL=2.0.4
make
Even if your system is running 2.4.13-test1.
The architecture could 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
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 some driver
module ;-)
I
27 matches
Mail list logo
