] ? rest_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
_write+0x19b/0x23a
[] ? n_tty_ioctl+0xc6/0xc6
[] redirected_tty_write+0x8a/0x95
[] vfs_write+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 linu
es this on a clean upstream build,
but I am still 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"
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).
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
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 t
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 cor
sizeof(setup->mcast_rate));
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
More majordomo info at http://vger.kernel.org/ma
return 0;
}
--
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 majordomo info at http://vger.kernel.org/majordomo-info.html
Pl
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 po
q+0x22/0x50
[ 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
Cande
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 an
port as the low
latency traffic at all.
Have you done any tests for bulk throughput with busy-poll? Yes, it will eat a
core,
but that might be worth it in some cases if there was significant throughput
increase...
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatec
1198unsigned int cflag = tty->termios->c_cflag;
1199
(gdb)
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
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
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
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
applica
managed to go through this
code within a single RCU period?
I think that if the rcu_assign_pointer logic wasn't 'published'
before a second thread came through this logic it could cause
this leakage?
The actual code I'm curious about is in net/mac80211/scan.c, in
the cfg80211_bss_
ut the atomic thread counter sits at 1, so no progress is ever made.
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg443471.html
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On 06/04/2013 09:53 AM, Ben Greear wrote:
On 06/04/2013 07:07 AM, Joe Lawrence wrote:
On Tue, 04 Jun 2013 15:26:28 +0930
Rusty Russell wrote:
Do you have a backtrace of the 3.9.4 crash? You can add "CFLAGS_module.o
= -O0" to get a clearer backtrace if you want...
Hi Rusty,
op forever.
Does this make sense?
Any ideas on how to fix this properly?
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
Mo
On 06/04/2013 02:18 PM, Ben Greear wrote:
I've been trying to figure out why I see the migration/* processes
hang in a busy loop
While reading the stop_machine.c file, I think I might have an
answer.
The set_state() method sets the thread_ack to the current number
of threads.
On 06/04/2013 09:41 PM, Rusty Russell wrote:
Ben Greear writes:
On 06/04/2013 02:18 PM, Ben Greear wrote:
I've been trying to figure out why I see the migration/* processes
hang in a busy loop
While reading the stop_machine.c file, I think I might have an
answer.
The set_state() m
On 06/05/2013 11:48 AM, Tejun Heo wrote:
Hello, Ben.
On Wed, Jun 05, 2013 at 09:59:00AM -0700, Ben Greear wrote:
One pattern I notice repeating for at least most of the hangs is that all but
one
CPU thread has irqs disabled and is in state 2. But, there will be one thread
in state 1 that
This is no longer really about the module unlink, so changing
subject.
On 06/05/2013 12:11 PM, Ben Greear wrote:
On 06/05/2013 11:48 AM, Tejun Heo wrote:
Hello, Ben.
On Wed, Jun 05, 2013 at 09:59:00AM -0700, Ben Greear wrote:
One pattern I notice repeating for at least most of the hangs is
On 06/05/2013 12:31 PM, Ben Greear wrote:
This is no longer really about the module unlink, so changing
subject.
On 06/05/2013 12:11 PM, Ben Greear wrote:
On 06/05/2013 11:48 AM, Tejun Heo wrote:
Hello, Ben.
On Wed, Jun 05, 2013 at 09:59:00AM -0700, Ben Greear wrote:
One pattern I notice
On 06/05/2013 02:11 PM, Tejun Heo wrote:
(cc'ing wireless crowd, tglx and Ingo. The original thread is at
http://thread.gmane.org/gmane.linux.kernel/1500158/focus=55005 )
Hello, Ben.
On Wed, Jun 05, 2013 at 01:58:31PM -0700, Ben Greear wrote:
Hmm, wonder if I found it. I previousl
nough if we can agree on the max
number of
loops (and if indeed my version of the patch is acceptable).
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
On 06/05/2013 08:46 PM, Eric Dumazet wrote:
On Wed, 2013-06-05 at 20:41 -0700, Ben Greear wrote:
On 06/05/2013 08:26 PM, Eric Dumazet wrote:
On Wed, 2013-06-05 at 20:14 -0700, Tejun Heo wrote:
Ah, so, that's why it's showing up now. We probably have had the same
issue all along b
On 06/06/2013 01:55 PM, Tejun Heo wrote:
Hello, Ben.
On Wed, Jun 05, 2013 at 08:41:01PM -0700, Ben Greear wrote:
On 06/05/2013 08:26 PM, Eric Dumazet wrote:
On Wed, 2013-06-05 at 20:14 -0700, Tejun Heo wrote:
Ah, so, that's why it's showing up now. We probably have had the same
t to add a link to the email thread.. The commit message
and patch has enough info that I think an interested party could find
the email thread easily enough if they needed more history.
And, much of the email thread is me running in circles thinking
I am going insane :)
Thanks,
Ben
--
Ben
On 06/13/2013 08:50 AM, Catalin Marinas wrote:
On Wed, Jun 12, 2013 at 01:28:13AM +0100, Ben Greear wrote:
On 06/11/2013 12:52 PM, Ben Greear wrote:
On 06/10/2013 03:32 PM, Catalin Marinas wrote:
On 10 June 2013 19:22, Ben Greear wrote:
We had a system go OOM while doing lots of wireless
t(kobj);
err = -EINVAL;
goto out;
}
--
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 majordomo i
On 05/30/2013 12:39 PM, Ben Greear wrote:
I'm seeing a crash (on hacked 3.9.3+ kernels). It's rare, but in a kernel
larded down with debugging, we are having some luck reproducing it.
Please note, this kernel is running a fair amount of my patches, so it could
be my bug. We did no
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
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
On 05/31/2013 12:22 PM, Ben Greear wrote:
While trying to verify that the kobject patch
(see "Please add to stable: module: don't unlink the module until we've removed all
exposure." email)
fixed the problems I was seeing, I hit what I believe is a different problem.
Much
On 05/31/2013 02:40 PM, Ben Greear wrote:
On 05/31/2013 12:22 PM, Ben Greear wrote:
While trying to verify that the kobject patch
(see "Please add to stable: module: don't unlink the module until we've removed all
exposure." email)
fixed the problems I was seeing, I hit
) related lockup still exists in 3.9.4 for me,
so I will also try applying that other kobject patch and continue testing
today...
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
On 06/03/2013 08:59 AM, Ben Greear wrote:
On 06/03/2013 07:17 AM, Joe Lawrence wrote:
Hi Rusty,
I had pointed Ben (offlist) to that bugzilla entry without realizing
there were other earlier related fixes in this space. Re-viewing bz-
58011, it looks like it was opened against 3.8.12, while
On 06/06/2013 02:40 PM, Tejun Heo wrote:
On Thu, Jun 06, 2013 at 02:29:49PM -0700, gree...@candelatech.com wrote:
From: Ben Greear
The stop machine logic can lock up if all but one of
the migration threads make it through the disable-irq
step and the one remaining thread gets stuck in
_call_rcu.clone.1+0x58/0x22a
[] call_rcu+0x17/0x19
[] put_object+0x46/0x4a
[] delete_object_full+0x2d/0x32
[] kmemleak_free+0x59/0x7a
[] slab_free_hook+0x21/0x87
[] kmem_cache_free+0xbe/0x15d
[] final_putname+0x38/0x3c
--
Ben Greear
Candela Technologies Inc http://www.c
On 06/10/2013 03:32 PM, Catalin Marinas wrote:
On 10 June 2013 19:22, Ben Greear wrote:
We had a system go OOM while doing lots of wireless
stations. (System had 8GB of RAM, so I suspect a leak).
I enabled kmemleak in a 3.9.5 (plus some local patches) and
I see the entries below. Any idea
On 06/10/2013 03:32 PM, Catalin Marinas wrote:
On 10 June 2013 19:22, Ben Greear wrote:
We had a system go OOM while doing lots of wireless
stations. (System had 8GB of RAM, so I suspect a leak).
I enabled kmemleak in a 3.9.5 (plus some local patches) and
I see the entries below. Any idea
On 06/11/2013 12:52 PM, Ben Greear wrote:
On 06/10/2013 03:32 PM, Catalin Marinas wrote:
On 10 June 2013 19:22, Ben Greear wrote:
We had a system go OOM while doing lots of wireless
stations. (System had 8GB of RAM, so I suspect a leak).
I enabled kmemleak in a 3.9.5 (plus some local
--
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 majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
On 06/29/2013 09:26 AM, Eric Dumazet wrote:
On Sat, 2013-06-29 at 09:11 -0700, Ben Greear wrote:
Do you know if your patch should go in 3.9?
Yes it should.
Ok, I'll add that to my tree.
Your test case sounds a bit like what gives us the rare crash in tcp_collapse
(we have lo
Seems there is a 64-bit division in there somewhere.
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
More majordomo inf
63 18
4c 39 e3 75 3c 48 8b 93 90 00 00 00 48
RIP [] shrink_dcache_for_umount_subtree+0x84/0x194
RSP
---[ end trace 9b2978a89532c292 ]---
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
On 03/05/2013 11:22 AM, Jeff Layton wrote:
On Tue, 5 Mar 2013 14:08:49 -0500
Jeff Layton wrote:
On Tue, 05 Mar 2013 10:54:56 -0800
Ben Greear wrote:
In doing some CIFS testing (utilizing it's feature to bind to local
address..but not sure that matters), we saw this error when trying
On 03/05/2013 01:09 PM, Jeff Layton wrote:
On Tue, 05 Mar 2013 11:42:46 -0800
Ben Greear wrote:
On 03/05/2013 11:22 AM, Jeff Layton wrote:
On Tue, 5 Mar 2013 14:08:49 -0500
Jeff Layton wrote:
On Tue, 05 Mar 2013 10:54:56 -0800
Ben Greear wrote:
In doing some CIFS testing (utilizing
timing related to netlink configuration/report requests?
We have lots of ways to measure wifi packet throughput latencies
and jitter (to/from userspace and/or to/from pktgen), but it doesn't use
netlink
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 04/10/2013 11:05 AM, Luis R. Rodriguez wrote:
On Wed, Apr 10, 2013 at 10:59 AM, Ben Greear wrote:
On 04/10/2013 10:55 AM, Luis R. Rodriguez wrote:
Curious if anyone has worked on latency and jitter benchmarks in using
netlink, specifically with nl80211. Has anyone benchmarked this? Ben
ry is removed?
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
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/08/2013 01:35 PM, Al Viro wrote:
On Wed, May 08, 2013 at 01:32:06PM -0700, Ben Greear wrote:
I'm seeing a crash when unloading the ath9k module.
It seems relay_close() is being passed bad memory.
The relay_open call uses an ath9k debugfs directory, so
that may be removed before the
pus with NMI
drm_kms_helper: panic occurred, switching back to text console
Rebooting in 10 seconds..
--
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.ker
just because some shit ends in your backyard.
We should rate-limit these messages at least. When a system is low on memory
the logs can quickly fill up with useless OOM messages, further slowing
the system...
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
On 05/28/2013 09:15 AM, Rafael Aquini wrote:
On Tue, May 28, 2013 at 09:00:45AM -0700, Ben Greear wrote:
On 05/27/2013 03:41 PM, Francois Romieu wrote:
atom...@redhat.com :
[...]
Failed GFP_ATOMIC allocations by the network stack result in dropped
packets, which will be received on a
On 03/07/2013 11:19 AM, Mateusz Guzik wrote:
On Tue, Mar 05, 2013 at 10:54:56AM -0800, Ben Greear wrote:
In doing some CIFS testing (utilizing it's feature to bind to local
address..but not sure that matters), we saw this error when trying
to un-mount.
Our kernel is patched (nfs,
t; Bret Indrelee | Sometimes, to be deep, we must act shallow!
> [EMAIL PROTECTED] | -Riff in The Quatrix
>
> -
> 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:
george anzinger wrote:
>
> Horst von Brand wrote:
> >
> > Ben Greear <[EMAIL PROTECTED]> said:
> >
> > [...]
> >
> > > Wouldn't a heap be a good data structure for a list of timers? Insertion
> > > is log(n) and finding the one wi
Jamie Lokier wrote:
>
> george anzinger wrote:
> > Horst von Brand wrote:
> > >
> > > Ben Greear <[EMAIL PROTECTED]> said:
> > >
> > > [...]
> > >
> > > > Wouldn't a heap be a good data structure for a list of tim
http://scry.wanfear.com/~greear/vlan.html
--
Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com (Released under GPL)
http://scry.wanfear.com http://scry.wanfear.com/~greear
-
To unsubscribe from this list: send the line "unsubscr
If I configure PCMCIA out of the build, the build will not link,
because the linker is still looking for the net_pcmcia.o file.
If I say yes for PCMCIA and enable a single module, it works.
compile configuration available if someone would like to see it.
Thanks,
Ben
--
Ben Greear ([EMAIL
hen I simply powered
down my machine with the HD light on solid...
Thanks,
Ben
--
Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com (Released under GPL)
http://scry.wanfear.com http://scry.wanfear.com/~greear
-
To unsubscribe
Becker */
RTL_W32_F (MAC0 + 0, cpu_to_le32 (*(u32 *) (dev->dev_addr + 0)));
RTL_W32_F (MAC0 + 4, cpu_to_le32 (*(u32 *) (dev->dev_addr + 4)));
The 2.2.18 driver is broken too, but I think Donald is going to send
the fixes for it.
Thanks,
Ben
--
Ben Greear ([EMAIL PROT
t so.
Sounds like a perfectly valid argument to me. Since Alan Cox's branch
seems to take on some of the more experimental stuff, perhaps it could
be used as an outlet for the pent-up patches untill 2.5 comes out?
Alan, could you elucidate your policy for accepting patches into the -ac
ser
dif
*dp = dev;
dev_hold(dev);
***
*** 2469,2473
write_lock_bh(&dev_base_lock);
*dp = d->next;
! write_unlock_bh(&dev_base_lock);
break;
}
--- 2777,2784
be added twice, once
+ * on initialization based on dev_base, and once again after that...
+ */
+__fdl_register_netdevice(dev);
+#endif
*dp = dev;
dev_hold(dev);
dev->deadbeaf = 0;
@@ -2468,7 +2776,10 @@
if (d == dev) {
Chris Wedgwood wrote:
>
> On Sat, Jan 06, 2001 at 02:33:27PM -0700, Ben Greear wrote:
>
> I'm hoping that I can get a few comments on this code. It was
> added to (significantly) speed up things like 'ifconfig -a' when
> running with 4000 or so V
Andi Kleen wrote:
>
> On Sat, Jan 06, 2001 at 02:33:27PM -0700, Ben Greear wrote:
> > I'm hoping that I can get a few comments on this code. It was added
> > to (significantly) speed up things like 'ifconfig -a' when running with
> > 4000 or so VLAN device
e suggest benchmarks you
consider valid.
Thanks,
Ben
--
Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com (Released under GPL)
http://scry.wanfear.com http://scry.wanfear.com/~greear
-
To unsubscribe from this list: send the
e paths are worth optimizing for.
The patch has been written, so even if it helps just a little more than it
hurts, it might be worth including. Of course, it may actually hurt more
than help.
I'd be very interested in lucid arguments as to why adding the patch would
actually be worse than
ferent from the rest of the
VLAN MACs on that physical interface. For OSPF you also need to
have multicast work on them, and other things that look very much like
a real interface.
Also, by making the VLANs a net_device, the rest of the kernel and
user-space code (ip, ifconfig, for example), works
ts.
What problem does this fix?
If you are mucking with the ifindex, you may be affecting many places
in the rest of the kernel, as well as user-space programs which use
ifindex to bind to raw devices.
On the other hand, the hash patch touches only one file, and should
not have any external impac
scan the map
Actually, VLAN code no longer uses this method to generate it's name,
it uses it's own mechanism (which, by the way, the hashed name lookup
makes much faster.) So, this part of the patch can be removed.
>
> Question: How do devices with hardware vlan support fit int
I make sure that it is second in the list?
>
> Register vlan in the top level protocol hash then have that yank the header
> and feed the packets through the hash again.
Thats what it already does, if I understand correctly. Of course, if VLAN
is loaded as a module, then it will be in
jamal wrote:
>
> On Sun, 7 Jan 2001, Ben Greear wrote:
>
> > > Question: How do devices with hardware vlan support fit into your model ?
> >
> > I don't know of any, and I'm not sure how they would be supported.
> >
>
> erm, this is a MU
> repeat for ip as well ;->
I can show a range w/out much trouble. I think I'll also tweak
the hash code to just do linear lookups if the number of interfaces
is below some number, (probably 20, or whatever the numbers show
is good...)
Ben
--
Ben Greear ([EMAIL PROTECTED]) htt
The only thing I ever thought of was the linear lookups,
which is why I wrote the hash code. The beauty of working with existing
user-space tools should not be over-looked!
It may be easier to fix other problems with many interface/net_devices
than cram a whole other virtual net_device structur
jamal wrote:
>
> On Sun, 7 Jan 2001, Ben Greear wrote:
>
> > Hrm, what if they just made each IP-SEC interface a net_device? If they
> > are a routable entity, with it's own IP address, it starts to look a lot
> > like an interface/net_device.
>
>
key player's minds, then
go ahead and tell me now so that I can go back to hacking code
and just include this patch with my VLAN patch.
Thanks,
Ben
--
Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com (Released unde
"David S. Miller" wrote:
>
>Date:Mon, 08 Jan 2001 01:12:21 -0700
> From: Ben Greear <[EMAIL PROTECTED]>
>
>http://grok.yi.org/~greear/hashed_dev.png
>(If you can't get to it, let me know and I'll email it to you...some
Andi Kleen wrote:
>
> On Mon, Jan 08, 2001 at 04:23:41PM +0100, Ben Greear wrote:
> > I don't argue that ifconfig shouldn't be fixed, but the hash speeds up
>
> It's already fixed since months. There was one stupid algorithm, which
> I was to blame for whe
he better solutions?
And what does your dislike for sales and management have to do with
the topic at hand?
--
Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com (Released under GPL)
http://scry.wanfear.com http://scry.wanfea
dev->name, dev->vlan_dev->real_dev->name);
dev_set_promiscuity(dev->vlan_dev->real_dev, 1);
}
}
else {
printk("VLAN (%s): Underlying device (%s) has same MAC, not checking
promiscious m
dule.)
For comparison, there is also another VLAN project at
http://vlan.sourceforge.net, but I think mine is better, or
at least has a more colorful web-page! :)
Comments are welcome.
Thanks,
Ben
--
Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com
, but an ioctl or
similar call would be OK. I'd even settle for some other tool,
like 'ip', if I could just figure out what commands to tell it.
Thanks,
Ben
--
Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com (Rele
ONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VIDEO_SELECT is not set
# CONFIG_MDA_CONSOLE is not set
# CONFIG_FB is not set
#
# Sound
#
# CONFIG_SO
much more powerful, and send the code back to me!
vconfig.c has been converted to C code now, instead of C++.
Thanks to MATHIEU.
Significantly cleaned up the code w/out decreasing any useful
functionality, I believe.
--
Ben Greear ([EMAI
files that you can add to procfs
in a single directory?
Suggestions welcome...
Thanks,
Ben
--
Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com (Released under GPL)
http://scry.wanfear.com http://scry.wanfear.com/~greear
?
Enjoy,
Ben
>
> -
> 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 at http://www.tux.org/lkml/
--
Ben Greea
hardware?
For the power/insane user, there could be a --really-do-stupid-thing-i-told-you-to
option, and it should be that hard to type!!
Ben
--
Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com (Released under GPL)
http://scr
Alexander Viro wrote:
>
> On Wed, 7 Mar 2001, Ben Greear wrote:
>
> > However, messing with the hdparms options can do random things, at
> > least from my perspective as a user: It may bring exciting new performance
> > to your system, and it may subtly, or not s
LANs. You can now change the MAC
address on a VLAN with my patch: http://scry.wanfear.com/~greear/vlan.html
Ben
--
Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com (Released under GPL)
http://scry.wanfear.com http://scry.w
David Weis wrote:
>
> On Tue, 23 Jan 2001, Ben Greear wrote:
> > David Weis wrote:
> > > what would be required to make the mac address of aliases changable,
> > > specifically for something like vrrp that shares a mac address among
> > > machines.
> >
hanks,
Ben
--
Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com (Released under GPL)
http://scry.wanfear.com http://scry.wanfear.com/~greear
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
roadcom Corporation BCM5705M 10/100/1000Base T
(rev 02)
--
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
Super-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]>
Can
l.org
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]
Mo
1 - 100 of 251 matches
Mail list logo
