On 7/1/07, Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> You patch is also damaged here.
> Check your MUA settings.
>
[Sorry about that, resending again]
When the interface is down (or driver removed), the BroadCom 44xx card remains
powered on,
and both its MAC and PHY is using up power.
Thi
On 6/30/07, Matthew Garrett <[EMAIL PROTECTED]> wrote:
On Sat, Jun 30, 2007 at 07:44:59AM -0700, Arjan van de Ven wrote:
> Matthew Garrett wrote:
> >Do you still get link beat detection when the phy is powered down?
No.
As for link detection on the switch connected to this card:
If I have WoL t
On 6/30/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
This is a non-standard formatting for comments, please follow
Coding style:
Thanks, I have updated the patch.
When the interface is down (or driver removed), the BroadCom 44xx card
remains powered on,
and both its MAC and PHY is using u
When the interface is down (or driver removed), the BroadCom 44xx card remains
powered on, and both its MAC and PHY is using up power.
This patch makes the driver issue a MAC_CTRL_PHY_PDOWN when the interface
is halted, and does a partial chip reset turns off the activity LEDs too.
Applies to 2.6
On 5/19/07, Török Edvin <[EMAIL PROTECTED]> wrote:
I tried -v13. However the scheduling "error" is now 10% (vs 2% with -v12).
I also noticed strange behaviour with CPU hotplug. I offlined cpu1
(echo 0 >/sys/devices/system/cpu/cpu1/online), and the typing speed on
my terminal
On 6/13/07, Török Edvin <[EMAIL PROTECTED]> wrote:
Hi,
When I run a multithreaded application, consisting of a "main thread"
that is mostly idle, and
3 "worker threads" (using as much CPU as they can get), 'top' and 'ps'
show that
the application us
Hi,
When I run a multithreaded application, consisting of a "main thread"
that is mostly idle, and
3 "worker threads" (using as much CPU as they can get), 'top' and 'ps'
show that
the application uses 0% CPU.
If I turn off thread details in top, and ps it correctly shows the CPU
usage of each thr
On 5/17/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
hey, cool! Also try -v13 - it should be even more tighter.
I tried -v13. However the scheduling "error" is now 10% (vs 2% with -v12).
I also noticed strange behaviour with CPU hotplug. I offlined cpu1
(echo 0 >/sys/devices/system/cpu/cpu1/onli
On 5/17/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
note: you ran it on a dual-core system and the SMP load-balancer needs
time to gain precision in the non-RT test - so i'd suggest to test it
much longer than 10 seconds: 300 seconds at least.
Thanks, running for 300 seconds shows only a 2% err
Hi,
I have tested your new CFS scheduler (v2.6.21.1-v12) on a Dell
Inspiron 6400 (Intel Core Duo @ 1.66 Ghz, SMP).
I tested with the bash-for-loop, and the massiv_intr.c workload you
suggested here http://lkml.org/lkml/2007/5/14/227 , then I tested with
a modified version of massiv_intr.c.
My mo
On 4/16/07, Török Edvin <[EMAIL PROTECTED]> wrote:
I got an Ooops while trying to load a little kernel module I wrote.
[]
/* Attributes changeable via sysfs */
static struct attribute * default_attrs[] = {
&module_enabled.attr,
&wbinv
11 matches
Mail list logo
