On Mon, May 15, 2006 at 11:57:12PM -0700, David S. Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Tue, 16 May 2006 10:19:09 +0400
>
> > +static int netchannel_convert_skb_ipv4(struct sk_buff *skb, struct
> > unetchannel *unc)
> > +{
> ...
> > + switch (
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Tue, 16 May 2006 10:19:09 +0400
> +static int netchannel_convert_skb_ipv4(struct sk_buff *skb, struct
> unetchannel *unc)
> +{
...
> + switch (unc->proto) {
> + case IPPROTO_TCP:
...
> + case IPPROTO_UDP:
...
Why do
Let me also bring attention to another netchannel implementation.
Some design notes [blog copypasts, sorry if it is out of sync sometimes].
First of all, do not use sockets. Just forget that such interface
exists.
New receiving channel abstraction will be created by special syscall,
which allows
From: Kelly Daly <[EMAIL PROTECTED]>
Date: Tue, 16 May 2006 11:02:29 +1000
> +/* handles default chan buffers that nobody else wants */
> +static int default_netchannel_thread(void *unused)
> +{
> + wait_queue_t wait;
> + struct netchannel_buftrailer *bp;
> + struct sk_buff *skbp;
> +
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Mon, 15 May 2006 16:28:58 -0700
> There is a potential jiffy wraparound bug in the transmit watchdog
> that is easily avoided by using time_after().
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Applied, thanks Stephen.
-
To unsubscrib
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 16 May 2006 03:22:21 +0200
> Patrick McHardy wrote:
> > 3) Clone the skb and have dev_queue_xmit_nit() consume it.
> >
> > That should actually be pretty easy.
>
> On second thought, thats not so great either. netdev_nit
> just globally signal
On Tue, May 16, 2006, Jouni Malinen wrote:
> Some hardware designs disable the radio in hardware, some
> don't.. In other words, the behavior would not be consistent
> between hardware designs unless the radio would be disabled
> unconditionally in software-processed case. I would like to
> be
There are cases where rx errors were found due to rx ring size being too
small
during remote installation using pcnet32. It is found that ethtool
functionality
may not be available under such circumenstance. This is the purpose behind
this patch.
However, as Don pointed out, there are several p
Carl-Daniel Hailfinger wrote:
Hi Jeff,
IIRC you had "too many iterations (6) in nv_nic_irq" appear regularly
in your dmesg with kernel 2.6.16. Did this disappear in more recent
kernels? If not, can you try the disable_msi and disable_msix module
parameters if they help in your case?
Yes, it di
I cannot think of another possible definition for thread-safe in the
context of these functions. Certainly they should not cause a "crash" when
called from multiple threads, but that's a requirement independent of
thread-safety. The POSIX specification doesn't mention atomicity with
respect to the
Patrick McHardy wrote:
> 3) Clone the skb and have dev_queue_xmit_nit() consume it.
>
> That should actually be pretty easy.
On second thought, thats not so great either. netdev_nit
just globally signals that there are some taps, but we
don't know if they're interested in a specific packet.
-
To
On Tue, May 16, 2006 at 03:17:59AM +0200, Patrick McHardy wrote:
>
> 3) Clone the skb and have dev_queue_xmit_nit() consume it.
>
> That should actually be pretty easy.
Unfortunately that would mean an unconditional copy for all TSO packets
on NICs such as tg3/e1000. These drivers have to modify
Herbert Xu wrote:
> David S. Miller <[EMAIL PROTECTED]> wrote:
>
>>Other implementation possibility suggestions welcome :-)
>
>
> I see two possibilities:
>
> 1) Move the af_packet hook into the NIC driver.
> 2) Rethink the lockless tx setup. If all NICs followed the tg3 and
>replaced spin
On Tuesday 16 May 2006 11:05, David S. Miller wrote:
> From: Kelly Daly <[EMAIL PROTECTED]>
> Date: Tue, 16 May 2006 11:02:29 +1000
>
> > On Friday 05 May 2006 12:48, Kelly Daly wrote:
> > > done! I will continue with implementation of default netchannel for
> > > now.
>
> Some context? It's been
From: Kelly Daly <[EMAIL PROTECTED]>
Date: Tue, 16 May 2006 11:02:29 +1000
> On Friday 05 May 2006 12:48, Kelly Daly wrote:
> > done! I will continue with implementation of default netchannel for now.
Some context? It's been a week since we were discussing this,
so I'd like to know what we're l
On Friday 05 May 2006 12:48, Kelly Daly wrote:
> done! I will continue with implementation of default netchannel for now.
___
diff -urp davem_orig/include/net/inet_hashtables.h
kelly/include/net/inet_hashtables.h
--- davem_orig/include/net/inet_hashtables.h2006-04-27 00:08:
On Tue, May 16, 2006 at 02:21:27AM +0200, Patrick McHardy wrote:
> David S. Miller wrote:
> > From: Stephen Hemminger <[EMAIL PROTECTED]>
> > Date: Mon, 15 May 2006 16:41:01 -0700
> >
> >
> >>kfree_skb(NULL) is legal so the conditional here is unneeded.
> >>
> >>But the increased calls to kfree_s
Mark A Smith wrote:
Hi Rick, Stephen,
The thread-safe claim is at:
http://devrsrc1.external.hp.com/STKS/cgi-bin/man2html?manpage=/usr/share/man/man2.Z/send.2
Specifically,
"
MULTITHREAD USAGE
The send(), sendmsg(), and sendto() system calls are thread-safe.
They each have a cancel
David S. Miller <[EMAIL PROTECTED]> wrote:
>
> Other implementation possibility suggestions welcome :-)
I see two possibilities:
1) Move the af_packet hook into the NIC driver.
2) Rethink the lockless tx setup. If all NICs followed the tg3 and
replaced spin_lock_irqsave with spin_lock then w
David S. Miller wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Mon, 15 May 2006 16:41:01 -0700
>
>
>>kfree_skb(NULL) is legal so the conditional here is unneeded.
>>
>>But the increased calls to kfree_skb(NULL) would probably bring the
>>"unlikely()" hordes descending on kfree_skb,
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Mon, 15 May 2006 16:41:01 -0700
> kfree_skb(NULL) is legal so the conditional here is unneeded.
>
> But the increased calls to kfree_skb(NULL) would probably bring the
> "unlikely()" hordes descending on kfree_skb, so maybe:
And unfortunately as
I presume this is only for "blocking" sockets? I cannot at least off
the top of my head see how a stack could offer it on non-blocking sockets.
The test seems to be based on sending a big message. In this case,
on non-blocking sockets, the send call will return partial status. The
return from
On Mon, 15 May 2006 16:11:05 -0700 (PDT)
Ranjit Manomohan <[EMAIL PROTECTED]> wrote:
> On Mon, 15 May 2006, David S. Miller wrote:
>
> > From: Ranjit Manomohan <[EMAIL PROTECTED]>
> > Date: Mon, 15 May 2006 14:19:06 -0700 (PDT)
> >
> > > Heres a new version which does a copy instead of the clone
On Mon, 15 May 2006 16:17:48 -0700
Rick Jones <[EMAIL PROTECTED]> wrote:
> David S. Miller wrote:
> > From: Mark A Smith <[EMAIL PROTECTED]>
> > Date: Mon, 15 May 2006 14:39:06 -0700
> >
> >
> >>I discovered that in some cases, send(), sendmsg(), and sendto() are not
> >>thread-safe. Although th
Skge driver always causes bad checksums on big-endian.
The checksum in the receive control block was being swapped
when it doesn't need to be.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- skge-2.6.orig/drivers/net/skge.c
+++ skge-2.6/drivers/net/skge.c
@@ -2717,8 +2717,7 @@ static in
The driver will get stuck (permanent transmit timeout), if the transmit
ring size is set too small. It needs to have enough ring elements to
hold one maximum size transmit.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- skge-2.6.orig/drivers/net/skge.c
+++ skge-2.6/drivers/net/skge.c
There is a potential jiffy wraparound bug in the transmit watchdog
that is easily avoided by using time_after().
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- linux-2.6.orig/net/sched/sch_generic.c
+++ linux-2.6/net/sched/sch_generic.c
@@ -193,8 +193,10 @@ static void dev_watchdog(uns
David S. Miller wrote:
From: Mark A Smith <[EMAIL PROTECTED]>
Date: Mon, 15 May 2006 14:39:06 -0700
I discovered that in some cases, send(), sendmsg(), and sendto() are not
thread-safe. Although the man page for these functions does not specify
whether these functions are supposed to be thread
On Mon, 15 May 2006, David S. Miller wrote:
> From: Ranjit Manomohan <[EMAIL PROTECTED]>
> Date: Mon, 15 May 2006 14:19:06 -0700 (PDT)
>
> > Heres a new version which does a copy instead of the clone to avoid
> > the double cloning issue.
>
> I still very much dislike this patch because it is cr
David S. Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Mon, 15 May 2006 14:39:23 -0700
How about:
How about, just leave it alone? :-)
That would work too :) but I guess I figured based on the reason given
just before I posted, for why setting to L1_CACHE_SIZE was wrong that
t
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 1/drivers/net/e1000/e1000_main.c
+++ 1/drivers/net/e1000/e1000_main.c
@@ -2451,7 +2451,7 @@ e1000_tso(struct e1000_adapter *adapter,
From: Rick Jones <[EMAIL PROTECTED]>
Date: Mon, 15 May 2006 14:39:23 -0700
> How about:
How about, just leave it alone? :-)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-in
From: Mark A Smith <[EMAIL PROTECTED]>
Date: Mon, 15 May 2006 14:39:06 -0700
> I discovered that in some cases, send(), sendmsg(), and sendto() are not
> thread-safe. Although the man page for these functions does not specify
> whether these functions are supposed to be thread-safe, my reading of
-->"Stephen" == Stephen Hemminger <[EMAIL PROTECTED]> writes:
>> i've been getting semi-regular lockups on my machine over 2.6.16
>> series. I recently attached a serial console in an attempt to
>> capture an OOPS.
Stephen> Could you retest with the v1.5 version that is 2.6.17-rc3?
usin
On Mon, 15 May 2006 14:39:23 -0700
Rick Jones <[EMAIL PROTECTED]> wrote:
> David S. Miller wrote:
> > From: "Randy.Dunlap" <[EMAIL PROTECTED]>
> > Date: Mon, 15 May 2006 08:02:58 -0700
> >
> >
> >>>-#define NETDEV_ALIGN32
> >>>+#define NETDEV_ALIGNL1_CACHE_BYTES
> >>>
On Mon, May 15, 2006 at 02:40:14PM -0700, Jouni Malinen wrote:
> On Mon, May 15, 2006 at 01:28:13PM -0700, Jean Tourrilhes wrote:
>
> > I believe the BSSID has to be unique. HP APs can also offer
> > multiple ESSID for the same BSSID, but they do so using different
> > BSSID. If you look at th
David S. Miller wrote:
From: "Randy.Dunlap" <[EMAIL PROTECTED]>
Date: Mon, 15 May 2006 08:02:58 -0700
-#defineNETDEV_ALIGN32
+#defineNETDEV_ALIGNL1_CACHE_BYTES
#define NETDEV_ALIGN_CONST (NETDEV_ALIGN - 1)
I don't know about the fixed value of 32,
On Mon, May 15, 2006 at 01:28:13PM -0700, Jean Tourrilhes wrote:
> I believe the BSSID has to be unique. HP APs can also offer
> multiple ESSID for the same BSSID, but they do so using different
> BSSID. If you look at the 802.11 spec, I can't see how two different
> virtual cells can have t
David S. Miller wrote:
> From: Ranjit Manomohan <[EMAIL PROTECTED]>
> Date: Mon, 15 May 2006 14:19:06 -0700 (PDT)
>
>
>>Heres a new version which does a copy instead of the clone to avoid
>>the double cloning issue.
>
>
> I still very much dislike this patch because it is creating
> 1 more clon
On Monday 15 May 2006 21:46, Jason Lunz wrote:
> On Mon, May 15, 2006 at 03:12:50PM -0400, Dan Williams wrote:
> > When those bits get set in the register, is the radio already disabled?
> > ie, for the bcm43xx chip, is it really force-disabled by the button, or
> > does the driver have some contro
From: "Randy.Dunlap" <[EMAIL PROTECTED]>
Date: Mon, 15 May 2006 08:02:58 -0700
> > -#defineNETDEV_ALIGN32
> > +#defineNETDEV_ALIGNL1_CACHE_BYTES
> > #defineNETDEV_ALIGN_CONST (NETDEV_ALIGN - 1)
>
> I don't know about the fixed value of 32, but if this pat
On Sun, 14 May 2006, David S. Miller wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Sun, 14 May 2006 03:10:34 -0700
>
> > It's a bit sad to be taking a clone of a clone like this.
> > Avoidable?
>
> Besides, clones of clones are illegal, if it's already a clone
> you must make a copy.
From: Ranjit Manomohan <[EMAIL PROTECTED]>
Date: Mon, 15 May 2006 14:19:06 -0700 (PDT)
> Heres a new version which does a copy instead of the clone to avoid
> the double cloning issue.
I still very much dislike this patch because it is creating
1 more clone per packet than is actually necessary a
Dnia poniedziałek, 15 maja 2006 22:06, John W. Linville napisał:
> On Fri, May 12, 2006 at 04:43:30PM -0400, Pavel Roskin wrote:
> > As a co-maintainer of Orinoco driver, I'd like to ask the netdev team
> > not to apply any patch from Marcin Juszkiewicz touching the Orinoco
> > driver without my or
On Sun, May 14, 2006 at 11:29:38PM -0400, Dan Williams wrote:
> On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote:
> > Hi Jean,
Hi,
Nice discussion you got going here ;-)
> > I'd just like to check my understanding (and softmacs implementation)
> > of SIWESSID and SIWAP beha
On Mon, May 15, 2006 at 03:27:54PM +, Jason Lunz wrote:
> So if there's any desire for consistency of wireless button support,
> then I think the software-controlled ones should always shut off the
> radio, and optionally inform userspace or the wireless stack using some
> event mechanism.
FW
On Fri, May 12, 2006 at 04:43:30PM -0400, Pavel Roskin wrote:
> As a co-maintainer of Orinoco driver, I'd like to ask the netdev team
> not to apply any patch from Marcin Juszkiewicz touching the Orinoco
> driver without my or David's explicit approval.
I plan to honor this request. Are there an
Ah OK, I thought it was related to the new compat code, but that isn't
the case. Your trace doesn't give much clues, except that it shows that
iptables dies with a SIGSEGV, which might be a bug in userspace or in
the kernel. Which was the last kernel that worked for you, and can you
try that versi
On Mon, May 15, 2006 at 03:12:50PM -0400, Dan Williams wrote:
> When those bits get set in the register, is the radio already disabled?
> ie, for the bcm43xx chip, is it really force-disabled by the button, or
> does the driver have some control?
I assume it disables the radio without any help fro
Meelis Roos wrote:
This should already be fixed in -rc4.
>>>
>>>
>>> Unfortunately it was still there with yesterdays rc4+git.
>>
>>
>> I may have misinterpreted your report - are you running a 32bit or 64bit
>> kernel?
>
>
> 32-bit kernel, this is a Motorola Powerstack II macine with 604e.
On Thu, 27 Apr 2006 00:24:11 +0200
Lennert Buytenhek <[EMAIL PROTECTED]> wrote:
> The ixp2000 driver for the enp2611 was developed on a board with
> three gigabit ports, but some enp2611 models only have two ports
> (and only one onboard PM3386.) The current driver assumes there
> are always thre
On Monday 15 May 2006 21:12, you wrote:
> > There are registers on the bcm43xx chip (0x158 and 0x49A) that indicate
> > some "Radio is hardware-disabled" state. We currently don't use that flag
> > correctly in the driver. Could you please assist me on testing if your
> > switch
> > actually toggl
This should already be fixed in -rc4.
Unfortunately it was still there with yesterdays rc4+git.
I may have misinterpreted your report - are you running a 32bit or 64bit
kernel?
32-bit kernel, this is a Motorola Powerstack II macine with 604e. PReP
subarch, only buildable from the old ARCH=p
On Mon, 2006-05-15 at 18:01 +0200, Michael Buesch wrote:
> On Monday 15 May 2006 17:27, you wrote:
> > [EMAIL PROTECTED] said:
> > > Some people are saying that instead of throwing and ACPI event we should
> > > be
> > > either use hotplug or internally just disable the radio and somehow inform
>
Meelis Roos wrote:
>>> Iptables seems to be broken on ppc for me. Kernel 2.6.17-rc3 (currently
>>> compiling rc4+git). 32-bit ppc, ARCH=ppc with PReP target. Iptables
>>> userland binary is from the latest Debian unstable (1.3.3-2).
>>>
>>> The symptoms: iptables usually just tells Invalid Argument
On Monday 15 May 2006 07:37, Jiri Benc wrote:
> This issue can be easily solved by not masking hw_modes by
> valid_hw_modes in ieee80211_ioctl_prism2_param and
> ieee80211_precalc_modes. Just check (hw_modes & valid_hw_modes) instead
> of hw_modes in ieee80211_sta_scan_timer.
>
> And yes, hw_modes
Lee Revell wrote:
> On Fri, 2006-05-12 at 01:53 +0200, Brice Goglin wrote:
>
>> Francois Romieu wrote:
>>
+ spin_lock(&mgp->cmd_lock);
+ response->result = 0x;
+ mb();
+ myri10ge_pio_copy((void __iomem *) cmd_addr, buf, sizeof (*buf));
+
+ /* wait
vaarikas:~# ip -6 route
2002:5283:297e::/48 dev tun6to4 metric 256 expires 21332659sec mtu 1480
advmss 1420 hoplimit 4294967295
You're using the wrong prefix length. The right one is /16. Does that work?
Changed tun6to4 to 2002::/16, still the same (packets for eth0 and the
unreachable de
vaarikas:~# ip -6 route
2002:5283:297e::/48 dev tun6to4 metric 256 expires 21332659sec mtu 1480
advmss 1420 hoplimit 4294967295
You're using the wrong prefix length. The right one is /16. Does that work?
Will try soon today. But the other routes had mor specific masks anyway -
/64 and /12
Iptables seems to be broken on ppc for me. Kernel 2.6.17-rc3 (currently
compiling rc4+git). 32-bit ppc, ARCH=ppc with PReP target. Iptables
userland binary is from the latest Debian unstable (1.3.3-2).
The symptoms: iptables usually just tells Invalid Argument on any
modification attempt. I'm try
On Fri, 2006-05-12 at 01:53 +0200, Brice Goglin wrote:
> Francois Romieu wrote:
> >
> >> + spin_lock(&mgp->cmd_lock);
> >> + response->result = 0x;
> >> + mb();
> >> + myri10ge_pio_copy((void __iomem *) cmd_addr, buf, sizeof (*buf));
> >> +
> >> + /* wait up to 2 seconds */
> >>
>
On Mon, May 15, 2006 at 05:12:20PM +0200, Ivo van Doorn wrote:
> Well I would think it is cleaner to inform userspace that the button is
> pressed
> and let userspace sort out what exactly should happen.
> But I doubt it will be a good idea when the driver is sending and event _and_
> disabled th
Needed for interaction with the nommu code in x86-64 which
will return bad_dma_address if the address exceeds dma_mask.
Cc: netdev@vger.kernel.org
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
---
drivers/net/b44.c | 28 ++--
1 files changed, 18 insertions(+), 10 dele
On Mon, 2006-05-15 at 10:37 -0400, Dan Williams wrote:
> Ideally, here's what would happen: the driver/card/whatever generates
> an ACPI event, which is noticed by HAL. HAL sets a property on the
> _exact_ device which the event is for, and propagates the signal out
> over dbus. Any interested a
Why is this necessary? There is already an ethtool function to set
the rx ring size (pcnet32_set_ringparam). Since module parameters
are being phased out in favor of the ethtool functions, why not use
the existing ethtool infrastructure for this?
Thanks,
Jon
On Mon, May 15, 2006 at 11:32:14AM +
On Monday 15 May 2006 17:27, you wrote:
> [EMAIL PROTECTED] said:
> > Some people are saying that instead of throwing and ACPI event we should be
> > either use hotplug or internally just disable the radio and somehow inform
> > the dscape stack that the radio has been disabled.
> >
> > What are pe
On Mon, 15 May 2006, Meelis Roos wrote:
On my home 6to4 gw, ipv6 routing seems to be broken and everything is sent to
6to4 tunnel (the default route). It worked with fine for a long time and with
2.6.17-rc2-g4d5c34ec and it's broken with vmlinuz-2.6.17-rc3-g3cd73eed and
2.6.17-rc4-g9be2f7c3 (ye
I have several problems with this patch. First, it assumes you only have
one device or you want all devices to operate with the same receive ring
size. (use module_param_array like full_duplex or options).
Second, the mininum number of descriptors should be 4 not 2, or the
loopback test will loo
[EMAIL PROTECTED] said:
> Some people are saying that instead of throwing and ACPI event we should be
> either use hotplug or internally just disable the radio and somehow inform
> the dscape stack that the radio has been disabled.
>
> What are peoples thoughts here, should we
>
> A. be handling t
On Monday 15 May 2006 16:37, Dan Williams wrote:
> On Mon, 2006-05-15 at 22:57 +1000, Mark Wallis wrote:
> > Hi everyone,
> >
> > Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> > ACPI event so that the hardware button can be handled in userspace. This
> > allows the
On Mon, 15 May 2006 14:08:29 +0200 Christian Borntraeger wrote:
> while digging through the alloc_netdev function I asked myself why there is a
> fixed alignment for netdevices. Is there a special reason for choosing 32? If
> yes, I suggest to add a comment to the definition.
>
> If not, I suspe
On Mon, 2006-05-15 at 22:57 +1000, Mark Wallis wrote:
> Hi everyone,
>
> Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> ACPI event so that the hardware button can be handled in userspace. This
> allows the user to basically do whatever they want when this button is
>
On Mon, 2006-05-15 at 06:16 -0700, Jouni Malinen wrote:
> On Sun, May 14, 2006 at 11:29:38PM -0400, Dan Williams wrote:
> > On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote:
> > > When SIWESSID happens, softmac drops association/authentication with the
> > > current network and then starts a
On Mon, 15 May 2006 16:01:48 +0200, Michael Buesch wrote:
> No, We must allocate the ieee80211_hw, before we can attach the board.
> But before we attached the board, we don't know what hardware it is.
> Sure, this can be worked around by some very ugly hack (It was done
> in an early version of th
On Mon, 15 May 2006 22:57:12 +1000 Mark Wallis wrote:
> What are peoples thoughts here, should we
>
> A. be handling this within our drivers and doing "what the user expects" and
> disabling the hardware radio, or
>
> B. should we be firing an ACPI event and getting the distro's to add scripts
On Monday 15 May 2006 15:35, you wrote:
> [removed some people from Cc: list as this is probably not much
> interesting for them]
>
> On Mon, 15 May 2006 14:04:44 +0200, Johannes Berg wrote:
> > On Mon, 2006-05-15 at 13:37 +0200, Jiri Benc wrote:
> > > bcm43xx does that. If I understand it correctl
On Monday 15 May 2006 15:25, Jiri Benc wrote:
> On Mon, 15 May 2006 22:57:12 +1000, Mark Wallis wrote:
> > Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> > ACPI event so that the hardware button can be handled in userspace. This
> > allows the user to basically do wha
[removed some people from Cc: list as this is probably not much
interesting for them]
On Mon, 15 May 2006 14:04:44 +0200, Johannes Berg wrote:
> On Mon, 2006-05-15 at 13:37 +0200, Jiri Benc wrote:
> > bcm43xx does that. If I understand it correctly, bcm43xx driver doesn't
> > know allowed modes un
On Mon, 15 May 2006 22:57:12 +1000, Mark Wallis wrote:
> Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> ACPI event so that the hardware button can be handled in userspace. This
> allows the user to basically do whatever they want when this button is
> pressed - includ
On Sun, May 14, 2006 at 11:29:38PM -0400, Dan Williams wrote:
> On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote:
> > When SIWESSID happens, softmac drops association/authentication with the
> > current network and then starts a scan for the requested SSID. When
> > found, softmac authentica
Hi everyone,
During our development of the rt2x00 wireless driver we have come across an
interesting issue that we want to get comment on from the netdev-community.
Some laptops with our Ralink cards build-in also include a hardware button
that is meant to enable/disable the wireless card. We are
On Sun, 2006-05-14 at 02:03 -0400, James Morris wrote:
> Included below is an incremental patch against the initial secmark posting
> last week: http://thread.gmane.org/gmane.linux.network/34927/focus=34927
>
> This posting to gather feedback on changes made since then primarily to
> address con
while digging through the alloc_netdev function I asked myself why there is a
fixed alignment for netdevices. Is there a special reason for choosing 32? If
yes, I suggest to add a comment to the definition.
If not, I suspect cacheline alignment might be beneficial:
struct net_device contains seve
On Mon, 2006-05-15 at 13:37 +0200, Jiri Benc wrote:
>
> bcm43xx does that. If I understand it correctly, bcm43xx driver doesn't
> know allowed modes until it loads firmware. And the firmware is not
> loaded until the device is opened (they probably have a reason for
> this).
No, that's not right
On Fri, 12 May 2006 16:35:27 -0400, Michael Wu wrote:
> Hm, so why not add something that will tell you what modes are supported by
> the hardware?
Sounds reasonable.
> Only problem with this patch is if the hardware adds any modes after
> registration, they will be disabled initially. Hopefull
85 matches
Mail list logo
