* Please pull upstream-fixes branch of wireless-2.6
From: John W. Linville @ 2006-05-06 1:06 UTC (permalink / raw)
To: netdev; +Cc: jeff, shemminger, akpm
These are fixes intended for 2.6.17...thanks!
---
The following changes since commit d98550e334715b2d9e45f8f0f4e1608720108640:
Linus Torvalds:
Merge branch 'merge' of git://git.kernel.org/.../paulus/powerpc
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-fixes
Daniel Drake:
softmac: don't reassociate if user asked for deauthentication
softmac: make non-operational after being stopped
David Woodhouse:
bcm43xx: Fix access to non-existent PHY registers
Jean Delvare:
ieee80211: Fix A band channel count (resent)
Michael Buesch:
bcm43xx: fix iwmode crash when down
bcm43xx: Fix array overrun in bcm43xx_geo_init
Stefano Brivio:
bcm43xx: check for valid MAC address in SPROM
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 45 ++++++++++++++---------
drivers/net/wireless/bcm43xx/bcm43xx_main.h | 6 ++-
drivers/net/wireless/bcm43xx/bcm43xx_phy.c | 2 +
drivers/net/wireless/bcm43xx/bcm43xx_wx.c | 7 +++-
include/net/ieee80211.h | 6 ++-
include/net/ieee80211softmac.h | 3 +-
net/ieee80211/softmac/ieee80211softmac_assoc.c | 17 ++++++++-
net/ieee80211/softmac/ieee80211softmac_auth.c | 16 +++++++-
net/ieee80211/softmac/ieee80211softmac_module.c | 4 ++
net/ieee80211/softmac/ieee80211softmac_scan.c | 8 ++++
10 files changed, 84 insertions(+), 30 deletions(-)
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index 9a06e61..e2982a8 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -939,9 +939,9 @@ #endif
return 0;
}
-static void bcm43xx_geo_init(struct bcm43xx_private *bcm)
+static int bcm43xx_geo_init(struct bcm43xx_private *bcm)
{
- struct ieee80211_geo geo;
+ struct ieee80211_geo *geo;
struct ieee80211_channel *chan;
int have_a = 0, have_bg = 0;
int i;
@@ -949,7 +949,10 @@ static void bcm43xx_geo_init(struct bcm4
struct bcm43xx_phyinfo *phy;
const char *iso_country;
- memset(&geo, 0, sizeof(geo));
+ geo = kzalloc(sizeof(*geo), GFP_KERNEL);
+ if (!geo)
+ return -ENOMEM;
+
for (i = 0; i < bcm->nr_80211_available; i++) {
phy = &(bcm->core_80211_ext[i].phy);
switch (phy->type) {
@@ -967,31 +970,36 @@ static void bcm43xx_geo_init(struct bcm4
iso_country = bcm43xx_locale_iso(bcm->sprom.locale);
if (have_a) {
- for (i = 0, channel = 0; channel < 201; channel++) {
- chan = &geo.a[i++];
+ for (i = 0, channel = IEEE80211_52GHZ_MIN_CHANNEL;
+ channel <= IEEE80211_52GHZ_MAX_CHANNEL; channel++) {
+ chan = &geo->a[i++];
chan->freq = bcm43xx_channel_to_freq_a(channel);
chan->channel = channel;
}
- geo.a_channels = i;
+ geo->a_channels = i;
}
if (have_bg) {
- for (i = 0, channel = 1; channel < 15; channel++) {
- chan = &geo.bg[i++];
+ for (i = 0, channel = IEEE80211_24GHZ_MIN_CHANNEL;
+ channel <= IEEE80211_24GHZ_MAX_CHANNEL; channel++) {
+ chan = &geo->bg[i++];
chan->freq = bcm43xx_channel_to_freq_bg(channel);
chan->channel = channel;
}
- geo.bg_channels = i;
+ geo->bg_channels = i;
}
- memcpy(geo.name, iso_country, 2);
+ memcpy(geo->name, iso_country, 2);
if (0 /*TODO: Outdoor use only */)
- geo.name[2] = 'O';
+ geo->name[2] = 'O';
else if (0 /*TODO: Indoor use only */)
- geo.name[2] = 'I';
+ geo->name[2] = 'I';
else
- geo.name[2] = ' ';
- geo.name[3] = '\0';
+ geo->name[2] = ' ';
+ geo->name[3] = '\0';
+
+ ieee80211_set_geo(bcm->ieee, geo);
+ kfree(geo);
- ieee80211_set_geo(bcm->ieee, &geo);
+ return 0;
}
/* DummyTransmission function, as documented on
@@ -3479,16 +3487,17 @@ static int bcm43xx_attach_board(struct b
goto err_80211_unwind;
bcm43xx_wireless_core_disable(bcm);
}
+ err = bcm43xx_geo_init(bcm);
+ if (err)
+ goto err_80211_unwind;
bcm43xx_pctl_set_crystal(bcm, 0);
/* Set the MAC address in the networking subsystem */
- if (bcm43xx_current_phy(bcm)->type == BCM43xx_PHYTYPE_A)
+ if (is_valid_ether_addr(bcm->sprom.et1macaddr))
memcpy(bcm->net_dev->dev_addr, bcm->sprom.et1macaddr, 6);
else
memcpy(bcm->net_dev->dev_addr, bcm->sprom.il0macaddr, 6);
- bcm43xx_geo_init(bcm);
-
snprintf(bcm->nick, IW_ESSID_MAX_SIZE,
"Broadcom %04X", bcm->chip_id);
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.h b/drivers/net/wireless/bcm43xx/bcm43xx_main.h
index eca79a3..30a202b 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.h
@@ -118,12 +118,14 @@ int bcm43xx_channel_to_freq(struct bcm43
static inline
int bcm43xx_is_valid_channel_a(u8 channel)
{
- return (channel <= 200);
+ return (channel >= IEEE80211_52GHZ_MIN_CHANNEL
+ && channel <= IEEE80211_52GHZ_MAX_CHANNEL);
}
static inline
int bcm43xx_is_valid_channel_bg(u8 channel)
{
- return (channel >= 1 && channel <= 14);
+ return (channel >= IEEE80211_24GHZ_MIN_CHANNEL
+ && channel <= IEEE80211_24GHZ_MAX_CHANNEL);
}
static inline
int bcm43xx_is_valid_channel(struct bcm43xx_private *bcm,
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_phy.c b/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
index 3313716..b0abac5 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
@@ -1287,7 +1287,7 @@ static void bcm43xx_phy_initg(struct bcm
if (radio->revision == 8)
bcm43xx_phy_write(bcm, 0x0805, 0x3230);
bcm43xx_phy_init_pctl(bcm);
- if (bcm->chip_id == 0x4306 && bcm->chip_package != 2) {
+ if (bcm->chip_id == 0x4306 && bcm->chip_package == 2) {
bcm43xx_phy_write(bcm, 0x0429,
bcm43xx_phy_read(bcm, 0x0429) & 0xBFFF);
bcm43xx_phy_write(bcm, 0x04C3,
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
index 3edbb48..b450639 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -182,8 +182,11 @@ static int bcm43xx_wx_set_mode(struct ne
mode = BCM43xx_INITIAL_IWMODE;
bcm43xx_lock_mmio(bcm, flags);
- if (bcm->ieee->iw_mode != mode)
- bcm43xx_set_iwmode(bcm, mode);
+ if (bcm->initialized) {
+ if (bcm->ieee->iw_mode != mode)
+ bcm43xx_set_iwmode(bcm, mode);
+ } else
+ bcm->ieee->iw_mode = mode;
bcm43xx_unlock_mmio(bcm, flags);
return 0;
diff --git a/include/net/ieee80211.h b/include/net/ieee80211.h
index 4725ff8..d5926bf 100644
--- a/include/net/ieee80211.h
+++ b/include/net/ieee80211.h
@@ -955,11 +955,13 @@ #define CFG_IEEE80211_RTS (1<<2)
#define IEEE80211_24GHZ_MIN_CHANNEL 1
#define IEEE80211_24GHZ_MAX_CHANNEL 14
-#define IEEE80211_24GHZ_CHANNELS 14
+#define IEEE80211_24GHZ_CHANNELS (IEEE80211_24GHZ_MAX_CHANNEL - \
+ IEEE80211_24GHZ_MIN_CHANNEL + 1)
#define IEEE80211_52GHZ_MIN_CHANNEL 34
#define IEEE80211_52GHZ_MAX_CHANNEL 165
-#define IEEE80211_52GHZ_CHANNELS 131
+#define IEEE80211_52GHZ_CHANNELS (IEEE80211_52GHZ_MAX_CHANNEL - \
+ IEEE80211_52GHZ_MIN_CHANNEL + 1)
enum {
IEEE80211_CH_PASSIVE_ONLY = (1 << 0),
diff --git a/include/net/ieee80211softmac.h b/include/net/ieee80211softmac.h
index b1ebfba..052ed59 100644
--- a/include/net/ieee80211softmac.h
+++ b/include/net/ieee80211softmac.h
@@ -204,7 +204,8 @@ struct ieee80211softmac_device {
/* couple of flags */
u8 scanning:1, /* protects scanning from being done multiple times at once */
- associated:1;
+ associated:1,
+ running:1;
struct ieee80211softmac_scaninfo *scaninfo;
struct ieee80211softmac_assoc_info associnfo;
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index fb79ce7..57ea9f6 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -51,11 +51,12 @@ ieee80211softmac_assoc(struct ieee80211s
spin_lock_irqsave(&mac->lock, flags);
mac->associnfo.associating = 1;
mac->associated = 0; /* just to make sure */
- spin_unlock_irqrestore(&mac->lock, flags);
/* Set a timer for timeout */
/* FIXME: make timeout configurable */
- schedule_delayed_work(&mac->associnfo.timeout, 5 * HZ);
+ if (likely(mac->running))
+ schedule_delayed_work(&mac->associnfo.timeout, 5 * HZ);
+ spin_unlock_irqrestore(&mac->lock, flags);
}
void
@@ -319,6 +320,9 @@ ieee80211softmac_handle_assoc_response(s
u16 status = le16_to_cpup(&resp->status);
struct ieee80211softmac_network *network = NULL;
unsigned long flags;
+
+ if (unlikely(!mac->running))
+ return -ENODEV;
spin_lock_irqsave(&mac->lock, flags);
@@ -377,10 +381,16 @@ ieee80211softmac_handle_disassoc(struct
{
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
unsigned long flags;
+
+ if (unlikely(!mac->running))
+ return -ENODEV;
+
if (memcmp(disassoc->header.addr2, mac->associnfo.bssid, ETH_ALEN))
return 0;
+
if (memcmp(disassoc->header.addr1, mac->dev->dev_addr, ETH_ALEN))
return 0;
+
dprintk(KERN_INFO PFX "got disassoc frame\n");
netif_carrier_off(dev);
spin_lock_irqsave(&mac->lock, flags);
@@ -400,6 +410,9 @@ ieee80211softmac_handle_reassoc_req(stru
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
struct ieee80211softmac_network *network;
+ if (unlikely(!mac->running))
+ return -ENODEV;
+
network = ieee80211softmac_get_network_by_bssid(mac, resp->header.addr3);
if (!network) {
dprintkl(KERN_INFO PFX "reassoc request from unknown network\n");
diff --git a/net/ieee80211/softmac/ieee80211softmac_auth.c b/net/ieee80211/softmac/ieee80211softmac_auth.c
index 9a0eac6..06e3326 100644
--- a/net/ieee80211/softmac/ieee80211softmac_auth.c
+++ b/net/ieee80211/softmac/ieee80211softmac_auth.c
@@ -86,6 +86,11 @@ ieee80211softmac_auth_queue(void *data)
/* Lock and set flags */
spin_lock_irqsave(&mac->lock, flags);
+ if (unlikely(!mac->running)) {
+ /* Prevent reschedule on workqueue flush */
+ spin_unlock_irqrestore(&mac->lock, flags);
+ return;
+ }
net->authenticated = 0;
net->authenticating = 1;
/* add a timeout call so we eventually give up waiting for an auth reply */
@@ -124,6 +129,9 @@ ieee80211softmac_auth_resp(struct net_de
unsigned long flags;
u8 * data;
+ if (unlikely(!mac->running))
+ return -ENODEV;
+
/* Find correct auth queue item */
spin_lock_irqsave(&mac->lock, flags);
list_for_each(list_ptr, &mac->auth_queue) {
@@ -298,8 +306,6 @@ ieee80211softmac_deauth_from_net(struct
/* can't transmit data right now... */
netif_carrier_off(mac->dev);
- /* let's try to re-associate */
- schedule_work(&mac->associnfo.work);
spin_unlock_irqrestore(&mac->lock, flags);
}
@@ -338,6 +344,9 @@ ieee80211softmac_deauth_resp(struct net_
struct ieee80211softmac_network *net = NULL;
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
+ if (unlikely(!mac->running))
+ return -ENODEV;
+
if (!deauth) {
dprintk("deauth without deauth packet. eek!\n");
return 0;
@@ -360,5 +369,8 @@ ieee80211softmac_deauth_resp(struct net_
}
ieee80211softmac_deauth_from_net(mac, net);
+
+ /* let's try to re-associate */
+ schedule_work(&mac->associnfo.work);
return 0;
}
diff --git a/net/ieee80211/softmac/ieee80211softmac_module.c b/net/ieee80211/softmac/ieee80211softmac_module.c
index be83bdc..6252be2 100644
--- a/net/ieee80211/softmac/ieee80211softmac_module.c
+++ b/net/ieee80211/softmac/ieee80211softmac_module.c
@@ -89,6 +89,8 @@ ieee80211softmac_clear_pending_work(stru
ieee80211softmac_wait_for_scan(sm);
spin_lock_irqsave(&sm->lock, flags);
+ sm->running = 0;
+
/* Free all pending assoc work items */
cancel_delayed_work(&sm->associnfo.work);
@@ -204,6 +206,8 @@ void ieee80211softmac_start(struct net_d
assert(0);
if (mac->txrates_change)
mac->txrates_change(dev, change, &oldrates);
+
+ mac->running = 1;
}
EXPORT_SYMBOL_GPL(ieee80211softmac_start);
diff --git a/net/ieee80211/softmac/ieee80211softmac_scan.c b/net/ieee80211/softmac/ieee80211softmac_scan.c
index 2b9e7ed..d31cf77 100644
--- a/net/ieee80211/softmac/ieee80211softmac_scan.c
+++ b/net/ieee80211/softmac/ieee80211softmac_scan.c
@@ -115,7 +115,15 @@ void ieee80211softmac_scan(void *d)
// TODO: is this if correct, or should we do this only if scanning from assoc request?
if (sm->associnfo.req_essid.len)
ieee80211softmac_send_mgt_frame(sm, &sm->associnfo.req_essid, IEEE80211_STYPE_PROBE_REQ, 0);
+
+ spin_lock_irqsave(&sm->lock, flags);
+ if (unlikely(!sm->running)) {
+ /* Prevent reschedule on workqueue flush */
+ spin_unlock_irqrestore(&sm->lock, flags);
+ break;
+ }
schedule_delayed_work(&si->softmac_scan, IEEE80211SOFTMAC_PROBE_DELAY);
+ spin_unlock_irqrestore(&sm->lock, flags);
return;
} else {
dprintk(PFX "Not probing Channel %d (not allowed here)\n", si->channels[current_channel_idx].channel);
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* Finance manager (msg id = 1dI )
From: tantiques @ 2006-05-06 0:45 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]
Hello, your e-mail address netdev@vger.kernel.org , has been taken from the open sources. My name is Alex Brewster. I am the main manager of Web Click Company.
We are engaged in software developing and design. The main office of our Company is located in Lithuania.
We are searching for employees to work in our company worldwide. If you wish to have additional income from 4000 to 10 000 dollars a month,
working from your house this offer is for you. The choice of vacancies is huge (designers, managers, auditors, financiers).
We will offer you the best conditions to work.
Also if you own a company or if you are managing director of the company we offer you to cooperation with us.
Please do not reply to this letter. Send your contact data and your CV to this e-mail: aomqg6gg37@yahoo.com - it is our temproary e-mail.
netdev@vger.kernel.org sorry for possible disturbance
------------------------------------------------------------
This email is not sent unsolicited and is in compliance with the
federal CAN-SPAM act. Your email address was provided to us as
either a reciprocal user of website promotion system(s), or as an
email initially sent by you or your company to which this response
is being provided.
--------------------------------------------------------------
ETLs2Fu8
this mailing conforms to all federal laws. please reply
back with "stop mailings" in subject line netdev@vger.kernel.org to
stop mailings. per can-spam you must allow up to 7
business days for your email deletion.
7tQ
TBau7
MKbx
Q
4dJ
cjzuEZNb
ma
l
xTj5W
Hd
^ permalink raw reply
* Re: [PATCH] Re: a question on tcp_highspeed.c (in 2.6.16)
From: David S. Miller @ 2006-05-06 0:42 UTC (permalink / raw)
To: jheffner; +Cc: davidwei79, netdev
In-Reply-To: <445A5098.6010306@psc.edu>
From: John Heffner <jheffner@psc.edu>
Date: Thu, 04 May 2006 15:06:00 -0400
> Xiaoliang (David) Wei wrote:
> > Hi gurus,
> >
> > I am reading the code of tcp_highspeed.c in the kernel and have a
> > question on the hstcp_cong_avoid function, specifically the following
> > AI part (line 136~143 in net/ipv4/tcp_highspeed.c ):
> >
> > /* Do additive increase */
> > if (tp->snd_cwnd < tp->snd_cwnd_clamp) {
> > tp->snd_cwnd_cnt += ca->ai;
> > if (tp->snd_cwnd_cnt >= tp->snd_cwnd) {
> > tp->snd_cwnd++;
> > tp->snd_cwnd_cnt -= tp->snd_cwnd;
> > }
> > }
> >
> > In this part, when (tp->snd_cwnd_cnt == tp->snd_cwnd),
> > snd_cwnd_cnt will be -1... snd_cwnd_cnt is defined as u16, will this
> > small chance of getting -1 becomes a problem?
> > Shall we change it by reversing the order of the cwnd++ and cwnd_cnt -=
> > cwnd?
>
> Absolutely correct. Thanks.
>
> Signed-off-by: John Heffner <jheffner@psc.edu>
Applied, thanks a lot everyone.
^ permalink raw reply
* Re: [RFC PATCH] [IPV6] ADDRCONF: Convert addrconf_lock to RCU.
From: David S. Miller @ 2006-05-06 0:40 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev
In-Reply-To: <20060505.122452.46183936.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Fri, 05 May 2006 12:24:52 +0900 (JST)
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
It is critical that we free the inet6 device structure using an RCU
callback in order for this locking strategy to work.
An RCU head needs to be added to "struct inet6_dev", and
in6_dev_finish_destroy() will need to schedule the real kfree() call
via an RCU callback.
^ permalink raw reply
* Re: VJ Channel API - driver level (PATCH)
From: David S. Miller @ 2006-05-06 0:35 UTC (permalink / raw)
To: johnpol; +Cc: alex, caitlinb, Leonid.Grossman, shemminger, netdev
In-Reply-To: <20060505093656.GB23540@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Fri, 5 May 2006 13:36:56 +0400
> Hardware folks could also create it's own implementation and show
> community if theirs approach is good or not.
Designing hardware for non-existing software infrastructure is
risky buisness :-)
^ permalink raw reply
* Re: [PATCH 2/3] Eleminate HZ from NET/ROM kernel interfaces
From: David S. Miller @ 2006-05-06 0:19 UTC (permalink / raw)
To: ralf; +Cc: pidoux, netdev, linux-hams
In-Reply-To: <20060501235235.GA18868@linux-mips.org>
From: Ralf Baechle <ralf@linux-mips.org>
Date: Tue, 2 May 2006 00:52:35 +0100
> On Sun, Apr 30, 2006 at 05:21:36PM -0700, David S. Miller wrote:
>
> > > With such extensive patches for netrom and rose modules that will go
> > > into a future 2.6.x kernel, I think it would be justified to update the
> > > following banners in af_rose.c and af_netrom.c respectively for they
> > > appear during boot :
> >
> > It might be worthwhile to remove the messages altogether.
> >
> > IPV4 and the core networking used to output similar initialization
> > log messages and it really doesn't really add anything but pollute
> > the already voluminous kernel log.
> >
> > So I say we just remove it.
>
> Agreed, patch to remove the messages is below.
>
> Ralf
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Applied, thanks a lot Ralf.
^ permalink raw reply
* Re: IPv6 connect() from site-local to global IPv6 address.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-05-06 0:19 UTC (permalink / raw)
To: dwmw2; +Cc: netdev, yoshfuji
In-Reply-To: <1146862832.2766.54.camel@pmac.infradead.org>
In article <1146862832.2766.54.camel@pmac.infradead.org> (at Fri, 05 May 2006 22:00:32 +0100), David Woodhouse <dwmw2@infradead.org> says:
> Since updating the kernel to 2.6.16, I've got problems with external
> connectivity to hosts which have both IPv4 and (Global) IPv6 addresses
> in DNS. Glibc used to return the IPv4 address in the A record first, and
> all was well. But now it returns the IPv6 address in the AAAA record
> first, and I can't communicate with that. So I get a three-minute
> timeout whenever I try to connect to anything in the outside which has
> both A and AAAA records.
>
> One of the things which glibc's implementation of RFC3484 address
> selection (http://people.redhat.com/drepper/linux-rfc3484.html) does is
> to perform a dummy connect() of a SOCK_DGRAM socket to each of the
> potential addresses. On older kernels this used to fail when we
> attempted to connect to a global IPv6 address and we didn't have a
> global IPv6 address of our own...
:
> socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
> connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:8b0:10b:1:20d:93ff:fe7a:3f2c", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
> getsockname(3, {sa_family=AF_INET6, sin6_port=htons(32772), inet_pton(AF_INET6, "::172.16.18.67", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
> socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
> connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("81.187.2.168")}, 16) = 0
> getsockname(3, {sa_family=AF_INET, sin_port=htons(32772), sin_addr=inet_addr("172.16.18.67")}, [16]) = 0
> Trying 2001:8b0:10b:1:20d:93ff:fe7a:3f2c...
>
> Is this change in behaviour intentional? Is it useful?
>
> How can we get sane behaviour from glibc again? What we had before was
> ideal -- if we have an IPv6 default route _and_ we have a Global IPv6
> address of our own, then return the Global IPv6 address in the AAAA
> record first. Else return the IPv4 address in the A record.
You have compatible address.
Do you really use the tunnel? How did you configure it?
--yoshfuji
^ permalink raw reply
* Re: [1/1] connector: export cn_already_initialized.
From: David S. Miller @ 2006-05-06 0:16 UTC (permalink / raw)
To: johnpol; +Cc: netdev
In-Reply-To: <20060504122421.GA8576@2ka.mipt.ru>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Thu, 4 May 2006 16:24:22 +0400
> No in-kernel users require it to be exported, so if you do think it
> should not be exported I will force external module changes.
What are the alternatives?
^ permalink raw reply
* Re: [DCCP]: Fix sock_orphan dead lock
From: David S. Miller @ 2006-05-06 0:09 UTC (permalink / raw)
To: herbert; +Cc: mingo, arjan, netdev
In-Reply-To: <20060504071750.GA17180@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 4 May 2006 17:17:50 +1000
> Anyway, the same issue affects DCCP (and SCTP too probably). Here
> is a patch that does the same thing for DCCP.
Thanks for catching that, applied.
^ permalink raw reply
* Re: [PATCH] bridge: keep track of received multicast packets
From: David S. Miller @ 2006-05-06 0:07 UTC (permalink / raw)
To: shemminger; +Cc: PCDiem, bridge, netdev
In-Reply-To: <20060504161019.17feb2aa@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Thu, 4 May 2006 16:10:19 -0700
> It makes sense to add this simple statistic to keep track of received
> multicast packets.
>
> Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH 4/4] [SCTP]: Fix state table entries for chunks received in CLOSED state.
From: David S. Miller @ 2006-05-06 0:06 UTC (permalink / raw)
To: sri; +Cc: netdev, lksctp-developers
In-Reply-To: <1146856490.7861.36.camel@w-sridhar2.beaverton.ibm.com>
From: Sridhar Samudrala <sri@us.ibm.com>
Date: Fri, 05 May 2006 12:14:50 -0700
> [SCTP]: Fix state table entries for chunks received in CLOSED state.
>
> Discard an unexpected chunk in CLOSED state rather can calling BUG().
>
> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 3/4] [SCTP]: Fix panic's when receiving fragmented SCTP control chunks.
From: David S. Miller @ 2006-05-06 0:04 UTC (permalink / raw)
To: sri; +Cc: netdev, lksctp-developers
In-Reply-To: <1146856485.7861.35.camel@w-sridhar2.beaverton.ibm.com>
From: Sridhar Samudrala <sri@us.ibm.com>
Date: Fri, 05 May 2006 12:14:45 -0700
> [SCTP]: Fix panic's when receiving fragmented SCTP control chunks.
>
> Use pskb_pull() to handle incoming COOKIE_ECHO and HEARTBEAT chunks that
> are received as skb's with fragment list.
>
> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/4] [SCTP]: Prevent possible infinite recursion with multiple bundled DATA.
From: David S. Miller @ 2006-05-06 0:04 UTC (permalink / raw)
To: sri; +Cc: netdev, lksctp-developers
In-Reply-To: <1146856478.7861.34.camel@w-sridhar2.beaverton.ibm.com>
From: Sridhar Samudrala <sri@us.ibm.com>
Date: Fri, 05 May 2006 12:14:38 -0700
> [SCTP]: Prevent possible infinite recursion with multiple bundled DATA.
>
> There is a rare situation that causes lksctp to go into infinite recursion
> and crash the system. The trigger is a packet that contains at least the
> first two DATA fragments of a message bundled together. The recursion is
> triggered when the user data buffer is smaller that the full data message.
> The problem is that we clone the skb for every fragment in the message.
> When reassembling the full message, we try to link skbs from the "first
> fragment" clone using the frag_list. However, since the frag_list is shared
> between two clones in this rare situation, we end up setting the frag_list
> pointer of the second fragment to point to itself. This causes
> sctp_skb_pull() to potentially recurse indefinitely.
>
> Proposed solution is to make a copy of the skb when attempting to link
> things using frag_list.
>
> Signed-off-by: Vladislav Yasevich <vladsilav.yasevich@hp.com>
> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Applied, but again I had to manually remove a ton of trailing
whitespace added by this patch.
^ permalink raw reply
* Re: [PATCH 1/4] [SCTP]: Allow spillover of receiver buffer to avoid deadlock
From: David S. Miller @ 2006-05-06 0:02 UTC (permalink / raw)
To: sri; +Cc: netdev, lksctp-developers
In-Reply-To: <1146856468.7861.33.camel@w-sridhar2.beaverton.ibm.com>
From: Sridhar Samudrala <sri@us.ibm.com>
Date: Fri, 05 May 2006 12:14:28 -0700
> [SCTP]: Allow spillover of receive buffer to avoid deadlock.
>
> This patch fixes a deadlock situation in the receive path by allowing
> temporary spillover of the receive buffer.
>
> - If the chunk we receive has a tsn that immediately follows the ctsn,
> accept it even if we run out of receive buffer space and renege data with
> higher TSNs.
> - Once we accept one chunk in a packet, accept all the remaining chunks
> even if we run out of receive buffer space.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Acked-by: Mark Butler <butlerm@middle.net>
> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Applied with trailing whitespace removed. Please double-check
all of your patches with something like:
git apply --check --whitespace=error-all diff
before submission.
Thanks.
^ permalink raw reply
* general protection fault: last sysfs file: /class/vc/vcsa4/dev
From: Paul Risenhoover @ 2006-05-05 23:37 UTC (permalink / raw)
To: netdev
Subject:
GPF on Dell machines
From:
Paul Risenhoover <prisenhoover@daxsolutions.com>
Date:
Fri, 05 May 2006 09:37:34 -0700
To:
linux-kernel@vger.kernel.org
I've been getting the following error repeatedly on a number of machines
in my server farm. Unfortunately, when this happens, the machine
becomes completely inoperable and must be hard booted. These are
dual-processor Dell X64 machines .
Can anybody please help? How can I make this stop? Should I be posting
this to the samba mailing list instead?
May 3 12:35:04 neon kernel: general protection fault: 0000 [1] SMP
May 3 12:35:04 neon kernel: last sysfs file: /class/vc/vcsa4/dev
May 3 12:35:04 neon kernel: CPU 0
May 3 12:35:04 neon kernel: Modules linked in: smbfs ipv6 parport_pc lp
parport autofs4 i2c_dev i2c_core rfcomm l2cap bluetooth sunrpc pcmcia
yenta_socket rsrc_nonstatic pcmcia_core video button battery ac
e752x_edac edac_mc e1000 dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
ata_piix
libata sd_mod scsi_mod
May 3 12:35:04 neon kernel: Pid: 21979, comm: smbiod Not tainted
2.6.16-1.2069_FC4smp #1
May 3 12:35:04 neon kernel: RIP: 0010:[<ffffffff882ea8ff>]
<ffffffff882ea8ff>{:smbfs:smbiod+520}
May 3 12:35:04 neon kernel: RSP: 0018:ffff810007013ee8 EFLAGS: 00010202
May 3 12:35:04 neon kernel: RAX: ffff203f1200b400 RBX: ffff81007fc8b400
RCX: ffff810007013ed4
May 3 12:35:04 neon kernel: RDX: 00000000ffffffff RSI: 0000000000000000
RDI: 0000000000000001
May 3 12:35:04 neon kernel: RBP: 0000000000000000 R08: ffff810007012000
R09: 00000000000005a8
May 3 12:35:04 neon kernel: R10: 0000000000000002 R11: ffffffff80316311
R12: 0000000000000007
May 3 12:35:04 neon kernel: R13: ffff203f1200b400 R14: ffff81007da3e4c8
R15: ffff810007013ee8
May 3 12:35:04 neon kernel: FS: 00002aaaaadfd6e0(0000)
GS:ffffffff8051e000(0000) knlGS:0000000000000000
May 3 12:35:04 neon kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
May 3 12:35:04 neon kernel: CR2: 00002aab32604000 CR3: 0000000008a5f000
CR4: 00000000000006e0
May 3 12:35:04 neon kernel: Process smbiod (pid: 21979, threadinfo
ffff810007012000, task ffff81001b4cb7a0)
May 3 12:35:04 neon kernel: Stack: 0000000000000000 ffff81001b4cb7a0
ffffffff8014a2b0 ffff810007013f00
May 3 12:35:04 neon kernel: ffff810007013f00 ffff810007013f58
ffff81001b4cb7a0 ffff81007c14ea00
May 3 12:35:04 neon kernel: ffff81007c14ea00 ffff8100698a3c58
May 3 12:35:04 neon kernel: Call Trace:
<ffffffff8014a2b0>{autoremove_wake_function+0}
May 3 12:35:04 neon kernel: <ffffffff8010bb1a>{child_rip+8}
<ffffffff882ea6f7>{:smbfs:smbiod+0}
May 3 12:35:04 neon kernel: <ffffffff8010bb12>{child_rip+0}
May 3 12:35:04 neon kernel:
May 3 12:35:04 neon kernel: Code: 49 8b 45 00 4c 89 eb 49 81 fd e0 2b
2f 88 74 19 49 89 c5 e9
May 3 12:35:04 neon kernel: RIP <ffffffff882ea8ff>{:smbfs:smbiod+520}
RSP <ffff810007013ee8>
May 3 12:35:31 neon kernel: <5>smb_add_request: request
[ffff810026493680, mid=765] timed out!
--> DMESG BEGINS HERE <--
Bootdata ok (command line is ro root=/dev/VolGroup00/LogVol00)
Linux version 2.6.16-1.2069_FC4smp
(bhcompile@hs20-bc1-6.build.redhat.com) (gcc version 4.0.2 20051125 (Red
Hat 4.0.2-8)) #1 SMP Tue Mar 28 12:48:20 EST 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 0000000000100000 - 000000007ffc0000 (usable)
BIOS-e820: 000000007ffc0000 - 000000007ffcfc00 (ACPI data)
BIOS-e820: 000000007ffcfc00 - 000000007ffff000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec90000 (reserved)
BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
ACPI: RSDP (v000 DELL ) @
0x00000000000fd650
ACPI: RSDT (v001 DELL PESC1425 0x00000001 MSFT 0x0100000a) @
0x00000000000fd664
ACPI: FADT (v001 DELL PESC1425 0x00000001 MSFT 0x0100000a) @
0x00000000000fd6b0
ACPI: MADT (v001 DELL PESC1425 0x00000001 MSFT 0x0100000a) @
0x00000000000fd724
ACPI: SPCR (v001 DELL PESC1425 0x00000001 MSFT 0x0100000a) @
0x00000000000fd7c0
ACPI: HPET (v001 DELL PESC1425 0x00000001 MSFT 0x0100000a) @
0x00000000000fd810
ACPI: MCFG (v001 DELL PESC1425 0x00000001 MSFT 0x0100000a) @
0x00000000000fd848
ACPI: DSDT (v001 DELL PESC1425 0x00000001 MSFT 0x0100000e) @
0x0000000000000000
No NUMA configuration found
Faking a node at 0000000000000000-000000007ffc0000
Bootmem setup node 0 0000000000000000-000000007ffc0000
On node 0 totalpages: 514768
DMA zone: 2767 pages, LIFO batch:0
DMA32 zone: 512001 pages, LIFO batch:31
Normal zone: 0 pages, LIFO batch:0
HighMem zone: 0 pages, LIFO batch:0
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x06] enabled)
Processor #6 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled)
Processor #1 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x07] enabled)
Processor #7 15:4 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x09] address[0xfec80000] gsi_base[32])
IOAPIC[1]: apic_id 9, version 32, address 0xfec80000, GSI 32-55
ACPI: IOAPIC (id[0x0a] address[0xfec80800] gsi_base[64])
IOAPIC[2]: apic_id 10, version 32, address 0xfec80800, GSI 64-87
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to physical flat
ACPI: HPET id: 0xffffffff base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 80000000 (gap: 7ffff000:60001000)
Checking aperture...
SMP: Allowing 4 CPUs, 0 hotplug CPUs
Built 1 zonelists
Kernel command line: ro root=/dev/VolGroup00/LogVol00
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 14.318180 MHz WALL HPET GTOD HPET/TSC timer.
time.c: Detected 3000.147 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 2053744k/2096896k available (2397k kernel code, 42768k reserved,
1210k data, 204k init)
Calibrating delay using timer specific routine.. 6005.70 BogoMIPS
(lpj=12011403)
Security Framework v1.0.0 initialized
SELinux: Initializing.
SELinux: Starting in permissive mode
selinux_register_security: Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 256
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
using mwait in idle threads.
CPU: Physical Processor ID: 0
CPU0: Thermal monitoring enabled (TM1)
Using local APIC timer interrupts.
result 12500500
Detected 12.500 MHz APIC timer.
Booting processor 1/4 APIC 0x6
Initializing CPU#1
Calibrating delay using timer specific routine.. 6000.44 BogoMIPS
(lpj=12000895)
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 3
CPU1: Thermal monitoring enabled (TM1)
Intel(R) Xeon(TM) CPU 3.00GHz stepping 03
Booting processor 2/4 APIC 0x1
Initializing CPU#2
Calibrating delay using timer specific routine.. 6000.40 BogoMIPS
(lpj=12000819)
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU2: Thermal monitoring enabled (TM1)
Intel(R) Xeon(TM) CPU 3.00GHz stepping 03
APIC error on CPU2: 00(40)
Booting processor 3/4 APIC 0x7
Initializing CPU#3
Calibrating delay using timer specific routine.. 6000.35 BogoMIPS
(lpj=12000704)
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 3
CPU3: Thermal monitoring enabled (TM1)
Intel(R) Xeon(TM) CPU 3.00GHz stepping 03
APIC error on CPU3: 00(40)
Brought up 4 CPUs
testing NMI watchdog ... OK.
migration_cost=3,1714
checking if image is initramfs... it is
Freeing initrd memory: 1875k freed
DMI 2.3 present.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
PCI: Using MMCONFIG at e0000000
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 0800-087f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region 0880-08bf claimed by ICH4 GPIO
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: PXH quirk detected, disabling MSI for SHPC device
PCI: PXH quirk detected, disabling MSI for SHPC device
Boot video device is 0000:04:0d.0
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PALO._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PALO.PXHB._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PALO.PXHA._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PICH._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 *6 7 10 11 12)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 *11 12)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 11 12) *0, disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 9 devices
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a
report
hpet0: at MMIO 0xfed00000 (virtual 0xffffffffff5fe000), IRQs 2, 8, 0
hpet0: 3 64-bit timers, 14318180 Hz
PCI-DMA: Disabling IOMMU.
pnp: 00:06: ioport range 0x800-0x87f could not be reserved
pnp: 00:06: ioport range 0x880-0x8bf has been reserved
pnp: 00:06: ioport range 0x8c0-0x8df has been reserved
pnp: 00:06: ioport range 0x8e0-0x8e3 has been reserved
pnp: 00:06: ioport range 0xc00-0xc0f has been reserved
pnp: 00:06: ioport range 0xc10-0xc1f has been reserved
pnp: 00:06: ioport range 0xca0-0xcaf has been reserved
pnp: 00:06: ioport range 0xc20-0xc3f has been reserved
PCI: Bridge: 0000:01:00.0
IO window: e000-efff
MEM window: fea00000-febfffff
PREFETCH window: disabled.
PCI: Bridge: 0000:01:00.2
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:02.0
IO window: e000-efff
MEM window: fe800000-febfffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
IO window: d000-dfff
MEM window: fe600000-fe7fffff
PREFETCH window: f0000000-f7ffffff
GSI 16 sharing vector 0xA9 and IRQ 16
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:02.0 to 64
PCI: Setting latency timer of device 0000:01:00.0 to 64
PCI: Setting latency timer of device 0000:01:00.2 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $
audit: initializing netlink socket (disabled)
audit(1146770259.072:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
SELinux: Registering netfilter hooks
Initializing Cryptographic API
ksign: Installing public key data
Loading keyring
- Added public key 7C299BBC39CD3974
- User ID: Red Hat, Inc. (Kernel Module GPG key)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Intel E7520/7320/7525 detected.<6>ACPI: PCI Interrupt 0000:00:02.0[A] ->
GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:02.0 to 64
Allocate Port Service[0000:00:02.0:pcie00]
Allocate Port Service[0000:00:02.0:pcie01]
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Real Time Clock Driver v1.12ac
hpet_resources: 0xfed00000 is busy
Linux agpgart interface v0.101 (c) Dave Jones
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing enabled
pnp: Device 00:05 activated.
00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
isa bounce pool size: 16 pages
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH5: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
GSI 17 sharing vector 0xB1 and IRQ 17
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 17
ICH5: chipset revision 2
ICH5: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio
Probing IDE interface ide0...
hda: TEAC CD-ROM CD-224E-N, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hda: ATAPI 24X CD-ROM drive, 256kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
ide-floppy driver 0.99.newide
usbcore: registered new driver libusual
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
TCP established hash table entries: 131072 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 9, 2097152 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
ACPI wakeup devices:
PCI0 PALO PXH PXHB PXHA PICH
ACPI: (supports S0 S4 S5)
Freeing unused kernel memory: 204k freed
Write protecting the kernel read-only data: 426k
SCSI subsystem initialized
libata version 1.20 loaded.
ata_piix 0000:00:1f.2: version 1.05
ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0xCCF8 ctl 0xCCF2 bmdma 0xCCC0 irq 17
ata2: SATA max UDMA/133 cmd 0xCCE0 ctl 0xCCDA bmdma 0xCCC8 irq 17
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4673 85:7c69 86:3c21 87:4663
88:207f
ata1: dev 0 ATA-7, max UDMA/133, 156250000 sectors: LBA48
ata1: dev 0 configured for UDMA/133
scsi0 : ata_piix
ata2: SATA port has no device.
scsi1 : ata_piix
Vendor: ATA Model: Maxtor 6L080M0 Rev: BACE
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 156250000 512-byte hdwr sectors (80000 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
SCSI device sda: 156250000 512-byte hdwr sectors (80000 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
sda: sda1 sda2
sd 0:0:0:0: Attached scsi disk sda
device-mapper: 4.5.0-ioctl (2005-10-04) initialised: dm-devel@redhat.com
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting. Commit interval 5 seconds
EXT3-fs: dm-0: orphan cleanup on readonly fs
ext3_orphan_cleanup: deleting unreferenced inode 10615593
ext3_orphan_cleanup: deleting unreferenced inode 14305643
ext3_orphan_cleanup: deleting unreferenced inode 10835636
ext3_orphan_cleanup: deleting unreferenced inode 10607810
ext3_orphan_cleanup: deleting unreferenced inode 10835634
ext3_orphan_cleanup: deleting unreferenced inode 10610239
ext3_orphan_cleanup: deleting unreferenced inode 10607808
ext3_orphan_cleanup: deleting unreferenced inode 10607746
ext3_orphan_cleanup: deleting unreferenced inode 10607740
ext3_orphan_cleanup: deleting unreferenced inode 10607733
ext3_orphan_cleanup: deleting unreferenced inode 10607659
ext3_orphan_cleanup: deleting unreferenced inode 16891829
ext3_orphan_cleanup: deleting unreferenced inode 16891825
ext3_orphan_cleanup: deleting unreferenced inode 10606624
EXT3-fs: dm-0: 14 orphan inodes deleted
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
security: 3 users, 6 roles, 889 types, 109 bools
security: 55 classes, 244452 rules
SELinux: Completing initialization.
SELinux: Setting up existing superblocks.
SELinux: initialized (dev dm-0, type ext3), uses xattr
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts
SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts
SELinux: initialized (dev devpts, type devpts), uses transition SIDs
SELinux: initialized (dev eventpollfs, type eventpollfs), uses
genfs_contexts
SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
SELinux: initialized (dev cpuset, type cpuset), not configured for labeling
SELinux: initialized (dev proc, type proc), uses genfs_contexts
SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
floppy0: no floppy controllers found
Intel(R) PRO/1000 Network Driver - version 6.3.9-k4-NAPI
Copyright (c) 1999-2005 Intel Corporation.
GSI 18 sharing vector 0xB9 and IRQ 18
ACPI: PCI Interrupt 0000:02:04.0[A] -> GSI 32 (level, low) -> IRQ 18
e1000: 0000:02:04.0: e1000_probe: (PCI:66MHz:32-bit) 00:14:22:b1:1a:33
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
hw_random: RNG not detected
MC: drivers/edac/edac_mc.c version edac_mc Ver: 2.0.0 Mar 28 2006
tolm = 80000, remapbase = ffc000, remaplimit = 0
EDAC MC0: Giving out device to "e752x_edac" E7520: PCI 0000:00:00.0
ACPI: Power Button (FF) [PWRF]
ibm_acpi: ec object not found
ACPI: Video Device [EVGA] (multi-head: no rom: yes post: no)
e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
EXT3 FS on dm-0, internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: initialized (dev sda1, type ext3), uses xattr
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Adding 2031608k swap on /dev/VolGroup00/LogVol01. Priority:-1 extents:1
across:2031608k
SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses
genfs_contexts
SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts
Bluetooth: Core ver 2.8
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.8
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.7
i2c /dev entries driver
SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
SELinux: initialized (dev autofs, type autofs), uses genfs_contexts
lp: driver loaded but no devices found
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
SELinux: initialized (dev smbfs, type smbfs), uses genfs_contexts
SELinux: initialized (dev smbfs, type smbfs), uses genfs_contexts
eth0: no IPv6 routers present
SELinux: initialized (dev smbfs, type smbfs), uses genfs_contexts
--
Paul Risenhoover - Director of Engineering - DAX Solutions, Inc. -
^ permalink raw reply
* Re: [RFC] Proposed structure for Regulatory/Geographical Wireless database
From: Larry Finger @ 2006-05-05 21:52 UTC (permalink / raw)
To: Dan Williams, netdev, Faidon Liambotis, Rick Jones, Ulrich Kunitz,
Harald Welte, Jouni Malinen, Christoph Hellwig
In-Reply-To: <1146863436.32242.23.camel@localhost.localdomain>
Dan Williams wrote:
> On Fri, 2006-05-05 at 15:14 -0500, Larry Finger wrote:
>> Thanks to all that responded to my earlier RFC. A number of changes in my thinking are based on
>> those comments, which came from Christoph Hellwig, Rick Jones, Ulrich Kunitz, Faidon Liambotis,
>> Jouni Malinen, and Harald Welte. The important points of my proposal are as follows:
>>
>> * The database will be maintained as a text file to be processed by a userland daemon that will
>> transform this database into the data structure needed by the ieee80211 code. In addition to the
>> regulatory data, this file will also contain the information needed for the daemon to set the size
>> of its data arrays dynamically.
>
> Can you explain a bit more about the dynamic array aspect here? What's
> that about? Shouldn't the geo-daemon be able to figure this stuff out
> automatically and tell the ieee80211 stack how many countries and groups
> there are? It has to parse the file anyway, so it should surely know
> how many groups and countries there are after parsing it. (or do I just
> not understand the issues...?)
The kernel only has a single geo object for each wireless interface initialized. The kernel routine
would state which country it wanted to the daemon, which would supply that one from the entities
created one when if parsed the database file. The dynamic aspect is to code the daemon in such a way
that changing the number of countries and/or groups will not necessitate changing the code in the
daemon.
>> * A new routine (ieee80211_init_geo ?) will be written to be called by the driver to load the geo
>> structure into the kernel. Information passed to the daemon will be the country code in ASCII and
>> whether the interface is to be used indoors or outdoors.
>>
>> * Checksum routines will be used to validate the data base. Such a simple scheme will not inhibit
>> anyone with moderate skills from hacking the channel/power settings, but such hacking will require
>> some effort.
>
> What I'm concerned about is error reporting. And as a distro packager,
> I don't want any user to have to touch the geo file. That's fine if
> they do, but nobody should _have_ to.
I agree.
> For error reporting, if the geo file does not exist, or contains invalid
> information, or if the checksum doesn't match for some reason, what's
> the failure case? It's not sufficient to just log that to dmesg and
> fail the attempt, because then a program like wpa_supplicant or
> NetworkManager will have no clue what the problem is if the driver just
> returns ENOENT or EFILESUCKS or whatever. This is the same problem we
> currently have with missing firmware. The failure case is not clearly
> recognizable by the client.
I plan to put the "unknown country" data into the init_geo routine. In case the geo database is not
available, has been corrupted, or the daemon is not running, the parameters will be the minimal set
of only bg channels 1-11 at minimum power and indoor usage. There would be a valid set of geo
parameters in the ieee80211 structure - likely not the ones that were wanted, but a valid set. In
addition, a failure code would be sent back to the driver, and the exact reason for the failure
logged to dmesg.
> If the geo data fails to be read, or fails to be validated by the
> driver, user apps that are trying to make connection attempts need to
> know exactly why the attempt failed, so they can inform users of the
> failure in a smart way. That information needs to come through the
> driver, because user apps that make network connection attempts
> shouldn't have to talk to the regulatory daemon _at all_.
Agreed.
> Conceptually, the regulatory/geo daemon is part of the kernel and the
> driver, and just happens to live in userspace because policy
> +kernel==ohmygodbad. But that means that it's the kernel's
> responsibility to marshal the error information back to clients of the
> wireless driver, not the clients problem to ask the regulatory/geo
> daemon, if it's actually running, what the heck the problem is and why
> the driver returned the error code it did.
>
> U NetworkManager geo-daemon
> ------------|-----------|-----------
> K | |
> driver/iee80211
>
> Think of it as a V, not a triangle. That's where we need to be WRT
> error reporting.
I'm not sure what additional error reporting mechanisms could/should be implemented. Any suggestions?
Larry
^ permalink raw reply
* Re: [RFC] Proposed structure for Regulatory/Geographical Wireless database
From: Larry Finger @ 2006-05-05 21:23 UTC (permalink / raw)
To: Uli Kunitz, netdev, Faidon Liambotis, Rick Jones, Harald Welte,
Jouni Malinen, Christoph Hellwig
In-Reply-To: <Pine.LNX.4.58.0605052256570.26787@p15091797.pureserver.info>
Uli Kunitz wrote:
> Larry Finger wrote:
>
>> * A new routine (ieee80211_init_geo ?) will be written to be called by the
>> driver to load the geo structure into the kernel. Information passed to the
>> daemon will be the country code in ASCII and whether the interface is to be
>> used indoors or outdoors.
>
> Would it be possible to support the regulatory domain codes as
> used in the outdated table 105 in Corrigendum 1 for 802.11b? The
> ZD1211 EEPROM contains only this code. An easy translation
> function would be sufficient. Maybe the group codes could be
> misused for it.
That certainly shouldn't be any difficulty. It could be done in the ZD1211 driver before it calls
the ieee80211_init_geo routine, or it could be done in the regulatory daemon. I assume that the
EEPROM contains X'10' for FCC regulations, X'31' for Spain, etc.
Larry
^ permalink raw reply
* Re: [RFC] Proposed structure for Regulatory/Geographical Wireless database
From: Dan Williams @ 2006-05-05 21:10 UTC (permalink / raw)
To: Larry Finger
Cc: netdev, Faidon Liambotis, Rick Jones, Ulrich Kunitz, Harald Welte,
Jouni Malinen, Christoph Hellwig
In-Reply-To: <445BB22B.30505@lwfinger.net>
On Fri, 2006-05-05 at 15:14 -0500, Larry Finger wrote:
> Thanks to all that responded to my earlier RFC. A number of changes in my thinking are based on
> those comments, which came from Christoph Hellwig, Rick Jones, Ulrich Kunitz, Faidon Liambotis,
> Jouni Malinen, and Harald Welte. The important points of my proposal are as follows:
>
> * The database will be maintained as a text file to be processed by a userland daemon that will
> transform this database into the data structure needed by the ieee80211 code. In addition to the
> regulatory data, this file will also contain the information needed for the daemon to set the size
> of its data arrays dynamically.
Can you explain a bit more about the dynamic array aspect here? What's
that about? Shouldn't the geo-daemon be able to figure this stuff out
automatically and tell the ieee80211 stack how many countries and groups
there are? It has to parse the file anyway, so it should surely know
how many groups and countries there are after parsing it. (or do I just
not understand the issues...?)
> * A new routine (ieee80211_init_geo ?) will be written to be called by the driver to load the geo
> structure into the kernel. Information passed to the daemon will be the country code in ASCII and
> whether the interface is to be used indoors or outdoors.
>
> * Checksum routines will be used to validate the data base. Such a simple scheme will not inhibit
> anyone with moderate skills from hacking the channel/power settings, but such hacking will require
> some effort.
What I'm concerned about is error reporting. And as a distro packager,
I don't want any user to have to touch the geo file. That's fine if
they do, but nobody should _have_ to.
For error reporting, if the geo file does not exist, or contains invalid
information, or if the checksum doesn't match for some reason, what's
the failure case? It's not sufficient to just log that to dmesg and
fail the attempt, because then a program like wpa_supplicant or
NetworkManager will have no clue what the problem is if the driver just
returns ENOENT or EFILESUCKS or whatever. This is the same problem we
currently have with missing firmware. The failure case is not clearly
recognizable by the client.
If the geo data fails to be read, or fails to be validated by the
driver, user apps that are trying to make connection attempts need to
know exactly why the attempt failed, so they can inform users of the
failure in a smart way. That information needs to come through the
driver, because user apps that make network connection attempts
shouldn't have to talk to the regulatory daemon _at all_.
Conceptually, the regulatory/geo daemon is part of the kernel and the
driver, and just happens to live in userspace because policy
+kernel==ohmygodbad. But that means that it's the kernel's
responsibility to marshal the error information back to clients of the
wireless driver, not the clients problem to ask the regulatory/geo
daemon, if it's actually running, what the heck the problem is and why
the driver returned the error code it did.
U NetworkManager geo-daemon
------------|-----------|-----------
K | |
driver/iee80211
Think of it as a V, not a triangle. That's where we need to be WRT
error reporting.
Dan
^ permalink raw reply
* Re: [RFC] Proposed structure for Regulatory/Geographical Wireless database
From: Uli Kunitz @ 2006-05-05 21:08 UTC (permalink / raw)
To: Larry Finger
Cc: netdev, Faidon Liambotis, Rick Jones, Ulrich Kunitz, Harald Welte,
Jouni Malinen, Christoph Hellwig
In-Reply-To: <445BB22B.30505@lwfinger.net>
Larry Finger wrote:
> * A new routine (ieee80211_init_geo ?) will be written to be called by the
> driver to load the geo structure into the kernel. Information passed to the
> daemon will be the country code in ASCII and whether the interface is to be
> used indoors or outdoors.
Would it be possible to support the regulatory domain codes as
used in the outdated table 105 in Corrigendum 1 for 802.11b? The
ZD1211 EEPROM contains only this code. An easy translation
function would be sufficient. Maybe the group codes could be
misused for it.
Uli
--
Uli Kunitz (kune@deine-taler.de)
^ permalink raw reply
* IPv6 connect() from site-local to global IPv6 address.
From: David Woodhouse @ 2006-05-05 21:00 UTC (permalink / raw)
To: NetDev
I've been using and testing IPv6 on a private network.
Machines have RFC1918 IPv4 addresses, with connectivity by NAT to the
outside world. They also have site-local IPv6 addresses. There is
approximately zero chance of getting corporate approval to have external
IPv6 connectivity.
Since updating the kernel to 2.6.16, I've got problems with external
connectivity to hosts which have both IPv4 and (Global) IPv6 addresses
in DNS. Glibc used to return the IPv4 address in the A record first, and
all was well. But now it returns the IPv6 address in the AAAA record
first, and I can't communicate with that. So I get a three-minute
timeout whenever I try to connect to anything in the outside which has
both A and AAAA records.
One of the things which glibc's implementation of RFC3484 address
selection (http://people.redhat.com/drepper/linux-rfc3484.html) does is
to perform a dummy connect() of a SOCK_DGRAM socket to each of the
potential addresses. On older kernels this used to fail when we
attempted to connect to a global IPv6 address and we didn't have a
global IPv6 address of our own...
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:8b0:10b:1:20d:93ff:fe7a:3f2c", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address)
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("81.187.2.168")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(33450), sin_addr=inet_addr("172.16.18.126")}, [16]) = 0
Trying 81.187.2.168...
On the newer kernel, the connect() succeeds:
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:8b0:10b:1:20d:93ff:fe7a:3f2c", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
getsockname(3, {sa_family=AF_INET6, sin6_port=htons(32772), inet_pton(AF_INET6, "::172.16.18.67", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("81.187.2.168")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(32772), sin_addr=inet_addr("172.16.18.67")}, [16]) = 0
Trying 2001:8b0:10b:1:20d:93ff:fe7a:3f2c...
Is this change in behaviour intentional? Is it useful?
How can we get sane behaviour from glibc again? What we had before was
ideal -- if we have an IPv6 default route _and_ we have a Global IPv6
address of our own, then return the Global IPv6 address in the AAAA
record first. Else return the IPv4 address in the A record.
--
dwmw2
^ permalink raw reply
* [RFC] Proposed structure for Regulatory/Geographical Wireless database
From: Larry Finger @ 2006-05-05 20:14 UTC (permalink / raw)
To: netdev, Faidon Liambotis, Rick Jones, Ulrich Kunitz, Harald Welte,
Jouni Malinen, Christoph Hellwig
Thanks to all that responded to my earlier RFC. A number of changes in my thinking are based on
those comments, which came from Christoph Hellwig, Rick Jones, Ulrich Kunitz, Faidon Liambotis,
Jouni Malinen, and Harald Welte. The important points of my proposal are as follows:
* The database will be maintained as a text file to be processed by a userland daemon that will
transform this database into the data structure needed by the ieee80211 code. In addition to the
regulatory data, this file will also contain the information needed for the daemon to set the size
of its data arrays dynamically.
* A new routine (ieee80211_init_geo ?) will be written to be called by the driver to load the geo
structure into the kernel. Information passed to the daemon will be the country code in ASCII and
whether the interface is to be used indoors or outdoors.
* Checksum routines will be used to validate the data base. Such a simple scheme will not inhibit
anyone with moderate skills from hacking the channel/power settings, but such hacking will require
some effort.
* Each channel in the resulting kernel data structure will have appropriate flags set indicating if
it is to be used indoors, outdoors, or both. In addition, if the channel should be used only for
passive scanning, a suitable flag will be set. In the 2.4 GHz band, a flag will indicate if it
should be used for 802.11b, otherwise both b and g mode will be assumed. In the 5.0 GHz bands, a
flag will be set if the channel is to conform with 802.11h or 802.11a standards.
The database consists of two sections. The first relates the Country Codes to a wireless group. The
second section describes the channel parameters for the groups. Shown below is a fragment showing
the Country Code - Group info for a few countries and the definitions for a few of the groups.
Please send me any comments, etc.
Larry
===================================================================
# text file for IEEE80211 Regulatory/Geographical information
#
# Version of 04 May 2006
#
# Information for dynamic array sizing
#
Number of Countries: 100
Number of Groups: 15
#
# Countries listed first
#
# group Country Code Description
#
1 AT Austria (Standard EU)
1 DE Germany (Standard EU)
2 FRI France Indoor (Not Guyana or La Reunion)
3 FRO France Outdoor (Not Guyana or La Reunion)
4 FR1 French Departments of Guyana and La Reunion Indoor
5 FR2 French Departments of Guyana and La Reunion Outdoor
.
.
.
9 US United States (FCC)
#
#
# Groups follow countries
#
Group 0 - Unspecified Country
#
# Band Ch. Range Ch. Spacing Power Flags
#
# Band - b, bg, a, or h
# Ch. Range - Minimum and Maximum Channels for this range
# Ch. Spacing - Number of channels between adjacent entries
# Power in mW EIRP
# Flag Codes
# B - Both Indoor and Outdoor
# I - Indoor Only
# O - Outdoor Only
# P - Passive Scan Only
#
bg 1 - 11 1 100 B
#
Group 1 - General European Union (EU)
#
bg 1 - 13 1 100 B
h 36 - 40 4 200 I
h 52 - 64 4 200 IP
h 100 - 140 4 1000 BP
#
Group 2 - France Indoor (Not Guyana or La Reunion)
#
bg 1 - 13 1 100 I
h 36 - 48 4 200 I
h 52 - 64 4 200 IP
h 100 - 140 4 1000 IP
#
Group 3 - France Outdoor (Not Guyana or La Reunion)
#
bg 1 - 8 1 100 O
bg 9 - 13 1 10 O
h 100 - 140 4 1000 OP
.
.
.
.
#
Group 9 - US (FCC)
#
bg 1 - 11 1 100 B
a 36 - 40 4 200 I
a 52 - 64 4 200 B
a 149 - 161 4 1000 B
#
^ permalink raw reply
* [PATCH 2/3] bcm43xx-d80211: fix whitespace
From: Stefano Brivio @ 2006-05-05 19:59 UTC (permalink / raw)
To: John W. Linville; +Cc: bcm43xx-dev, netdev
In-Reply-To: <20060505215542.25d310dd@localhost>
Fix whitespace.
Signed-off-by: Stefano Brivio <stefano.brivio@polimi.it>
Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 00:50:00.370034536 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 02:43:44.981535888 +0200
@@ -128,13 +128,13 @@
static struct pci_device_id bcm43xx_pci_tbl[] = {
/* Broadcom 4303 802.11b */
{ PCI_VENDOR_ID_BROADCOM, 0x4301, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
- /* Broadcom 4307 802.11b */
+ /* Broadcom 4307 802.11b */
{ PCI_VENDOR_ID_BROADCOM, 0x4307, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
- /* Broadcom 4318 802.11b/g */
+ /* Broadcom 4318 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4318, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4306 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4320, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
- /* Broadcom 4306 802.11a */
+ /* Broadcom 4306 802.11a */
// { PCI_VENDOR_ID_BROADCOM, 0x4321, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4309 802.11a/b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4324, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
--
Ciao
Stefano
^ permalink raw reply
* [PATCH 3/3] bcm43xx-d80211: add PCI ID for bcm4319
From: Stefano Brivio @ 2006-05-05 19:59 UTC (permalink / raw)
To: John W. Linville; +Cc: bcm43xx-dev, netdev
In-Reply-To: <20060505215542.25d310dd@localhost>
Add PCI ID for bcm4319.
Signed-off-by: Stefano Brivio <stefano.brivio@polimi.it>
Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 00:50:00.370034536 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 02:56:42.216378232 +0200
@@ -132,6 +132,8 @@ MODULE_PARM_DESC(fwpostfix, "Postfix for
{ PCI_VENDOR_ID_BROADCOM, 0x4307, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4318 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4318, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
+ /* Broadcom 4319 802.11b/g */
+ { PCI_VENDOR_ID_BROADCOM, 0x4319, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4306 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4320, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4306 802.11a */
--
Ciao
Stefano
^ permalink raw reply
* [PATCH 1/3] bcm43xx-d80211: check for valid MAC address in SPROM
From: Stefano Brivio @ 2006-05-05 19:55 UTC (permalink / raw)
To: John W. Linville; +Cc: bcm43xx-dev, netdev
Please apply to wireless-dev.
--
Check for valid MAC address in SPROM fields instead of relying on PHY type
while setting the MAC address in the networking subsystem, as some devices
have multiple PHYs.
Signed-off-by: Stefano Brivio <stefano.brivio@polimi.it>
Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 00:50:00.370034536 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 02:43:44.981535888 +0200
@@ -3482,7 +3482,7 @@
bcm43xx_pctl_set_crystal(bcm, 0);
/* Set the MAC address in the networking subsystem */
- if (bcm43xx_current_phy(bcm)->type == BCM43xx_PHYTYPE_A)
+ if (is_valid_ether_addr(bcm->sprom.et1macaddr))
memcpy(bcm->net_dev->dev_addr, bcm->sprom.et1macaddr, 6);
else
memcpy(bcm->net_dev->dev_addr, bcm->sprom.il0macaddr, 6);
--
Ciao
Stefano
^ permalink raw reply
* Re: sky2 1.3-rc1
From: Stephen Hemminger @ 2006-05-05 19:43 UTC (permalink / raw)
To: Daniel Drake
Cc: Thomas Glanzmann, Bill Hoover, Bertrand Jacquin, micheleschi,
netdev, teppic74
In-Reply-To: <445B9C93.4070406@gentoo.org>
On Fri, 05 May 2006 19:42:27 +0100
Daniel Drake <dsd@gentoo.org> wrote:
> Stephen Hemminger wrote:
> > What is happening is that if there is a misconfiguration and irq routing
> > is messed up (ie edge trigged). The driver will degenerate to polling every 100ms.
> > If your system is this misconfigured, then ACPI or the BIOS needs to be fixed
> > and the driver really only needs to work well enough to get the bug report out ;-)
>
> Ok, thanks for the explanation.
>
> Can you give any hints as to how we can classify this misconfiguration?
> Barry's system has a level triggered IRQ assigned to sky2, and that IRQ
> is not shared:
>
> http://bugs.gentoo.org/show_bug.cgi?id=132056#c3
>
> I'm just looking for something I can take to the ACPI developers, other
> than "its broken because Stephen said so" ;)
Try running idle_timeout=0 module parameter. In that case there will be no
polling timer. If it just hangs, then the problem is missed interrupt.
You could use this to see if you are getting irq's
--- sky2.orig/drivers/net/sky2.c
+++ sky2/drivers/net/sky2.c
@@ -2125,6 +2125,9 @@ static int sky2_poll(struct net_device *
int work_done = 0;
u32 status = sky2_read32(hw, B0_Y2_SP_EISR);
+ if (netif_msg_intr((struct sky2_port *) netdev_priv(dev0)))
+ printk(KERN_DEBUG PFX "poll status %#x\n", status);
+
if (status & Y2_IS_HW_ERR)
sky2_hw_intr(hw);
@@ -2183,6 +2186,9 @@ static irqreturn_t sky2_intr(int irq, vo
if (status == 0 || status == ~0)
return IRQ_NONE;
+ if (netif_msg_intr((struct sky2_port *) netdev_priv(dev0)))
+ printk(KERN_DEBUG PFX "irq status %#x\n", status);
+
prefetch(&hw->st_le[hw->st_idx]);
if (likely(__netif_rx_schedule_prep(dev0)))
__netif_rx_schedule(dev0);
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox