On 02/06/2013 05:21 AM, Steven Rostedt wrote:
On Tue, 2013-02-05 at 22:23 -0800, Ben Greear wrote:
On 02/05/2013 08:36 PM, Steven Rostedt wrote:
On Tue, 2013-02-05 at 19:30 -0800, Ben Greear wrote:
It's huge, so here's a link:
http://www.candelatech.com/~greearb/debug.tgz
The trace shows
On 02/06/2013 08:07 AM, Steven Rostedt wrote:
On Wed, 2013-02-06 at 07:56 -0800, Ben Greear wrote:
I'm 99% sure that the bug is in your modifications.
I'm sorry, I tried to make that clear.
You said it was an out of tree module, I didn't realize it had changes
to the core Linux as well
-mcast_rate));
Thanks,
Ben
--
Ben Greear gree...@candelatech.com
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
return 0;
}
--
Ben Greear gree...@candelatech.com
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On 02/06/2013 09:54 AM, Ben Greear wrote:
On 02/06/2013 08:27 AM, Johannes Berg wrote:
On Wed, 2013-02-06 at 17:23 +0100, Cong Ding wrote:
Using 'sizeof' on array given as function argument returns size of a pointer
rather than the size of array.
Oops, yeah, Stephen Hemminger pointed
On 02/05/2013 08:36 PM, Steven Rostedt wrote:
On Tue, 2013-02-05 at 19:30 -0800, Ben Greear wrote:
It's huge, so here's a link:
http://www.candelatech.com/~greearb/debug.tgz
The trace shows that __netif_receive_skb() is grabbing an
rcu_read_lock() but never releasing it. But I don't see
On 02/05/2013 08:26 PM, Steven Rostedt wrote:
On Tue, Feb 05, 2013 at 05:10:37PM -0800, Ben Greear wrote:
===
[ INFO: suspicious RCU usage. ]
3.7.6+ #4 Tainted: G C O
---
/home/greearb/git/linux-3.7.dev.y/kernel/rcutree.c:360
On 02/05/2013 06:52 PM, Steven Rostedt wrote:
On Tue, 2013-02-05 at 18:26 -0800, Ben Greear wrote:
Well, here it is..something is calling rcu_read_lock lots and lots,
Or a bug in the way lockdep handles rcu mappings.
it seems. Any way to get a better idea of where those calls are
made
On 02/05/2013 05:54 PM, Steven Rostedt wrote:
On Tue, Feb 05, 2013 at 05:10:37PM -0800, Ben Greear wrote:
I'm debugging something that could be my own bug in my wanlink module (but then
again, haven't seen this on 3.5 kernels, and my module is
basically un-changed since then).
I'm using
fairly suspicious that it isn't my code.
Famous last words I'm sure :)
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mor
0xa9/0x105
[] sys_write+0x54/0x89
[] system_call_fastpath+0x16/0x1b
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordo
est_init+0x7e/0x82
[] ? start_kernel+0x375/0x382
[] ? repair_env_string+0x58/0x58
[] ? x86_64_start_reservations+0xb8/0xbd
[] ? x86_64_start_kernel+0x101/0x110
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe li
[81011134] ? cpu_idle+0x63/0xb7
[815077fa] ? rest_init+0x7e/0x82
[81ab8ccb] ? start_kernel+0x375/0x382
[81ab878b] ? repair_env_string+0x58/0x58
[81ab82dd] ? x86_64_start_reservations+0xb8/0xbd
[81ab83e3] ? x86_64_start_kernel+0x101/0x110
--
Ben Greear
/0x20b
[8133db38] tty_write+0x19b/0x23a
[8133f930] ? n_tty_ioctl+0xc6/0xc6
[8133dc61] redirected_tty_write+0x8a/0x95
[81158d6c] vfs_write+0xa9/0x105
[81158ead] sys_write+0x54/0x89
[81559569] system_call_fastpath+0x16/0x1b
--
Ben Greear gree
fairly suspicious that it isn't my code.
Famous last words I'm sure :)
Thanks,
Ben
--
Ben Greear gree...@candelatech.com
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
On 02/05/2013 05:54 PM, Steven Rostedt wrote:
On Tue, Feb 05, 2013 at 05:10:37PM -0800, Ben Greear wrote:
I'm debugging something that could be my own bug in my wanlink module (but then
again, haven't seen this on 3.5 kernels, and my module is
basically un-changed since then).
I'm using
On 02/05/2013 06:52 PM, Steven Rostedt wrote:
On Tue, 2013-02-05 at 18:26 -0800, Ben Greear wrote:
Well, here it is..something is calling rcu_read_lock lots and lots,
Or a bug in the way lockdep handles rcu mappings.
it seems. Any way to get a better idea of where those calls are
made
On 02/05/2013 08:26 PM, Steven Rostedt wrote:
On Tue, Feb 05, 2013 at 05:10:37PM -0800, Ben Greear wrote:
===
[ INFO: suspicious RCU usage. ]
3.7.6+ #4 Tainted: G C O
---
/home/greearb/git/linux-3.7.dev.y/kernel/rcutree.c:360
On 02/05/2013 08:36 PM, Steven Rostedt wrote:
On Tue, 2013-02-05 at 19:30 -0800, Ben Greear wrote:
It's huge, so here's a link:
http://www.candelatech.com/~greearb/debug.tgz
The trace shows that __netif_receive_skb() is grabbing an
rcu_read_lock() but never releasing it. But I don't see
On 01/29/2013 06:18 PM, Ben Greear wrote:
I've been seeing strange lockups since 3.7.4. Not so easily reproducible
most of the time. Previous lockups looked to be rcu/rtnl based, but the one
below has a bunch of i2c stuff in it.
Patches applied are a few wifi patches from upstream and one
50
[ 432.111031] [] ? ret_from_kernel_thread+0x1b/0x28
[ 432.111031] [] ? __init_kthread_worker+0x60/0x60
[ 432.111031] panic occurred, switching back to text console
[ 432.111031] Rebooting in 10 seconds..
CTRL-A Z for help |115200 8N1 | NOR | Minicom 2.5| VT102 | Online 00:07
--
Ben Greear
Candela Techno
| NOR | Minicom 2.5| VT102 | Online 00:07
--
Ben Greear gree...@candelatech.com
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On 01/29/2013 06:18 PM, Ben Greear wrote:
I've been seeing strange lockups since 3.7.4. Not so easily reproducible
most of the time. Previous lockups looked to be rcu/rtnl based, but the one
below has a bunch of i2c stuff in it.
Patches applied are a few wifi patches from upstream and one
On 10/23/2012 03:52 PM, Ben Hutchings wrote:
On Tue, 2012-10-23 at 09:14 -0700, Ben Greear wrote:
On 10/22/2012 11:36 PM, David Miller wrote:
From: Doug Goldstein
Date: Mon, 22 Oct 2012 00:53:57 -0500
Sets the sysfs device_type to 'vlan' for udev. This makes it easier for
applications
).
And applications that care might suddenly have more features, or be more
efficient when running on newer kernels..
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
ethtool returns, which
sucks at best).
And applications that care might suddenly have more features, or be more
efficient when running on newer kernels..
Thanks,
Ben
--
Ben Greear gree...@candelatech.com
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send
On 10/23/2012 03:52 PM, Ben Hutchings wrote:
On Tue, 2012-10-23 at 09:14 -0700, Ben Greear wrote:
On 10/22/2012 11:36 PM, David Miller wrote:
From: Doug Goldstein car...@cardoe.com
Date: Mon, 22 Oct 2012 00:53:57 -0500
Sets the sysfs device_type to 'vlan' for udev. This makes it easier
1193static void uart_set_termios(struct tty_struct *tty,
1194struct ktermios
*old_termios)
1195{
1196struct uart_state *state = tty->driver_data;
1197unsigned long flags;
1198unsigned int cflag = tty->
tty_struct *tty,
1194struct ktermios
*old_termios)
1195{
1196struct uart_state *state = tty-driver_data;
1197unsigned long flags;
1198unsigned int cflag = tty-termios-c_cflag;
1199
(gdb)
Thanks,
Ben
--
Ben
,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
--
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.
,
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
--
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
3d/0x70
[] sysenter_past_esp+0x5f/0x89
===
Code: 08 89 ec 5d c3 8b 40 10 81 48 10 00 00 00 02 eb db 81 49 10 00 00 00 04
eb c2 8d 74 26 0
EIP: [] uart_write_room+0xd/0x20 SS:ESP 0068:f6e79ee4
CTRL-A Z for help | 38400 8N1 | NOR | Minicom 2.1| VT102 | Of
:f6e79ee4
CTRL-A Z for help | 38400 8N1 | NOR | Minicom 2.1| VT102 | Offline
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Eric W. Biederman wrote:
Ben Greear <[EMAIL PROTECTED]> writes:
Eric W. Biederman wrote:
However there also seem to be simpler cases like Ben's bridge module,
that don't appear to have any global state.
Well, my module has some global state, but I don't think it needs to care
Eric W. Biederman wrote:
Ben Greear <[EMAIL PROTECTED]> writes:
Regardless of infringement it is incompatible with a complete network
namespace implementation. Further it sounds like the module you are
describing defines a kernel ABI without being merged and hopes that
ABI will
ou have
some way to
register anonymous (and non GPL) subsystems. I'm guessing you do not
want to
support that....
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
(and non GPL) subsystems. I'm guessing you do not
want to
support that
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
Eric W. Biederman wrote:
Ben Greear [EMAIL PROTECTED] writes:
Regardless of infringement it is incompatible with a complete network
namespace implementation. Further it sounds like the module you are
describing defines a kernel ABI without being merged and hopes that
ABI will still
Eric W. Biederman wrote:
Ben Greear [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
However there also seem to be simpler cases like Ben's bridge module,
that don't appear to have any global state.
Well, my module has some global state, but I don't think it needs to care about
namespaces
Eric W. Biederman wrote:
Patrick McHardy <[EMAIL PROTECTED]> writes:
Ben Greear wrote:
I have a binary module that uses dev_get_by_name...it's sort of a bridge-like
thing and
needs user-space to tell it which device to listen for packets on...
This code doesn't need or care
Eric W. Biederman wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
Ben Greear wrote:
I have a binary module that uses dev_get_by_name...it's sort of a bridge-like
thing and
needs user-space to tell it which device to listen for packets on...
This code doesn't need or care about name
from a non-gpl module, but if required, I can probably figure something
out...
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
from a non-gpl module, but if required, I can probably figure something
out...
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
haps these patches should be considered for .23 stable as well?
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
these patches should be considered for .23 stable as well?
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
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
header. If the stripped
VLAN header is placed into the skb, then any code that does need to
rebuild it can do so. It may be less efficient, but users can just
not use that NIC hardware for high-end solutions, and at any rate,
less efficient is better than broken.
Ben
--
Ben Greear <[EMAIL
. If the stripped
VLAN header is placed into the skb, then any code that does need to
rebuild it can do so. It may be less efficient, but users can just
not use that NIC hardware for high-end solutions, and at any rate,
less efficient is better than broken.
Ben
--
Ben Greear [EMAIL PROTECTED
space. Ditto,
the receive checksum offload should be fixed up as well.
The hardware has stripped the VLAN header completely and has not
provided it to us at all.
Do the NICs not save the QoS bits in the VLAN header anywhere that we could
use to reconstitute the header?
Thanks,
Ben
--
Ben
. Ditto,
the receive checksum offload should be fixed up as well.
The hardware has stripped the VLAN header completely and has not
provided it to us at all.
Do the NICs not save the QoS bits in the VLAN header anywhere that we could
use to reconstitute the header?
Thanks,
Ben
--
Ben Greear
oesn't
explicitly know
about. I think it should pass them up the stack with VLAN tag intact,
but again, perhaps
there are reasons not to do that?
DaveM did the HW Accel for VLANs if I remember correctly...perhaps he
has some input?
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Tech
the VLAN header for hw-accel vlans?
Either way, if we sniff the underlying device, we should always get the
VLAN header.
What about drivers and filtering VLANs? It seems there is still a
difference between software
vlans and hw-accel in this case.
Thanks,
Ben
--
Ben Greear <[EMAIL PROTEC
the VLAN header for hw-accel vlans?
Either way, if we sniff the underlying device, we should always get the
VLAN header.
What about drivers and filtering VLANs? It seems there is still a
difference between software
vlans and hw-accel in this case.
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED
explicitly know
about. I think it should pass them up the stack with VLAN tag intact,
but again, perhaps
there are reasons not to do that?
DaveM did the HW Accel for VLANs if I remember correctly...perhaps he
has some input?
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc
David Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
I believe LRO is going to have to be disabled for routing/bridging,
so the stack will probably need to become aware of it at some point...
The packet will be GSO'd on output I believe, so it won't
break anything.
Alternative
ing to have to be disabled for routing/bridging,
so the stack will probably need to become aware of it at some point...
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscrib
to have to be disabled for routing/bridging,
so the stack will probably need to become aware of it at some point...
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
David Miller wrote:
From: Ben Greear [EMAIL PROTECTED]
I believe LRO is going to have to be disabled for routing/bridging,
so the stack will probably need to become aware of it at some point...
The packet will be GSO'd on output I believe, so it won't
break anything.
Alternatively, we
Krzysztof Halasa wrote:
Ben Greear <[EMAIL PROTECTED]> writes:
There is already a flag you can set on vlan devices (reorder-header)
that strips the VLAN tag before presenting it to user-space.
Sure, but isn't it only valid for VLAN device (not the main ethX)?
I.e., can yo
Krzysztof Halasa wrote:
Ben Greear [EMAIL PROTECTED] writes:
There is already a flag you can set on vlan devices (reorder-header)
that strips the VLAN tag before presenting it to user-space.
Sure, but isn't it only valid for VLAN device (not the main ethX)?
I.e., can you have the tag
on the correct VLAN.
Seems a bit of work, I know my message is missing the patch...
Unless I mis-understand, this has been working since 2.4 days :)
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send th
on the correct VLAN.
Seems a bit of work, I know my message is missing the patch...
Unless I mis-understand, this has been working since 2.4 days :)
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line
result is that dev_queue_xmit_nit() is called twice, once for
dev=eth0.2 then for dev=eth0.
Maybe binding to all isn't such a good idea then.
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
it.)
Any comments on what is the expected behavior of 'tcpdump -i eth0.2' vs.
'tcpdump -i eth0'?
I would expect that you see tags with -i eth0, but not with -i eth0.2
That is the way it currently works with non-hw-accell VLANs (or it was
the last I checked).
Ben
--
Ben Greear <[EMAIL PROTEC
it.)
Any comments on what is the expected behavior of 'tcpdump -i eth0.2' vs.
'tcpdump -i eth0'?
I would expect that you see tags with -i eth0, but not with -i eth0.2
That is the way it currently works with non-hw-accell VLANs (or it was
the last I checked).
Ben
--
Ben Greear [EMAIL PROTECTED
() is called twice, once for
dev=eth0.2 then for dev=eth0.
Maybe binding to all isn't such a good idea then.
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Patrick McHardy wrote:
Ben Greear wrote:
Patrick McHardy wrote:
Put another way, once you enable VLAN header stripping, you
won't see the headers for *any* VLAN, not only for those you're
actually running locally. This is also a problem for devices
like macvlan, where it would
. Then, the packets will be received by the software stack with
the vlan
header intact. Something sniffing on the physical dev will
automatically get the
VLAN header.
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscrib
. Then, the packets will be received by the software stack with
the vlan
header intact. Something sniffing on the physical dev will
automatically get the
VLAN header.
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from
Patrick McHardy wrote:
Ben Greear wrote:
Patrick McHardy wrote:
Put another way, once you enable VLAN header stripping, you
won't see the headers for *any* VLAN, not only for those you're
actually running locally. This is also a problem for devices
like macvlan, where it would
a printk in vlan_device_event() to check which event
it is hanging on, and
the netdevice that is passed in.
Since the vlan code holds RTNL at this point, then most other network
tasks will eventually
hang as well.
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc
enabled?
You could also add a printk in vlan_device_event() to check which event
it is hanging on, and
the netdevice that is passed in.
Since the vlan code holds RTNL at this point, then most other network
tasks will eventually
hang as well.
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela
?
[ Yes, I know this is an evil thing to attempt, and Greg did not
show me how to do it! :) ]
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
?
[ Yes, I know this is an evil thing to attempt, and Greg did not
show me how to do it! :) ]
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
that allows lockdep to save and print
this info, but I'm not clear on exactly how to pass the fname, fline info
through mutex_lock and on to lockdep's methods
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list
that allows lockdep to save and print
this info, but I'm not clear on exactly how to pass the fname, fline info
through mutex_lock and on to lockdep's methods
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send
looking at the report. If we see it again or
manage to find some way to reliably reproduce this on other
hardware, I will of course let you know.
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send th
: * REBOOT LINUX *
CT_ROOT: 38495/253184 files (3.5% non-contiguous), 227976/253015 blocks
(Repair filesystem) 3 # reboot
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe l
: pktgen_mark_device marking eth0#0 for removal
.
After restarting and a manual fsck, the system appears to
be back to normal.
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe l
: pktgen_mark_device marking eth0#0 for removal
.
After restarting and a manual fsck, the system appears to
be back to normal.
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
CT_ROOT: * FILE SYSTEM WAS MODIFIED *
CT_ROOT: * REBOOT LINUX *
CT_ROOT: 38495/253184 files (3.5% non-contiguous), 227976/253015 blocks
(Repair filesystem) 3 # reboot
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from
looking at the report. If we see it again or
manage to find some way to reliably reproduce this on other
hardware, I will of course let you know.
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line
if you enable ACPI, but at least it seems
fixed if you disable ACPI.
Hope this helps someone!
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
if you enable ACPI, but at least it seems
fixed if you disable ACPI.
Hope this helps someone!
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
n more detail.
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
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.o
detail.
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
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
problems is as useful as finding
problems in this sort of thing.
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED
problems is as useful as finding
problems in this sort of thing.
Thanks,
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
with decent built-in
NICs. The built-ins on this board are tg3 and they must be on
a slow bus, because they cannot go faster than about 700Mbps
(using big pkts).
I'll benchmark things again when 2.6.13 comes out and try to
get some more detailed numbers...
Thanks,
Ben
--
Ben Greear <[EM
Danial Thom wrote:
--- Ben Greear <[EMAIL PROTECTED]> wrote:
Danial Thom wrote:
I think the concensus is that 2.6 has made
trade
offs that lower raw throughput, which is what
a
networking device needs. So as a router or
network appliance, 2.6 seems less suitable. A
Danial Thom wrote:
--- Ben Greear <[EMAIL PROTECTED]> wrote:
Danial Thom wrote:
I think the concensus is that 2.6 has made
trade
offs that lower raw throughput, which is what
a
networking device needs. So as a router or
network appliance, 2.6 seems less suitable. A
Danial Thom wrote:
--- Ben Greear [EMAIL PROTECTED] wrote:
Danial Thom wrote:
I think the concensus is that 2.6 has made
trade
offs that lower raw throughput, which is what
a
networking device needs. So as a router or
network appliance, 2.6 seems less suitable. A
raw
bridging
Danial Thom wrote:
--- Ben Greear [EMAIL PROTECTED] wrote:
Danial Thom wrote:
I think the concensus is that 2.6 has made
trade
offs that lower raw throughput, which is what
a
networking device needs. So as a router or
network appliance, 2.6 seems less suitable. A
raw
bridging
with decent built-in
NICs. The built-ins on this board are tg3 and they must be on
a slow bus, because they cannot go faster than about 700Mbps
(using big pkts).
I'll benchmark things again when 2.6.13 comes out and try to
get some more detailed numbers...
Thanks,
Ben
--
Ben Greear [EMAIL
dropped.
Interestingly, the system is about 60% idle according to top,
and still dropping pkts, so it would seem that the system could
be better utilized!
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send th
dropped.
Interestingly, the system is about 60% idle according to top,
and still dropping pkts, so it would seem that the system could
be better utilized!
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line unsubscribe
-priority level like -18 or so.
You can also reserve more memory for the networking stack
and increase the size of the permitted buffers.
I am also interested to hear how your system responds to compiling
w/out PREEMPT.
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc
-priority level like -18 or so.
You can also reserve more memory for the networking stack
and increase the size of the permitted buffers.
I am also interested to hear how your system responds to compiling
w/out PREEMPT.
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http
I'll try the latest -mm and report back.
Thanks,
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordo
-Micro eventually reproduced the problem,
and told me
the fix was to send the MB back to them so they could solder another part
onto it I haven't received the MB back yet so I don't know if they
really
have a fix for it or not...
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologi
-Micro eventually reproduced the problem,
and told me
the fix was to send the MB back to them so they could solder another part
onto it I haven't received the MB back yet so I don't know if they
really
have a fix for it or not...
Ben
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc
201 - 300 of 478 matches
Mail list logo
