date:20060611


[EMAIL PROTECTED] wrote:

From: Ingo Molnar [EMAIL PROTECTED]

Barry K. Nathan reported the following lockdep warning:

[  197.343948] BUG: warning at kernel/lockdep.c:1856/trace_hardirqs_on()
[  197.345928]  [c010329b] show_trace_log_lvl+0x5b/0x105
[  197.346359]  [c0103896] show_trace+0x1b/0x20
[  197.346759]  [c01038ed] dump_stack+0x1f/0x24
[  197.347159]  [c012efa2] trace_hardirqs_on+0xfb/0x185
[  197.348873]  [c029b009] _spin_unlock_irq+0x24/0x2d
[  197.350620]  [e09034e8] do_tx_done+0x171/0x179 [ns83820]
[  197.350895]  [e090445c] ns83820_irq+0x149/0x20b [ns83820]
[  197.351166]  [c013b4b8] handle_IRQ_event+0x1d/0x52
[  197.353216]  [c013c6c2] handle_level_irq+0x97/0xe1
[  197.355157]  [c01048c3] do_IRQ+0x8b/0xac
[  197.355612]  [c0102d9d] common_interrupt+0x25/0x2c


The driver's locking is definitely wrong, but I don't think this is the 
fix, because PCI drivers with a single interrupt should be using 
spin_lock() in the interrupt handler.  Anything more would be uncivilized :)


/me starts to do a better patch...

Jesus, the locking here is awful.  No wonder there are bugs.

Since this driver isn't seeing a ton of work these days, I think the 
best thing to do would be to _simplify_ the locking.  This driver is 
grabbing so many locks, turning interrupts off+on so often that any 
benefit the multiple locks had is probably long gone, particularly on 
modern machines.


Let me see what I can do with it...

Jeff


-
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-info.html

Re: [patch 7/8] lock validator: fix ns83820.c irq-flags bug

2006-06-11 Thread Arjan van de Ven


Jeff Garzik wrote:
The driver's locking is definitely wrong, but I don't think this is the 
fix, 


it's an obvious correct fix in the correctness sense though...



Jesus, the locking here is awful.  No wonder there are bugs.



... which given that fact, is for 2.6.17 probably the right thing, pending
a nicer fix for 2.6.18

I fully agree with you that the locking is trying to be WAAAY too smart
for it's own good, and that a much simpler scheme is called for.

-
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-info.html

Re: [RFC ] [2 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - database

2006-06-11 Thread Larry Finger


Hi Uli,

Thanks for the comments.

Ulrich Kunitz wrote:


two minor comments.

1. I appreciate that you are keeping everything in 80 character
   lines. So I believe the one line extending 80 characters is an
   oversight.


I have tried, but will watch that more carefully.



2. Could you just add a simple explanation for the pow column for
   the uninformed reader?


It was described in the initial text material that was not sent out. I have duplicated that info at 
the beginning of each type of group description, and have added it to the header on the debug output 
as follows:


AT, HR, CY, CZ, DK, EE, EU, FI, FR, GF, DE, VA, HU, IE, IT, LV, LT, LU, MK, MT
NL, PL, RE, SI, SE, GB

Indoor Group 1 with 18 channels in 5 GHz bands

  Chn  Freq Pow(dBm)   Flags
   36  518023  PASSIVE   H_RULES
   40  520023  PASSIVE   H_RULES
   44  522023  PASSIVE   H_RULES
   48  524023  PASSIVE   H_RULES
   52  526023  PASSIVE   H_RULES


Larry
-
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-info.html

[PATCH] SoftMAC: Prevent multiple authentication attempts on the same network

2006-06-11 Thread Joseph Jezak

This patch addresses the No queue exists messages commonly seen during
authentication and associating.  These appear due to scheduling multiple
authentication attempts on the same network.  To prevent this, I added a
flag to stop multiple authentication attempts by the association layer.
I also added a check to the wx handler to see if we're connecting to a
different network than the one already in progress.  This scenario was
causing multiple requests on the same network because the network BSSID
was not being updated despite the fact that the ESSID changed.

Signed-off-by: Joseph Jezak [EMAIL PROTECTED]

---

diff --git a/include/net/ieee80211softmac.h b/include/net/ieee80211softmac.h
index 052ed59..82a299a 100644
--- a/include/net/ieee80211softmac.h
+++ b/include/net/ieee80211softmac.h
@@ -101,6 +101,7 @@ struct ieee80211softmac_assoc_info {
 */
u8 static_essid:1,
   associating:1,
+  assoc_wait:1,
   bssvalid:1,
   bssfixed:1;
 
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c 
b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index 57ea9f6..aa65a7e 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -47,9 +47,7 @@ ieee80211softmac_assoc(struct ieee80211s

dprintk(KERN_INFO PFX sent association request!\n);
 
-   /* Change the state to associating */
spin_lock_irqsave(mac-lock, flags);
-   mac-associnfo.associating = 1;
mac-associated = 0; /* just to make sure */
 
/* Set a timer for timeout */
@@ -181,6 +179,10 @@ ieee80211softmac_assoc_work(void *d)
/* meh */
if (mac-associated)
ieee80211softmac_disassoc(mac, 
WLAN_REASON_DISASSOC_STA_HAS_LEFT);
+   
+   spin_lock_irqsave(mac-lock, flags);
+   mac-associnfo.associating = 1;
+   spin_unlock_irqrestore(mac-lock, flags);
 
/* try to find the requested network in our list, if we found one 
already */
if (mac-associnfo.bssvalid || mac-associnfo.bssfixed)
@@ -274,19 +276,32 @@ ieee80211softmac_assoc_work(void *d)
memcpy(mac-associnfo.associate_essid.data, found-essid.data, 
IW_ESSID_MAX_SIZE + 1);

/* we found a network! authenticate (if necessary) and associate to it. 
*/
-   if (!found-authenticated) {
+   if (found-authenticating) {
+   dprintk(KERN_INFO PFX Already requested authentication, 
waiting...\n);
+   if(!mac-associnfo.assoc_wait) {
+   mac-associnfo.assoc_wait = 1;
+   ieee80211softmac_notify_internal(mac, 
IEEE80211SOFTMAC_EVENT_ANY, found, ieee80211softmac_assoc_notify, NULL, 
GFP_KERNEL);
+   }
+   return;
+   }
+   if (!found-authenticated  !found-authenticating) {
/* This relies on the fact that _auth_req only queues the work,
 * otherwise adding the notification would be racy. */
if (!ieee80211softmac_auth_req(mac, found)) {
-   dprintk(KERN_INFO PFX cannot associate without being 
authenticated, requested authentication\n);
-   ieee80211softmac_notify_internal(mac, 
IEEE80211SOFTMAC_EVENT_ANY, found, ieee80211softmac_assoc_notify, NULL, 
GFP_KERNEL);
+   if(!mac-associnfo.assoc_wait) {
+   dprintk(KERN_INFO PFX Cannot associate without 
being authenticated, requested authentication\n);
+   mac-associnfo.assoc_wait = 1;
+   ieee80211softmac_notify_internal(mac, 
IEEE80211SOFTMAC_EVENT_ANY, found, ieee80211softmac_assoc_notify, NULL, 
GFP_KERNEL);
+   }
} else {
printkl(KERN_WARNING PFX Not authenticated, but 
requesting authentication failed. Giving up to associate\n);
+   mac-associnfo.assoc_wait = 0;
ieee80211softmac_call_events(mac, 
IEEE80211SOFTMAC_EVENT_ASSOCIATE_FAILED, found);
}
return;
}
/* finally! now we can start associating */
+   mac-associnfo.assoc_wait = 0;
ieee80211softmac_assoc(mac, found);
 }
 
diff --git a/net/ieee80211/softmac/ieee80211softmac_auth.c 
b/net/ieee80211/softmac/ieee80211softmac_auth.c
index 06e3326..23125ae 100644
--- a/net/ieee80211/softmac/ieee80211softmac_auth.c
+++ b/net/ieee80211/softmac/ieee80211softmac_auth.c
@@ -36,8 +36,9 @@ ieee80211softmac_auth_req(struct ieee802
struct ieee80211softmac_auth_queue_item *auth;
unsigned long flags;

-   if (net-authenticating)
+   if (net-authenticating || net-authenticated) 
return 0;
+   net-authenticating = 1;
 
/* Add the network if it's not already added */
ieee80211softmac_add_network(mac, net);
@@ -92,7 +93,6 @@ ieee80211softmac_auth_queue(void *data)

[PATCH] SoftMAC: Add network to ieee80211softmac_call_events when associate times out

2006-06-11 Thread Joseph Jezak

The ieee80211softmac_call_events function, when called with event type
IEEE80211SOFTMAC_EVENT_ASSOCIATE_TIMEOUT should pass the network as the
third parameter.  This patch does that.

Signed-off-by: Joseph Jezak [EMAIL PROTECTED]

---

diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c 
b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index aa65a7e..f9f7c8d 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -61,6 +61,7 @@ void
 ieee80211softmac_assoc_timeout(void *d)
 {
struct ieee80211softmac_device *mac = (struct ieee80211softmac_device 
*)d;
+   struct ieee80211softmac_network *n;
unsigned long flags;
 
spin_lock_irqsave(mac-lock, flags);
@@ -73,11 +74,12 @@ ieee80211softmac_assoc_timeout(void *d)
mac-associnfo.associating = 0;
mac-associnfo.bssvalid = 0;
mac-associated = 0;
+
+   n = ieee80211softmac_get_network_by_bssid_locked(mac, 
mac-associnfo.bssid);
spin_unlock_irqrestore(mac-lock, flags);
 
dprintk(KERN_INFO PFX assoc request timed out!\n);
-   /* FIXME: we need to know the network here. that requires a bit of 
restructuring */
-   ieee80211softmac_call_events(mac, 
IEEE80211SOFTMAC_EVENT_ASSOCIATE_TIMEOUT, NULL);
+   ieee80211softmac_call_events(mac, 
IEEE80211SOFTMAC_EVENT_ASSOCIATE_TIMEOUT, n);
 }
 
 /* Sends out a disassociation request to the desired AP */


-
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-info.html

Re: [patch 7/8] lock validator: fix ns83820.c irq-flags bug


Arjan van de Ven wrote:

Jeff Garzik wrote:
The driver's locking is definitely wrong, but I don't think this is 
the fix, 


it's an obvious correct fix in the correctness sense though...



Jesus, the locking here is awful.  No wonder there are bugs.



... which given that fact, is for 2.6.17 probably the right thing, pending
a nicer fix for 2.6.18


I disagree, the patch is wrong too.

For normal PCI hardware, the in-ISR paths should all use spin_lock(), 
and the outside-ISR paths should use either spin_lock_irq() or 
spin_lock_irqsave().


Jeff



-
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-info.html

Re: [patch 7/8] lock validator: fix ns83820.c irq-flags bug

2006-06-11 Thread Arjan van de Ven


Jeff Garzik wrote:

Arjan van de Ven wrote:

Jeff Garzik wrote:
The driver's locking is definitely wrong, but I don't think this is 
the fix, 


it's an obvious correct fix in the correctness sense though...



Jesus, the locking here is awful.  No wonder there are bugs.



... which given that fact, is for 2.6.17 probably the right thing, 
pending

a nicer fix for 2.6.18


I disagree, the patch is wrong too.


wrong as in not quite optimal, not wrong as in buggy.

For normal PCI hardware, the in-ISR paths should all use spin_lock(), 


only for per hardware locks obviously, not for per driver locks ;)


you are right that it's a lot nicer to do what you describe. No argument
from me on that part. But to call it wrong or incorrect is not quite
ok.  In terms of changing/fixing the approach we did was the simplest one.
Not the make it look nice one. Fix it by making the bug go away in the light
of a LOT of fishy locking.

You can demand that we first fix all the fishy locking first, and I can even
in part agree with that, but for -stable and 2.6.17 that is obviously out
of scope while a simple make the bug go away fix is not.

-
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-info.html

Re: [PATCH 1/2] PHYLIB: Add get_link ethtool helper function


Nathaniel Case wrote:

This adds a phy_ethtool_get_link() function along the same lines as
phy_ethtool_gset().  This provides drivers utilizing PHYLIB an
alternative to using ethtool_op_get_link().  This is more desirable
since the Link detected field in ethtool would actually reflect the
state of the PHY register.

Patch depends on previous patch (0/2).

Signed-off-by: Nate Case [EMAIL PROTECTED]
Signed-off-by: Andy Fleming [EMAIL PROTECTED]


NAK, needs an EXPORT


-
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-info.html

Re: [RFC ] [1 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - statement of project

2006-06-11 Thread Larry Finger

Uli,

Ulrich Kunitz wrote:

Larry,

I've not read your patches your detail, so I comment only on your
description.

The problem is the driver doesn't have good ideas, whether the
device is outdoor and in which country it operates. Devices have
some information available, but I have definitely a device
marketed in Canada, which had an EEPROM value for ETSI as
regulatory domain. I would expect the daemon to know, in which
country it is and whether the device is used outdoors. Keep also
in mind, that this information will be available from the AP at a
later time.

I agree that once the AP is broadcasting the country code, this all gets easier. I have a problem
similar to yours in that my interface's EEPROM supplies a code that indicates the world, which leads
to the bcm43xx driver code setting 2.4 GHz channels 1 - 14 and then running active scans on all of
them. Of course in the US 12, 13 and 14 are illegal and could lead to legal action if the FCC were
monitoring outside my house.

I don't see any means for the daemon to know its country other than the driver or the user telling
it. If such a means exists, I would like to learn of it. My current working model is to supply the
country code from a module option when the driver is loaded.

So there should be an explicit method to request the minimum set
or the configuration of daemon. Later the set can be changed again
by the AP information provided.

If the daemon is not running, if the country code is , or if it doesn't match any country in the
database, the minimum set is supplied, but the driver could call the routine again if it learned
more about its environment.

b) It then creates a new directory, '/proc/net/ieee80211_geo', and
populates it with 2 files for communication with the daemon. The first,
which is read by the daemon, contains the country and outdoor codes, and
the second is for the the daemon to write the 'struct ieee80211_geo' data
corresponding to the country and indoor/outdoor information passed from the
kernel.

Michael Buesch already commented on /proc/net. I don't think, that
this will be popular with a lot of folks. sysfs should be
supported and the mechanism should be comparable to firmware
loading. Maybe this could be some kind of udev extension. And make
it device specific, the whole approach should not break, if you
are accessing two devices connecting to two different access
points at the same time, where one of them is configured by the
central networking folks, who don't bother to adapt there configs
to specific countries and the other is a perfectly conformant
local AP, which is used for testing purposes.

Based on Michael's comments, I have changed the kernel - user space communication to use sysfs
rather than procfs. It also uses only a single mode 0666 file in /sys for communication. The deamon
spins waiting for that file to exist, then reads it to get the country and in/out flags. It then
writes the geo binary data to the file, closes it, delays a while and then repeats. After the geo
data are read, the kernel routine deletes the kobjects that create the sysfs file, loads the geo
data into the location supplied by the driver, and exits. Because the /sys file exists for only a
short time, I don't think that having it world writable will cause any problems. In addition, the
data supplied are thoroughly checked to make sure that it has the proper data for geo information.
If the 0666 mode is a problem, the daemon may have to become root to write the data.

Because, the geo data is loaded into a data area that is specific to each device, I don't expect any
problem with the situation you describe even if the same driver is operating both devices. If I have
missed some nuance, please enlighten me.

2. The user-space daemon, which need not be run as root, does the following:

It needs only to run temporarily run as root. I would definitely
recommend that all file parsing activities should not run as root.

At present, it does everything as an unprivileged user.

e) It then spins waiting for the existence of file
'/proc/net/ieee80211_geo/country', which is the indication that the kernel
is requesting data.

Again the whole interface should be device specific.

This part I don't understand. Everything in the geo data is generic to ieee802.11 devices. As I
stated earlier, it will end up in the private data for the device, but I don't see any reason for
the daemon to know which device is going to use the data.

Thanks for your comments,

Larry
-
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-info.html

Re: [patch 7/8] lock validator: fix ns83820.c irq-flags bug


[EMAIL PROTECTED] wrote:

diff -puN drivers/net/ns83820.c~lock-validator-fix-ns83820c-irq-flags-bug 
drivers/net/ns83820.c
--- devel/drivers/net/ns83820.c~lock-validator-fix-ns83820c-irq-flags-bug   
2006-06-08 22:18:34.0 -0700
+++ devel-akpm/drivers/net/ns83820.c2006-06-08 22:18:48.0 -0700
@@ -804,7 +804,7 @@ static int ns83820_setup_rx(struct net_d
 
 		writel(dev-IMR_cache, dev-base + IMR);

writel(1, dev-base + IER);
-   spin_unlock_irq(dev-misc_lock);
+   spin_unlock(dev-misc_lock);
 
 		kick_rx(ndev);
 


The above code snippet removes the nested unlock-irq, but now the code 
is unbalanced, so IMO this patch _adds_ confusion.


I think the conservative patch for 2.6.17 is the one I have attached. 
Unless there are objections, that is what I will forward...


Jeff


diff --git a/drivers/net/ns83820.c b/drivers/net/ns83820.c
index 706aed7..cee0e74 100644
--- a/drivers/net/ns83820.c
+++ b/drivers/net/ns83820.c
@@ -776,9 +776,11 @@ static int ns83820_setup_rx(struct net_d
 
ret = rx_refill(ndev, GFP_KERNEL);
if (!ret) {
+   unsigned long flags;
+
dprintk(starting receiver\n);
/* prevent the interrupt handler from stomping on us */
-   spin_lock_irq(dev-rx_info.lock);
+   spin_lock_irqsave(dev-rx_info.lock, flags);
 
writel(0x0001, dev-base + CCSR);
writel(0, dev-base + RFCR);
@@ -790,7 +792,7 @@ static int ns83820_setup_rx(struct net_d
phy_intr(ndev);
 
/* Okay, let it rip */
-   spin_lock_irq(dev-misc_lock);
+   spin_lock(dev-misc_lock);
dev-IMR_cache |= ISR_PHY;
dev-IMR_cache |= ISR_RXRCMP;
//dev-IMR_cache |= ISR_RXERR;
@@ -804,11 +806,11 @@ static int ns83820_setup_rx(struct net_d
 
writel(dev-IMR_cache, dev-base + IMR);
writel(1, dev-base + IER);
-   spin_unlock_irq(dev-misc_lock);
+   spin_unlock(dev-misc_lock);
 
kick_rx(ndev);
 
-   spin_unlock_irq(dev-rx_info.lock);
+   spin_unlock_irqrestore(dev-rx_info.lock, flags);
}
return ret;
 }

Re: [patch 7/8] lock validator: fix ns83820.c irq-flags bug

2006-06-11 Thread Arjan van de Ven



The above code snippet removes the nested unlock-irq, but now the code 
is unbalanced, so IMO this patch _adds_ confusion.


I think the conservative patch for 2.6.17 is the one I have attached. 
Unless there are objections, that is what I will forward...



this looks entirely fair and reasonable

Acked-by: Arjan van de Ven [EMAIL PROTECTED]
-
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-info.html

Re: [PATCH RFC] netpoll: don't spin forever sending to stopped queues

2006-06-11 Thread Matt Mackall

On Thu, Jun 08, 2006 at 07:15:50PM -0700, Jeremy Fitzhardinge wrote:
 Matt Mackall wrote:
 That's odd. Netpoll holds a reference to the device, of course, but so
 does a normal up interface. So that shouldn't be the problem.
 Another possibility is that outgoing packets from printks in the
 driver are causing difficulty. Not sure what can be done about that.
   
 Here's a patch.  I haven't tested it beyond compiling it, and I don't 
 know if it is actually correct.  In this case, it seems pointless to 
 spin waiting for an even which will never happen.  Should 
 netif_poll_disable() cause netpoll_send_skb() (or something) to not even 
 bother trying to send?  netif_poll_disable seems mysteriously simple to me.
 
J

Did this work for you at all?

 When transmitting a skb in netpoll_send_skb(), only retry a limited
 number of times if the device queue is stopped.

Where limited = once?

 Signed-off-by: Jeremy Fitzhardinge [EMAIL PROTECTED]
 
 diff -r aac813f54617 net/core/netpoll.c
 --- a/net/core/netpoll.c  Wed Jun 07 14:53:40 2006 -0700
 +++ b/net/core/netpoll.c  Thu Jun 08 19:00:29 2006 -0700
 @@ -280,15 +280,10 @@ static void netpoll_send_skb(struct netp
* network drivers do not expect to be called if the queue is
* stopped.
*/
 - if (netif_queue_stopped(np-dev)) {
 - np-dev-xmit_lock_owner = -1;
 - spin_unlock(np-dev-xmit_lock);
 - netpoll_poll(np);
 - udelay(50);
 - continue;
 - }
 -
 - status = np-dev-hard_start_xmit(skb, np-dev);
 + status = NETDEV_TX_BUSY;
 + if (!netif_queue_stopped(np-dev))
 + status = np-dev-hard_start_xmit(skb, np-dev);
 +
   np-dev-xmit_lock_owner = -1;
   spin_unlock(np-dev-xmit_lock);
 
 
 

-- 
Mathematics is the supreme nostalgia of our time.
-
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-info.html

IEEE80211 Regulatory/Geographical Support for WLAN driver

2006-06-11 Thread Ulrich Kunitz

On 06-06-11 11:46 Larry Finger wrote:

 I don't see any means for the daemon to know its country other than the 
 driver or the user telling it. If such a means exists, I would like to 
 learn of it. My current working model is to supply the country code from a 
 module option when the driver is loaded.

I thought about a config option. However thinking about they whole
thing more, I believe the functionality of your daemon should be
included into WPA supplicant and should use it's user space
communication mechanisms. It will become the universal WLAN user
space daemon anyhow. The second best option would be to extend
udev and reuse the firmware loading code.

BTW creating a file with 0666 is almost always a bad idea, even if
it exists only a short time. 

Kind regards,

Uli

-- 
Uli Kunitz
-
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-info.html

Re: [patch 7/8] lock validator: fix ns83820.c irq-flags bug

2006-06-11 Thread Benjamin LaHaise

 The above code snippet removes the nested unlock-irq, but now the code 
 is unbalanced, so IMO this patch _adds_ confusion.
 
 I think the conservative patch for 2.6.17 is the one I have attached. 
 Unless there are objections, that is what I will forward...

This looks reasonable and sufficiently conservative.  Reworking locking is 
something that I'm a bit more hesitant about, although folding misc_lock 
in with the other locks perhaps makes sense.  I would like to keep the 
split between tx and tx completion, though.  Also, any rework is going to 
need real testing, which is not something that a simple release cycle is 
likely to get enough coverage on.

-ben
-- 
Time is of no importance, Mr. President, only life is important.
Don't Email: [EMAIL PROTECTED].
-
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-info.html

Re: [PATCH] [2.6.17-rc6] Section mismatch in drivers/net/ne.o during modpost

2006-06-11 Thread Sam Ravnborg

On Sun, Jun 11, 2006 at 04:37:31PM +0200, Mikael Pettersson wrote:
 On Sat, 10 Jun 2006 22:38:00 +0200, Sam Ravnborg wrote:
  --- linux-2617-rc6.orig/drivers/net/ne.c
  +++ linux-2617-rc6/drivers/net/ne.c
  @@ -829,7 +829,7 @@ that the ne2k probe is the last 8390 bas
   is at boot) and so the probe will get confused by any other 8390 cards.
   ISA device autoprobes on a running machine are not recommended anyway. */
   
  -int init_module(void)
  +int __init init_module(void)
   {
 int this_dev, found = 0;
 
 When you anyway touches the driver I suggest to name the function
 module_init, module_cleanup and use module_init(), module_cleanup().
 
 Maybe not: in the ne.c driver init_module() is inside #ifdef MODULE,
 so conversion to ne_init() + module_init(ne_init) would be a no-op
 except for making the code larger. In the non-MODULE case Space.c
 calls ne_probe() directly.
The whole purpose of marking a function __init is to place in in a
section that can be discarded after init. This has the added advantage
that it kills off some ugly #ifdef MODULE / #endif as is the case for
ne.c

Even if not discarded then the code cleaniness is preferable to #ifdef /
#endif if purpose is only to save a few bytes.

Shifting to module_init(), module_cleanup() is the only right thing to
do - and the old behaviour is not even documented in LDD3 anymore.
[At least I did not find it last time I searched].

Sam
-
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-info.html

[PATCH] zd1211rw: disable TX queue during stop

2006-06-11 Thread Daniel Drake

This avoids some potential races.

Signed-off-by: Daniel Drake [EMAIL PROTECTED]

diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c 
b/drivers/net/wireless/zd1211rw/zd_mac.c
index bbe067e..3bdc54d 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -197,6 +197,8 @@ int zd_mac_stop(struct net_device *netde
struct zd_mac *mac = zd_netdev_mac(netdev);
struct zd_chip *chip = mac-chip;
 
+   netif_stop_queue(netdev);
+
/*
 * The order here deliberately is a little different from the open()
 * method, since we need to make sure there is no opportunity for RX
-
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-info.html

Re: [PATCH 2.6.17-rc6] Remove Prism II support from Orinoco

On Sat, Jun 10, 2006 at 02:08:50PM -0400, Dave Jones wrote:
  On Sat, Jun 10, 2006 at 08:50:10PM +0300, Faidon Liambotis wrote:
Remove Prism II IDs from the orinoco driver since now we have a separate
driver for them (HostAP). Additionally, kill orinoco_{pci,plx,nortel}
completely, since they only exist to support Prism cards.
No attempt was made to clean up the rest of the driver of the actual
Prism II code, only the PCI IDs were removed.
  
  I'm fairly certain I have a buffalo card that doesn't work with hostap
  that works just fine with orinoco.  I'll dig it out and see if that
  has been improved.

Objection rescinded, I have a WLI-PCM-L11G, which this patch doesn't affect.

One question though. People who are currently using orinoco will have
networking scripts set up by their distros autodetection mechanisms to
set up an 'ethX' interface. Switching to hostap by default will change
their interface to a wlanX interface, requiring them to either edit
their networking interface scripts, or to add dev_template parameters
to their /etc/modprobe.conf

Whichever is chosen, the upgrade process is going to blindside end-users
into broken wireless. Maybe things would just transparently keep working
if the default template was also ethX. Though that would cause breakage
for anyone with a currently working 'wlanX' interface on upgrade.

Hmm, tricky.

Dave

-- 
http://www.codemonkey.org.uk
-
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-info.html

Re: [PATCH 2.6.17-rc6] Remove Prism II support from Orinoco

On Sun, Jun 11, 2006 at 06:27:19PM -0400, Dave Jones wrote:
  On Sat, Jun 10, 2006 at 02:08:50PM -0400, Dave Jones wrote:
On Sat, Jun 10, 2006 at 08:50:10PM +0300, Faidon Liambotis wrote:
  Remove Prism II IDs from the orinoco driver since now we have a 
  separate
  driver for them (HostAP). Additionally, kill orinoco_{pci,plx,nortel}
  completely, since they only exist to support Prism cards.
  No attempt was made to clean up the rest of the driver of the actual
  Prism II code, only the PCI IDs were removed.

I'm fairly certain I have a buffalo card that doesn't work with hostap
that works just fine with orinoco.  I'll dig it out and see if that
has been improved.
  
  Objection rescinded, I have a WLI-PCM-L11G, which this patch doesn't affect.

Ah-ha, I had tested the wrong card.
I also have a Sitecom card, which matches this ident you remove in your patch..

PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0002), /* Safeway 802.11b, ZCOMAX 
AirRunner/XI-300 */


pccardctl ident shows it as:

Socket 0:
  product info:  , IEEE 802.11 Wireless LAN/PC Card, , 
  manfid: 0xd601, 0x0002
  function: 6 (network)



Under hostap, it's a brick, it won't even report any scanning results.

pccard: PCMCIA card inserted into slot 0
pcmcia: registering new device pcmcia0.0
ieee80211_crypt: registered algorithm 'NULL'
hostap_cs: 0.4.4-kernel (Jouni Malinen [EMAIL PROTECTED])
hostap_cs: setting Vcc=33 (constant)
Checking CFTABLE_ENTRY 0x01 (default 0x01)
IO window settings: cfg-io.nwin=1 dflt.io.nwin=1
io-flags = 0x0046, io.base=0x, len=64
hostap_cs: Registered netdevice wifi0
hostap_cs: index 0x01: , irq 4, io 0x0100-0x013f
prism2_hw_init: initialized in 108 ms
wifi0: NIC: id=0x8002 v1.0.0
wifi0: PRI: id=0x15 v0.3.0
wifi0: STA: id=0x1f v1.3.4
wifi0: defaulting to host-based encryption as a workaround for firmware bug in 
Host AP mode WEP
wifi0: defaulting to bogus WDS frame as a workaround for firmware bug in Host 
AP mode WDS
wifi0: registered netdevice wlan0
Scan result translation succeeded (length=0)


With orinoco however, it works just fine..
(Asides from the irritating feature of orinoco that the interface has to be 'up'
 before an iwlist scanning works)


pccard: PCMCIA card inserted into slot 0
pcmcia: registering new device pcmcia0.0
eth1: Hardware identity 8002::0001:
eth1: Station identity  001f:0004:0001:0003
eth1: Firmware determined as Intersil 1.3.4
eth1: Ad-hoc demo mode supported
eth1: IEEE standard IBSS ad-hoc mode supported
eth1: WEP supported, 104-bit key
eth1: MAC address 00:60:B3:68:AE:9B
eth1: Station name Prism  I
eth1: ready
eth1: index 0x01: , irq 4, io 0x0100-0x013f
ADDRCONF(NETDEV_UP): eth1: link is not ready
eth1: New link status: Connected (0001)
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready


So with your patch, this card will become totally useless to me.

Dave

-- 
http://www.codemonkey.org.uk
-
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-info.html

Re: [PATCH 2.6.17-rc6] Remove Prism II support from Orinoco

2006-06-11 Thread Kyle McMartin

On Sun, Jun 11, 2006 at 06:40:54PM -0400, Dave Jones wrote:
 Under hostap, it's a brick, it won't even report any scanning results.
 

Did you switch it into managed mode? The hostap driver, iirc, defaults
to running in master (AP) mode.

Cheers,
Kyle
-
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-info.html

[PATCH] [IrDA] irda-usb.c: STIR421x cleanups

2006-06-11 Thread Samuel Ortiz

This patch is for the net-2.6.18 tree.
It cleans the STIR421x part of the irda-usb code. We also no longer try to
load all existing firmwares but only the matching one (according to the USB
id we get from the dongle).

Signed-off-by: Nick Fedchik [EMAIL PROTECTED]
Signed-off-by: Samuel Ortiz [EMAIL PROTECTED]


---

 drivers/net/irda/irda-usb.c |  327 +++
 drivers/net/irda/irda-usb.h |   10 +
 2 files changed, 145 insertions(+), 192 deletions(-)

946837ac4e7bb301a1fcef0046b2a72e8e81b57c
diff --git a/drivers/net/irda/irda-usb.c b/drivers/net/irda/irda-usb.c
index cd87593..844fa74 100644
--- a/drivers/net/irda/irda-usb.c
+++ b/drivers/net/irda/irda-usb.c
@@ -83,9 +83,9 @@ static struct usb_device_id dongles[] = 
/* Extended Systems, Inc.,  XTNDAccess IrDA USB (ESI-9685) */
{ USB_DEVICE(0x8e9, 0x100), .driver_info = IUC_SPEED_BUG | 
IUC_NO_WINDOW },
/* SigmaTel STIR4210/4220/4116 USB IrDA (VFIR) Bridge */
-   { USB_DEVICE(0x66f, 0x4210), .driver_info = IUC_STIR_4210 | 
IUC_SPEED_BUG },
-   { USB_DEVICE(0x66f, 0x4220), .driver_info = IUC_STIR_4210 | 
IUC_SPEED_BUG },
-   { USB_DEVICE(0x66f, 0x4116), .driver_info = IUC_STIR_4210 | 
IUC_SPEED_BUG },
+   { USB_DEVICE(0x66f, 0x4210), .driver_info = IUC_STIR421X | 
IUC_SPEED_BUG },
+   { USB_DEVICE(0x66f, 0x4220), .driver_info = IUC_STIR421X | 
IUC_SPEED_BUG },
+   { USB_DEVICE(0x66f, 0x4116), .driver_info = IUC_STIR421X | 
IUC_SPEED_BUG },
{ .match_flags = USB_DEVICE_ID_MATCH_INT_CLASS |
  USB_DEVICE_ID_MATCH_INT_SUBCLASS,
  .bInterfaceClass = USB_CLASS_APP_SPEC,
@@ -154,7 +154,7 @@ static void irda_usb_build_header(struct
 * and if either speed or xbofs (or both) needs
 * to be changed.
 */
-   if (self-capability  IUC_STIR_4210 
+   if (self-capability  IUC_STIR421X 
((self-new_speed != -1) || (self-new_xbofs != -1))) {
 
/* With STIR421x, speed and xBOFs must be set at the same
@@ -318,7 +318,7 @@ static void irda_usb_change_speed_xbofs(
/* Set the new speed and xbofs in this fake frame */
irda_usb_build_header(self, frame, 1);
 
-   if ( self-capability  IUC_STIR_4210 ) {
+   if (self-capability  IUC_STIR421X) {
if (frame[0] == 0) return ; // do nothing if no change
frame[1] = 0; // other parameters don't change here
frame[2] = 0;
@@ -455,7 +455,7 @@ static int irda_usb_hard_xmit(struct sk_
 
/* Change setting for next frame */
 
-   if ( self-capability  IUC_STIR_4210 ) {
+   if (self-capability  IUC_STIR421X) {
__u8 turnaround_time;
__u8* frame;
turnaround_time = get_turnaround_time( skb );
@@ -897,10 +897,13 @@ static void irda_usb_receive(struct urb 
docopy = (urb-actual_length  IRDA_RX_COPY_THRESHOLD);
 
/* Allocate a new skb */
-   if ( self-capability  IUC_STIR_4210 )
-   newskb = dev_alloc_skb(docopy ? urb-actual_length : 
IRDA_SKB_MAX_MTU + USB_IRDA_SIGMATEL_HEADER);
+   if (self-capability  IUC_STIR421X)
+   newskb = dev_alloc_skb(docopy ? urb-actual_length :
+  IRDA_SKB_MAX_MTU +
+  USB_IRDA_STIR421X_HEADER);
else
-   newskb = dev_alloc_skb(docopy ? urb-actual_length : 
IRDA_SKB_MAX_MTU);
+   newskb = dev_alloc_skb(docopy ? urb-actual_length :
+  IRDA_SKB_MAX_MTU);
 
if (!newskb)  {
self-stats.rx_dropped++;
@@ -1022,188 +1025,140 @@ static int irda_usb_is_receiving(struct 
return 0; /* For now */
 }
 
-
-#define STIR421X_PATCH_PRODUCT_VERSION_STR   Product Version: 
-#define STIR421X_PATCH_COMPONENT_VERSION_STR Component Version: 
-#define STIR421X_PATCH_DATA_TAG_STR  STMP
-#define STIR421X_PATCH_FILE_VERSION_MAX_OFFSET   512 /* version info is 
before here */
-#define STIR421X_PATCH_FILE_IMAGE_MAX_OFFSET 512 /* patch image starts 
before here */
-#define STIR421X_PATCH_FILE_END_OF_HEADER_TAG0x1A/* marks end of patch 
file header (PC DOS text file EOF character) */
+#define STIR421X_PATCH_PRODUCT_VER Product Version: 
+#define STIR421X_PATCH_STMP_TAGSTMP
+#define STIR421X_PATCH_CODE_OFFSET 512 /* patch image starts before here */
+/* marks end of patch file header (PC DOS text file EOF character) */
+#define STIR421X_PATCH_END_OF_HDR_TAG  0x1A
+#define STIR421X_PATCH_BLOCK_SIZE  1023
 
 /*
- * Known firmware patches for STIR421x dongles
+ * Function stir421x_fwupload (struct irda_usb_cb *self,
+ * unsigned char *patch,
+ * const unsigned int patch_len)
+ *
+ *   Upload firmware code to SigmaTel 421X IRDA-USB dongle
  */
-static char * stir421x_patches[] = {
-   42101001.sb,
-   42101002.sb,
-};
-
-static int

Re: [PATCH 2.6.17-rc6] Remove Prism II support from Orinoco

On Sun, Jun 11, 2006 at 06:31:40PM -0400, Kyle McMartin wrote:
  On Sun, Jun 11, 2006 at 06:40:54PM -0400, Dave Jones wrote:
   Under hostap, it's a brick, it won't even report any scanning results.
   
  
  Did you switch it into managed mode? The hostap driver, iirc, defaults
  to running in master (AP) mode.

Ah, yes, that gets it able to scan again, thanks.
This is another gotcha that is going to prevent a smooth transition
from orinoco-hostap for end users though.

Dave

-- 
http://www.codemonkey.org.uk
-
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-info.html

Re: [RFT] Realtek 8168 ethernet support

2006-06-11 Thread Francois Romieu

The patch below agaisnt 2.6.17-rc6 includes the following changes:

commit 3072cc0aba3ac0c944e196a63c4154ca5746ec0b

r8169: sync with vendor's driver

- add several PCI ID for the PCI-E adapters ;
- new identification strings ;
- the RTL_GIGA_MAC_VER_ defines have been renamed to closely match the
  out-of-tree driver. It makes the comparison less hairy ;
- various magic ;
- the PCI region for the device with PCI ID 0x8136 is guessed.
  Explanation: the in-kernel Linux driver is written to allow MM register
  accesses and avoid the IO tax. The relevant BAR register was found at
  base address 1 for the plain-old PCI 8169. User reported lspci show that
  it is found at base address 2 for the new Gigabit PCI-E 816{8/9}.
  Typically:
  01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.: Unknown 
device 8168 (rev 01)
  Subsystem: Unknown device 1631:e015
  Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
  Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- 
TAbort- MAbort- SERR- PERR-
  Latency: 0, cache line size 20
  Interrupt: pin A routed to IRQ 16
  Region 0: I/O ports at b800 [size=256]
  Region 2: Memory at ff7ff000 (64-bit, non-prefetchable) [size=4K]
  
  So far I have not received any lspci report for the 0x8136 and
  Realtek's driver do not help: be it under BSD or Linux, their r1000 driver
  include a USE_IO_SPACE #define but the bar address is always hardcoded
  to 1 in the MM case. :o/

Signed-off-by: Francois Romieu [EMAIL PROTECTED]

commit 33857396c4f7d171f4ccaca86356df5fe2fdd304

r8169: remove rtl8169_init_board

Rationale:
- its signature is not exactly pretty;
- it has no knowledge of pci_device_id;
- kiss 23 lines good bye.

Signed-off-by: Francois Romieu [EMAIL PROTECTED]

commit af50f4372644c3c18c2af697a933c90f2a96be77

r8169: hardware flow control

The datasheet suggests that the device handles the hardware flow
control almost automagically. User report a different story, so
let's try to twiddle the mii registers.

Signed-off-by: Francois Romieu [EMAIL PROTECTED]

commit d1e6ebbea2297df970e52823e1d8c9af62b0548d

r8169: RX fifo overflow recovery

Signed-off-by: Francois Romieu [EMAIL PROTECTED]

commit 17fb3bf33149eb2cb1a37ff94ab236ab01f91a40

r8169: mac address change support

Fix for http://bugzilla.kernel.org/show_bug.cgi?id=6032.

Cc: Tim Mattox [EMAIL PROTECTED]
Signed-off-by: Francois Romieu [EMAIL PROTECTED]

The patch is for review only: mac address change apart, I need to
test it and it will surely conflict with jeff#netdev because of a
recently added PCI ID.

The patches are available at:
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.17-rc6/r8169

or:

git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git r8169

diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 0ad3310..53a33c5 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -150,11 +150,16 @@ #define RTL_R16(reg)  readw (ioaddr + (r
 #define RTL_R32(reg)   ((unsigned long) readl (ioaddr + (reg)))
 
 enum mac_version {
-   RTL_GIGA_MAC_VER_B = 0x00,
-   /* RTL_GIGA_MAC_VER_C = 0x03, */
-   RTL_GIGA_MAC_VER_D = 0x01,
-   RTL_GIGA_MAC_VER_E = 0x02,
-   RTL_GIGA_MAC_VER_X = 0x04   /* Greater than RTL_GIGA_MAC_VER_E */
+   RTL_GIGA_MAC_VER_01 = 0x00,
+   RTL_GIGA_MAC_VER_02 = 0x01,
+   RTL_GIGA_MAC_VER_03 = 0x02,
+   RTL_GIGA_MAC_VER_04 = 0x03,
+   RTL_GIGA_MAC_VER_05 = 0x04,
+   RTL_GIGA_MAC_VER_11 = 0x0b,
+   RTL_GIGA_MAC_VER_12 = 0x0c,
+   RTL_GIGA_MAC_VER_13 = 0x0d,
+   RTL_GIGA_MAC_VER_14 = 0x0e,
+   RTL_GIGA_MAC_VER_15 = 0x0f
 };
 
 enum phy_version {
@@ -166,7 +171,6 @@ enum phy_version {
RTL_GIGA_PHY_VER_H = 0x08, /* PHY Reg 0x03 bit0-3 == 0x0003 */
 };
 
-
 #define _R(NAME,MAC,MASK) \
{ .name = NAME, .mac_version = MAC, .RxConfigMask = MASK }
 
@@ -175,18 +179,28 @@ static const struct {
u8 mac_version;
u32 RxConfigMask;   /* Clears the bits supported by this chip */
 } rtl_chip_info[] = {
-   _R(RTL8169,   RTL_GIGA_MAC_VER_B, 0xff7e1880),
-   _R(RTL8169s/8110s,RTL_GIGA_MAC_VER_D, 0xff7e1880),
-   _R(RTL8169s/8110s,RTL_GIGA_MAC_VER_E, 0xff7e1880),
-   _R(RTL8169s/8110s,RTL_GIGA_MAC_VER_X, 0xff7e1880),
+   _R(RTL8169,   RTL_GIGA_MAC_VER_01, 0xff7e1880),
+   _R(RTL8169s/8110s,RTL_GIGA_MAC_VER_02, 0xff7e1880),
+   _R(RTL8169s/8110s,RTL_GIGA_MAC_VER_03, 0xff7e1880),
+   _R(RTL8169sb/8110sb,  RTL_GIGA_MAC_VER_04, 0xff7e1880),
+   _R(RTL8169sc/8110sc,  RTL_GIGA_MAC_VER_05, 0xff7e1880),
+   _R(RTL8168b/8111b,RTL_GIGA_MAC_VER_11, 0xff7e1880), // PCI-E
+

Re: [PATCH 1/2] e1000: fix netpoll with NAPI

2006-06-11 Thread Neil Horman

On Thu, Jun 08, 2006 at 01:29:00PM -0400, Jeff Moyer wrote:
 == Regarding Re: [PATCH 1/2] e1000: fix netpoll with NAPI; Mitch Williams 
 [EMAIL PROTECTED] adds:
 
 mitch.a.williams On Wed, 2006-06-07 at 11:44 -0700, Jeff Moyer wrote:
  That patch locks around the tx clean routine.  As such, it doesn't
  prevent the problem.
 
 mitch.a.williams The call to netif_rx_schedule_prep provides locking
 mitch.a.williams because it sets the __LINK_STATE_RX_SCHED bit atomically.
 mitch.a.williams The spinlock around e1000_clean_tx_irq is to protect it
 mitch.a.williams from other calls to the transmit routine, not NAPI.
 
 Yes, but what prevents recursion in the poll routine?  Consider that the
 poll routine could end up triggerring a printk (think iptables, here).  In
 that case, you end up calling into netpoll, and if the tx ring is full, we
 call the poll_controller routine.  We've now recursed.
 
 The poll lock was originally introduced to prevent recursion, not
 concurrent access.
 
Any further thoughts on this guys?  I still think my last solution solves all of
the netpoll problems, and isn't going to have any noticable impact on
performance.

Regards
Neil

 -Jeff
 -
 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-info.html
-
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-info.html

Remove useless check for null dev from uli526x_interrupt()

As we're already dereferencing dev a few lines above, if this
check could ever trigger, we'd have already oopsed.

Signed-off-by: Dave Jones [EMAIL PROTECTED]

--- linux-2.6/drivers/net/tulip/uli526x.c~  2006-06-11 20:24:41.0 
-0400
+++ linux-2.6/drivers/net/tulip/uli526x.c   2006-06-11 20:25:14.0 
-0400
@@ -666,11 +666,6 @@ static irqreturn_t uli526x_interrupt(int
unsigned long ioaddr = dev-base_addr;
unsigned long flags;
 
-   if (!dev) {
-   ULI526X_DBUG(1, uli526x_interrupt() without DEVICE arg, 0);
-   return IRQ_NONE;
-   }
-
spin_lock_irqsave(db-lock, flags);
outl(0, ioaddr + DCR7);
 
-
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-info.html

Re: Problem authenticating using WPA with bcm43xx-softmac

2006-06-11 Thread Larry Finger


Johannes Berg wrote:

On Fri, 2006-06-09 at 10:31 -0500, Larry Finger wrote:


Do you mean a special dump, or is the kernel debug output and wpa_supplicant 
debug output sufficient?


I was thinking of packet dumps but earlier you said you couldn't create
any so I'm out of ideas for now.


I was finally able to get my second laptop running with bcm43xx so I could get packet dumps. When I 
analyzed them, the Association Response packet contained the following information:


Association denied due to requesting station not supporting short preamble 
operation (0x0013)

I think this is a bug in the code on my WRT54G V5 and I will report it to Linksys; however, in the 
meantime, I am able to connect using the following _ugly_ hack to softmac_assoc_req and 
softmac_reassoc_req:


diff --git a/net/ieee80211/softmac/ieee80211softmac_io.c 
b/net/ieee80211/softmac/ieee80211softmac_io.c
index cc6cd56..a1d0c10 100644
--- a/net/ieee80211/softmac/ieee80211softmac_io.c
+++ b/net/ieee80211/softmac/ieee80211softmac_io.c
@@ -199,6 +199,8 @@ ieee80211softmac_assoc_req(struct ieee80
(*pkt)-capability |= mac-ieee-short_slot ?
cpu_to_le16(WLAN_CAPABILITY_SHORT_SLOT_TIME) : 0;
 */
+   /* add short preamble operation capability */
+   (*pkt)-capability |= cpu_to_le16(WLAN_CAPABILITY_SHORT_PREAMBLE);
(*pkt)-capability |= mac-ieee-sec.level ? 
cpu_to_le16(WLAN_CAPABILITY_PRIVACY) : 0;
/* Fill in Listen Interval (?) */
(*pkt)-listen_interval = cpu_to_le16(10);
@@ -247,6 +249,8 @@ ieee80211softmac_reassoc_req(struct ieee
(*pkt)-capability |= mac-ieee-short_slot ?
cpu_to_le16(WLAN_CAPABILITY_SHORT_SLOT_TIME) : 0;
 */
+   /* add short preamble operation capability */
+   (*pkt)-capability |= cpu_to_le16(WLAN_CAPABILITY_SHORT_PREAMBLE);
(*pkt)-capability |= mac-ieee-sec.level ?
cpu_to_le16(WLAN_CAPABILITY_PRIVACY) : 0;


I expect that softmac should be listening to the driver as to whether this capability is available; 
however, I'm now up and running once again.


Larry
-
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-info.html

Re: [PATCH netdev-2.6#upstream] net: au1000_eth: PHY framework conversion


Herbert Valerio Riedel wrote:

convert au1000_eth driver to use PHY framework and garbage collected
functions and identifiers that became unused/obsolete in the process

Signed-off-by: Herbert Valerio Riedel [EMAIL PROTECTED]


applied


-
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-info.html

Re: [PATCH] [IrDA] irda-usb.c: STIR421x cleanups

From: Samuel Ortiz [EMAIL PROTECTED]
Date: Mon, 12 Jun 2006 09:12:35 +0300

 This patch is for the net-2.6.18 tree.
 It cleans the STIR421x part of the irda-usb code. We also no longer try to
 load all existing firmwares but only the matching one (according to the USB
 id we get from the dongle).

 Signed-off-by: Nick Fedchik [EMAIL PROTECTED]
 Signed-off-by: Samuel Ortiz [EMAIL PROTECTED]

Applied, thanks a lot.
-
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-info.html

Re: [PATCH] bnx2: endian fixes

From: Alexey Dobriyan [EMAIL PROTECTED]
Date: Sat, 10 Jun 2006 15:52:51 +0400

 Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]

Applied, thanks Alexey.

-
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-info.html

Re: [PATCH] net.ipv4.ip_autoconfig sysctl removal

From: Stephen Hemminger [EMAIL PROTECTED]
Date: Mon, 5 Jun 2006 10:58:31 -0700

 The sysctl net.ipv4.ip_autoconfig is a legacy value that is not used.
 Can it finally go in 2.6.18 or do we need to go through the whole 
 feature-removal process?

 Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]

I think killing this on in 2.6.18 is ok, applied.

Thanks.
-
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-info.html

Re: [ PATCH 2.6.17-rc6 1/1] udp.c: counting InDatagrams which are never delivered