On 20010711 J . A . Magallon wrote:
>Hi, all...
>
>[I'm sending this both to lkml and distro support, beacause I am not sure who
>is to blame...]
>
>Well, fast synopsys: iniscripts use /sbin/ip from iproute2-2.2.4. That needs:
>CONFIG_NETLINK=y
>CONFIG_RTNETLINK
Hi, all...
[I'm sending this both to lkml and distro support, beacause I am not sure who
is to blame...]
Well, fast synopsys: iniscripts use /sbin/ip from iproute2-2.2.4. That needs:
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
to work. If I enable that, pump breaks (I have to try with another dhcp
Hi, all...
[I'm sending this both to lkml and distro support, beacause I am not sure who
is to blame...]
Well, fast synopsys: iniscripts use /sbin/ip from iproute2-2.2.4. That needs:
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
to work. If I enable that, pump breaks (I have to try with another dhcp
On 20010711 J . A . Magallon wrote:
Hi, all...
[I'm sending this both to lkml and distro support, beacause I am not sure who
is to blame...]
Well, fast synopsys: iniscripts use /sbin/ip from iproute2-2.2.4. That needs:
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
to work. If I enable that, pump breaks
On 20010706 Davide Libenzi wrote:
>
>On 05-Jul-2001 David Woodhouse wrote:
>>
>> [EMAIL PROTECTED] said:
>>> This program prints garbage:
>>> #define min(x,y) ({ typeof((x)) _x = (x); typeof((y)) _y = (y);
>>> #(_x>_y)?_y:_x; })
>>> int main (void) {
>>> int
On 20010706 Davide Libenzi wrote:
On 05-Jul-2001 David Woodhouse wrote:
[EMAIL PROTECTED] said:
This program prints garbage:
#define min(x,y) ({ typeof((x)) _x = (x); typeof((y)) _y = (y);
#(_x_y)?_y:_x; })
int main (void) {
int _x = 3, _y = 4;
On 20010703 Erik Meusel wrote:
>On Tue, 3 Jul 2001, Keith Owens wrote:
>
>> >P.S.: would it be possible to patch the menuconfig in that way, that it
>> >does look in the whole include-path for the and relating
>> >files? they aren't in /usr/include/ in my system and I'm tired of patching
>>
On 20010703 Erik Meusel wrote:
On Tue, 3 Jul 2001, Keith Owens wrote:
P.S.: would it be possible to patch the menuconfig in that way, that it
does look in the whole include-path for the ncurses.h and relating
files? they aren't in /usr/include/ in my system and I'm tired of patching
On 20010629 Martin Knoblauch wrote:
>Hi,
>
> just something positive for the weekend. With 2.4.5-ac21, the behaviour
>on my laptop (128MB plus twice the sapw) seems a bit more sane. When I
>start new large applications now, the "used" portion of VM actually
>pushes against the cache instead of
On 20010629 Martin Knoblauch wrote:
Hi,
just something positive for the weekend. With 2.4.5-ac21, the behaviour
on my laptop (128MB plus twice the sapw) seems a bit more sane. When I
start new large applications now, the used portion of VM actually
pushes against the cache instead of forcing
On 20010628 Troy Benjegerdes wrote:
>> >
>> > > usb-uhci.c: v1.251 Georg Acher, Deti Fliegl, Thomas Sailer,
>> > Roman Weissgaerber
>> > > usb-uhci.c: USB Universal Host Controller Interface driver
>> >
>> > How about "usb-uhci.c: USB Universal Host Controller Interface
>> > driver v1.251"
>> >
On 20010628 Troy Benjegerdes wrote:
usb-uhci.c: v1.251 Georg Acher, Deti Fliegl, Thomas Sailer,
Roman Weissgaerber
usb-uhci.c: USB Universal Host Controller Interface driver
How about usb-uhci.c: USB Universal Host Controller Interface
driver v1.251
instead?
Sorry if this
This discussion seems to go nowhere. Thanks for your comments. I know much
more on Linux than before.
I am happy that processes in Linux are so marvelous. Linux does not need
a decent POSIX threads implementation because the same functionality can
be achived with processes. Do what you like, you
This discussion seems to go nowhere. Thanks for your comments. I know much
more on Linux than before.
I am happy that processes in Linux are so marvelous. Linux does not need
a decent POSIX threads implementation because the same functionality can
be achived with processes. Do what you like, you
On 20010625 Larry McVoy wrote:
>
>One for the quotes page, eh? We're terribly sorry, we'll get busy on adding
>some delay loops in Linux so it too can be slow.
>--
I was afraid someone would tell that...
I just want to say that the 'problem' is not that threads are slow in linux,
but that
On 20010624 Sasi Peter wrote:
>
>I know opendivx code is not like kernel code at all, but on the other hand
>it is well suited for benchmark testing.
>
>
>test file: (opendivx with postprocessing, this stuff is written in C)
># mplayer -osdlevel 0 -nosound -benchmark 1800.avi -vo null -pp 15
On 20010624 Alan Cox wrote:
>
>2. Look back in the kernel archives and you'll find some patches for
> the warnings about multi-line string literals in asm blocks
>
Are there any plans to standarise asm inline code, for example in
Documentation/CodingStyle (of course, in good
On 20010624 Rob Landley wrote:
>
>This is a bit like like saying that a truck and a train are totally different
>beasts. If I'm trying to haul cargo from point A to point B, which is served
>by both, all I care about is how long it takes and how much it costs.
>
>I don't care what it was
On 20010621 Stephen Satchell wrote:
>
>By the way, I'm surprised no one has mentioned that a synonym for "thread"
>is "lightweight process".
>
In linux. Perhaps this the fault.
In IRIX, you have sprocs and threads. sprocs have independent pids and you
can control what you share (mappings, fd
On 20010622 Rob Landley wrote:
>
>I still consider the difference between threads and processes with shared
>resources (memory, fds, etc) to be largely semantic.
>
They should not be the same. Processes are processes, and threads were designed
for situations where processes are too heavy.
On 20010622 Rob Landley wrote:
I still consider the difference between threads and processes with shared
resources (memory, fds, etc) to be largely semantic.
They should not be the same. Processes are processes, and threads were designed
for situations where processes are too heavy. Other
On 20010621 Stephen Satchell wrote:
By the way, I'm surprised no one has mentioned that a synonym for thread
is lightweight process.
In linux. Perhaps this the fault.
In IRIX, you have sprocs and threads. sprocs have independent pids and you
can control what you share (mappings, fd
On 20010624 Rob Landley wrote:
This is a bit like like saying that a truck and a train are totally different
beasts. If I'm trying to haul cargo from point A to point B, which is served
by both, all I care about is how long it takes and how much it costs.
I don't care what it was INTENDED
On 20010624 Sasi Peter wrote:
I know opendivx code is not like kernel code at all, but on the other hand
it is well suited for benchmark testing.
test file: (opendivx with postprocessing, this stuff is written in C)
# mplayer -osdlevel 0 -nosound -benchmark 1800.avi -vo null -pp 15
VIDEO:
On 20010625 Larry McVoy wrote:
One for the quotes page, eh? We're terribly sorry, we'll get busy on adding
some delay loops in Linux so it too can be slow.
--
I was afraid someone would tell that...
I just want to say that the 'problem' is not that threads are slow in linux,
but that others
On 20010624 Alan Cox wrote:
2. Look back in the kernel archives and you'll find some patches for
the warnings about multi-line string literals in asm blocks
Are there any plans to standarise asm inline code, for example in
Documentation/CodingStyle (of course, in good friendship
On 20010618 Dan Kegel wrote:
>Pete Wyckoff wrote:
>>
>> [EMAIL PROTECTED] said:
>> > I'd like to monitor CPU, memory, and I/O utilization in a
>> > long-running multithreaded daemon under kernels 2.2, 2.4,
>> > and possibly also Solaris (#ifdefs are ok).
>>
>> getrusage() isn't really the
On 20010618 Dan Kegel wrote:
Pete Wyckoff wrote:
[EMAIL PROTECTED] said:
I'd like to monitor CPU, memory, and I/O utilization in a
long-running multithreaded daemon under kernels 2.2, 2.4,
and possibly also Solaris (#ifdefs are ok).
getrusage() isn't really the system call you want
Hi.
First, sorry if this is a glibc issue. Just chose to ask here first.
I want to know the CPU time used by a POSIX-threaded program. I have tried
to use getrusage() with RUSAGE_SELF and RUSAGE_CHILDREN. Problem:
main thread just do nothing, spawns children and waits. And I get always
0
On 20010613 Kurt Garloff wrote:
>
> What I do in my numerics code to avoid this problem, is to create all the
> threads (as many as there are CPUs) on program startup and have then wait
> (block) for a condition. As soon as there's something to to, variables for
> the thread are setup
On 20010613 Kurt Garloff wrote:
What I do in my numerics code to avoid this problem, is to create all the
threads (as many as there are CPUs) on program startup and have then wait
(block) for a condition. As soon as there's something to to, variables for
the thread are setup (protected by
Hi.
First, sorry if this is a glibc issue. Just chose to ask here first.
I want to know the CPU time used by a POSIX-threaded program. I have tried
to use getrusage() with RUSAGE_SELF and RUSAGE_CHILDREN. Problem:
main thread just do nothing, spawns children and waits. And I get always
0
On 06.08 Michael H. Warfield wrote:
>
> No, we are not talking lab instrumentation here. We are talking
> about CPU monitoring. Lab instrumentation is a whole different issue
> with things like the IEEE bus and such. Lab instrumentation would require
> it's own drivers and interface.
>
On 06.08 Michael H. Warfield wrote:
>
> Actually, the REAL point I was TRYING to make (and doing a really
> shabby job of it) is that some of this needs a little dose of reality.
> We don't have sensors that are accurate to 1/10 of a K and certainly not
> to 1/100 of a K. Knowing the CPU
On 06.08 Michael H. Warfield wrote:
Actually, the REAL point I was TRYING to make (and doing a really
shabby job of it) is that some of this needs a little dose of reality.
We don't have sensors that are accurate to 1/10 of a K and certainly not
to 1/100 of a K. Knowing the CPU
On 06.08 Michael H. Warfield wrote:
No, we are not talking lab instrumentation here. We are talking
about CPU monitoring. Lab instrumentation is a whole different issue
with things like the IEEE bus and such. Lab instrumentation would require
it's own drivers and interface.
On 06.07 Nico Schottelius wrote:
> >
> > Based upon the lspci output you posted earlier, aic7880 has a single
> > SCSI bus.
>
> Oh. That could really be a problem.. I though having two different
> connectors on the board would make two different buses..
> I must have been wrong.
>
> > So you
On 06.07 Nico Schottelius wrote:
Based upon the lspci output you posted earlier, aic7880 has a single
SCSI bus.
Oh. That could really be a problem.. I though having two different
connectors on the board would make two different buses..
I must have been wrong.
So you must mean two
On 06.06 Pavel Machek wrote:
>
> ACPI is already using 0.1*K, so everything should use that to be
> consistent.
> Pavel
Which is the data type for temperature ? Would not it be better to
use 0.01*K ? So you get the full accuracy of
On 06.06 john slee wrote:
>
> On Wed, Jun 06, 2001 at 02:27:22PM +0200, David N. Welton wrote:
> > Perusing the kernel sources while investigating watchdog drivers, I
> > notice that in some places, Fahrenheit is used, and in some places,
> > Celsius. It would seem logical to me to have a
Hi,
A little test-question. I am getting some strange timings...
Hardware: PIIX4:
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80
[Master])
Flags: bus master, medium devsel, latency 64
I/O ports at ffa0 [size=16]
and a Creative 52mx CD-ROM
Hi,
A little test-question. I am getting some strange timings...
Hardware: PIIX4:
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80
[Master])
Flags: bus master, medium devsel, latency 64
I/O ports at ffa0 [size=16]
and a Creative 52mx CD-ROM
On 06.06 john slee wrote:
On Wed, Jun 06, 2001 at 02:27:22PM +0200, David N. Welton wrote:
Perusing the kernel sources while investigating watchdog drivers, I
notice that in some places, Fahrenheit is used, and in some places,
Celsius. It would seem logical to me to have a global
On 06.06 Pavel Machek wrote:
ACPI is already using 0.1*K, so everything should use that to be
consistent.
Pavel
Which is the data type for temperature ? Would not it be better to
use 0.01*K ? So you get the full accuracy of a
On 06.02 Pavel Machek wrote:
> Hi!
>
> > ...again (I think I asked just the same last summer)
> > and lm_sensors is still out of the kernel (we have got 40ºC in Spain
> > this week, and I would like to know how my PIIs suffer...)
>
> Send some summer over here. It is 15C outside...
>
> You
On 06.02 Pavel Machek wrote:
Hi!
...again (I think I asked just the same last summer)
and lm_sensors is still out of the kernel (we have got 40ºC in Spain
this week, and I would like to know how my PIIs suffer...)
Send some summer over here. It is 15C outside...
You should try
On 05.30 Marcelo Tosatti wrote:
>
>
> Its at
> http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.5ac4/reapswap.patch
>
> Please test.
>
Which kind of test, something like the gcc think I posted recently ?
Just stress vm, fill swap, and try to do it again ?
--
J.A. Magallon
On 05.30 Alan Cox wrote:
>
> 2.4.5-ac5
> o Move the pagecache and pagemap_lru_lock to (Andrea Arcangeli)
> different cache lines
Nice bit. One other bit from aa I think perhaps is usefull for SMP
(don't understand fully the difference, but if it makes cache usage better...)
is
...again (I think I asked just the same last summer)
and lm_sensors is still out of the kernel (we have got 40ºC in Spain
this week, and I would like to know how my PIIs suffer...)
Anybody knows if sensors will get into kernel anytime in this century ?
Yes, it can generate patches automagically,
...again (I think I asked just the same last summer)
and lm_sensors is still out of the kernel (we have got 40ºC in Spain
this week, and I would like to know how my PIIs suffer...)
Anybody knows if sensors will get into kernel anytime in this century ?
Yes, it can generate patches automagically,
On 05.30 Alan Cox wrote:
2.4.5-ac5
o Move the pagecache and pagemap_lru_lock to (Andrea Arcangeli)
different cache lines
Nice bit. One other bit from aa I think perhaps is usefull for SMP
(don't understand fully the difference, but if it makes cache usage better...)
is
On 05.30 Marcelo Tosatti wrote:
Its at
http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.5ac4/reapswap.patch
Please test.
Which kind of test, something like the gcc think I posted recently ?
Just stress vm, fill swap, and try to do it again ?
--
J.A. Magallon
On 05.29 Fabbione wrote:
> Hi all,
> sorry for the offtopic msg.
>
> Can someone point me to a 4 ports fast/eth card solution for linux?
>
> I found some cards based on the DEC 21*4* chips but when
> I asked for more details I got a strange answer from the reseller
> like that this card
On 05.29 Fabbione wrote:
Hi all,
sorry for the offtopic msg.
Can someone point me to a 4 ports fast/eth card solution for linux?
I found some cards based on the DEC 21*4* chips but when
I asked for more details I got a strange answer from the reseller
like that this card is able
On 05.26 Rik van Riel wrote:
> On Sat, 26 May 2001, J . A . Magallon wrote:
>
> > It does not begin to use swap in a growing fashion, it just appears
> > full in a moment.
>
> It gets _allocated_ in a moment, but things don't actually get
> swapped out. This isn
On 05.26 Rik van Riel wrote:
On Sat, 26 May 2001, J . A . Magallon wrote:
It does not begin to use swap in a growing fashion, it just appears
full in a moment.
It gets _allocated_ in a moment, but things don't actually get
swapped out. This isn't a problem.
The real problem
Hi.
This is a little experiment to smash 2.4 vm, and there is something I do not
understand.
Experiment: compile a C file with, say, 100k lines of puts("test"), auto
generated. Box is running vanilla 2.4.5, on 256Mb of ram.
State before gcc tst.c (just logged in a Gnome session with a couple
Hi.
This is a little experiment to smash 2.4 vm, and there is something I do not
understand.
Experiment: compile a C file with, say, 100k lines of puts(test), auto
generated. Box is running vanilla 2.4.5, on 256Mb of ram.
State before gcc tst.c (just logged in a Gnome session with a couple
On 05.21 Alan Cox wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
>
>Intermediate diffs are available from
> http://www.bzimage.org
>
>
> 2.4.4-ac12
> o Just tracking Linus 2.4.5pre4
> - A chunk more
On 05.21 Richard Henderson wrote:
> On Mon, May 21, 2001 at 01:07:50PM +1000, Keith Owens wrote:
> > does cause a section conflict, egcs 1.1.2.
> >
> > Interestingly enough, if var[12] are together, without the intervening
> > text, then gcc does not flag an error, instead it puts both
On 05.21 Richard Henderson wrote:
On Mon, May 21, 2001 at 01:07:50PM +1000, Keith Owens wrote:
does cause a section conflict, egcs 1.1.2.
Interestingly enough, if var[12] are together, without the intervening
text, then gcc does not flag an error, instead it puts both variables
in
On 05.21 Alan Cox wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
2.4.4-ac12
o Just tracking Linus 2.4.5pre4
- A chunk more merged with
On 05.18 Bill Pringlemeir wrote:
>
> Why don't the build scripts run a dummy file to determine where the
> floating point registers should be placed?
>
> ...
> const int value = offsetof(struct task_struct, thread.i387.fxsave) & 15;
> ...
>
That is not the problem. The problem is that the
On 05.17 Manfred Spraul wrote:
> "David S. Miller" wrote:
> >
> > J . A . Magallon writes:
> > > > What platform?
> >
> > > Any more info ?
> >
> > No, I thought it might be some cache flushing issue
> > on a no
On 05.17 Manfred Spraul wrote:
David S. Miller wrote:
J . A . Magallon writes:
What platform?
Any more info ?
No, I thought it might be some cache flushing issue
on a non-x86 machine.
I found the problem:
I sent out the old patch :-(
Attached is the correct
On 05.18 Bill Pringlemeir wrote:
Why don't the build scripts run a dummy file to determine where the
floating point registers should be placed?
...
const int value = offsetof(struct task_struct, thread.i387.fxsave) 15;
...
That is not the problem. The problem is that the registers
On 05.17 Ingo Oeser wrote:
> On Thu, May 17, 2001 at 05:45:38PM +0100, Alan Cox wrote:
> > 2.4.4-ac10
>
> I think someone forgot this little return. It removes the
> following warning:
>
> serial.c:4208: warning: control reaches end of non-void function
>
>
> ---
On 05.17 Ingo Oeser wrote:
On Thu, May 17, 2001 at 05:45:38PM +0100, Alan Cox wrote:
2.4.4-ac10
I think someone forgot this little return. It removes the
following warning:
serial.c:4208: warning: control reaches end of non-void function
--- linux-2.4.4-ac10/drivers/char/serial.c
On 05.13 Rik van Riel wrote:
> On Tue, 8 May 2001, Mike Galbraith wrote:
>
> > While running a ktrace enabled kernel (IKD), I noticed many useless
> > context switches. The problem is that we continually pester kswapd/
> > kflushd at times when they can't do anything other than go back to
> >
On 05.13 Rik van Riel wrote:
On Tue, 8 May 2001, Mike Galbraith wrote:
While running a ktrace enabled kernel (IKD), I noticed many useless
context switches. The problem is that we continually pester kswapd/
kflushd at times when they can't do anything other than go back to
sleep. As
On 05.12 David S. Miller wrote:
>
> J . A . Magallon writes:
> > I tried your patch on 2.4.4-ac8, and something strange happens.
> > Untarring linux-2.4.4 takes a little time, disk light flashes,
> > but no files appear on the disk (just 'Makefile', as you wil
On 05.12 David S. Miller wrote:
J . A . Magallon writes:
I tried your patch on 2.4.4-ac8, and something strange happens.
Untarring linux-2.4.4 takes a little time, disk light flashes,
but no files appear on the disk (just 'Makefile', as you will see below).
Doing a separate gunzip
On 05.12 J . A . Magallon wrote:
>
> On 05.11 Manfred Spraul wrote:
> >
> > Please test it.
> > The kernel space part should be ok, but I know that the
> > patch can cause deadlocks with buggy user space apps.
> >
>
> I tried your patch o
On 05.11 Manfred Spraul wrote:
>
> Please test it.
> The kernel space part should be ok, but I know that the
> patch can cause deadlocks with buggy user space apps.
>
I tried your patch on 2.4.4-ac8, and something strange happens.
Untarring linux-2.4.4 takes a little time, disk light flashes,
On 05.11 Martin.Knoblauch wrote:
>
> I ask, because I thought the size of kproc could be used to determine
> the amount of physical memory. If this assumption is wrong, is there
> another way to achive the goal?
>
#include // for get_phys_pages()
#include // for getpagesize()
ram =
On 05.11 Martin.Knoblauch wrote:
I ask, because I thought the size of kproc could be used to determine
the amount of physical memory. If this assumption is wrong, is there
another way to achive the goal?
#include sys/sysinfo.h // for get_phys_pages()
#include unistd.h // for
On 05.11 Manfred Spraul wrote:
Please test it.
The kernel space part should be ok, but I know that the
patch can cause deadlocks with buggy user space apps.
I tried your patch on 2.4.4-ac8, and something strange happens.
Untarring linux-2.4.4 takes a little time, disk light flashes,
but
On 05.12 J . A . Magallon wrote:
On 05.11 Manfred Spraul wrote:
Please test it.
The kernel space part should be ok, but I know that the
patch can cause deadlocks with buggy user space apps.
I tried your patch on 2.4.4-ac8, and something strange happens.
Untarring linux-2.4.4
On 05.07 Helge Hafting wrote:
> Tobias Ringstrom wrote:
> >
> > On Sun, 6 May 2001, David S. Miller wrote:
> > > It is the most straightforward way to make a '1' or '0'
> > > integer from the NULL state of a pointer.
> >
> > But is it really specified in the C "standards" to be exctly zero or
On 05.07 Helge Hafting wrote:
Tobias Ringstrom wrote:
On Sun, 6 May 2001, David S. Miller wrote:
It is the most straightforward way to make a '1' or '0'
integer from the NULL state of a pointer.
But is it really specified in the C standards to be exctly zero or one,
and not
On 05.03 Miles Lane wrote:
> Sorry for sending a link to a (albeit, free) subcription
> service earlier. Here's the text of the article, in case
> you are interested in Microsoft's latest shinanigans.
>
>
> away in an effort to attract visitors to Web sites. G.P.L. requires
> that any
On 05.03 Miles Lane wrote:
Sorry for sending a link to a (albeit, free) subcription
service earlier. Here's the text of the article, in case
you are interested in Microsoft's latest shinanigans.
away in an effort to attract visitors to Web sites. G.P.L. requires
that any software
On 05.01 Hugh Dickins wrote:
> On Tue, 1 May 2001, J . A . Magallon wrote:
> > >
> > > OK works here ...
> >
> > Me too.
> >
> > Perhaps this reschedules ok in UP but kinda fails in SMP...
>
> Great. And see Andrea's SCHED_YIELD explanati
On 05.01 Andrea Arcangeli wrote:
>
> And if you fork off a child with its p->policy SCHED_YIELD set it will
> never get scheduled in.
>
> Only "just" running tasks can have SCHED_YIELD set.
>
> So the below lines are the *right* and most robust approch as far I can
> tell. (plus counter needs
On 05.01 boris wrote:
> On Tue, May 01, 2001 at 04:50:52PM +0100, Hugh Dickins wrote:
>
> > Don't ask me why, but I think you may find it's Peter's patch to
> > the women-and-children-first in kernel/fork.c: I'm not yet running
> > -ac2, but I am trying that patch, fine on UP but hanging right
On 05.01 Hugh Dickins wrote:
>
> Don't ask me why, but I think you may find it's Peter's patch to
> the women-and-children-first in kernel/fork.c: I'm not yet running
> -ac2, but I am trying that patch, fine on UP but hanging right there
> (well, I get a "go go go" message too) on SMP.
>
After
On 05.01 mirabilos wrote:
>
> Another point: look at the headers. I'd like LKML to
> strip all these X- thingies, the "Received:" etc.
> so that the messages I get have a bare minimum header
> consisting just of To: and Subject: (maybe MIME).
>
What you have todo is to learn how to configure
Hi,
On 05.01 Alan Cox wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
>
Hangs after APIC init:
(bootlog from ac1)
Using local APIC timer interrupts.
calibrating APIC timer ...
CPU clock speed is 400.9211 MHz.
host bus clock speed is 100.2300 MHz.
cpu: 0,
Hi,
Looking over one other problem, I realized that my 2 cpus are recognized
slightly different in the function:
cpu: 0, clocks: 1002324, slice: 334108
CPU0
cpu: 1, clocks: 1002324, slice: 334108
CPU1
Both are just the same, both pII@400, 512Kb:
CPU: Before vendor init, caps: 0183fbff
On 05.01 Andrea Arcangeli wrote:
And if you fork off a child with its p-policy SCHED_YIELD set it will
never get scheduled in.
Only just running tasks can have SCHED_YIELD set.
So the below lines are the *right* and most robust approch as far I can
tell. (plus counter needs to be
Hi,
Looking over one other problem, I realized that my 2 cpus are recognized
slightly different in the setup_APIC_timer function:
cpu: 0, clocks: 1002324, slice: 334108
CPU0T0:1002320,T1:668208,D:4,S:334108,C:1002324
cpu: 1, clocks: 1002324, slice: 334108
Hi,
On 05.01 Alan Cox wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Hangs after APIC init:
(bootlog from ac1)
Using local APIC timer interrupts.
calibrating APIC timer ...
CPU clock speed is 400.9211 MHz.
host bus clock speed is 100.2300 MHz.
cpu: 0,
On 05.01 mirabilos wrote:
Another point: look at the headers. I'd like LKML to
strip all these X- thingies, the Received: etc.
so that the messages I get have a bare minimum header
consisting just of To: and Subject: (maybe MIME).
What you have todo is to learn how to configure your
On 05.01 Hugh Dickins wrote:
Don't ask me why, but I think you may find it's Peter's patch to
the women-and-children-first in kernel/fork.c: I'm not yet running
-ac2, but I am trying that patch, fine on UP but hanging right there
(well, I get a go go go message too) on SMP.
After
On 05.01 Hugh Dickins wrote:
On Tue, 1 May 2001, J . A . Magallon wrote:
OK works here ...
Me too.
Perhaps this reschedules ok in UP but kinda fails in SMP...
Great. And see Andrea's SCHED_YIELD explanation in the sluggish
mail thread. Well, I didn't try to understand
On 05.01 Keith Owens wrote:
>
> The patch appears to work but is it worth applying now? The existing
> 2.4 rules work fine and the entire kbuild system will be rewritten for
> 2.5, including the case you identified here. It struck me as a decent
> change but for no benefit and, given that the
On 05.01 Keith Owens wrote:
The patch appears to work but is it worth applying now? The existing
2.4 rules work fine and the entire kbuild system will be rewritten for
2.5, including the case you identified here. It struck me as a decent
change but for no benefit and, given that the 2.4
On 04.29 Steve 'Denali' McKnelly wrote:
> Howdy J.A.,
>
> Let me ask a possibly stupid question... How do you tell
> what version of the Gibbs Adaptec driver you're using? Did I
You can look at the kernel boot messages for a line like:
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA
On 04.29 Steve 'Denali' McKnelly wrote:
> Command found on device queue
> aic7xxx_abort returns 8194
>
I have seen blaming for this error to aic7xxx new driver prior to version
6.1.11. It was included in the 2.4.3-ac series, but its has not got into
main 2.4.4 (there is still
On 04.29 Steve 'Denali' McKnelly wrote:
Command found on device queue
aic7xxx_abort returns 8194
I have seen blaming for this error to aic7xxx new driver prior to version
6.1.11. It was included in the 2.4.3-ac series, but its has not got into
main 2.4.4 (there is still 6.1.5).
1 - 100 of 509 matches
Mail list logo
