* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Christoph Lameter @ 2007-08-14 22:51 UTC (permalink / raw)
To: Chris Snook
Cc: linux-kernel, linux-arch, torvalds, netdev, akpm, ak,
heiko.carstens, davem, schwidefsky, wensong, horms, wjiang,
cfriesen, zlynx, rpjday, jesper.juhl
In-Reply-To: <46C23078.4040109@redhat.com>
On Tue, 14 Aug 2007, Chris Snook wrote:
> But barriers force a flush of *everything* in scope, which we generally don't
> want. On the other hand, we pretty much always want to flush atomic_*
> operations. One way or another, we should be restricting the volatile
> behavior to the thing that needs it. On most architectures, this patch set
> just moves that from the declaration, where it is considered harmful, to the
> use, where it is considered an occasional necessary evil.
Then we would need
atomic_read()
and
atomic_read_volatile()
atomic_read_volatile() would imply an object sized memory barrier before
and after?
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Satyam Sharma @ 2007-08-14 23:08 UTC (permalink / raw)
To: Christoph Lameter
Cc: Chris Snook, Linux Kernel Mailing List, linux-arch, torvalds,
netdev, Andrew Morton, ak, heiko.carstens, davem, schwidefsky,
wensong, horms, wjiang, cfriesen, zlynx, rpjday, jesper.juhl,
segher
In-Reply-To: <Pine.LNX.4.64.0708141529310.32693@schroedinger.engr.sgi.com>
On Tue, 14 Aug 2007, Christoph Lameter wrote:
> On Thu, 9 Aug 2007, Chris Snook wrote:
>
> > This patchset makes the behavior of atomic_read uniform by removing the
> > volatile keyword from all atomic_t and atomic64_t definitions that currently
> > have it, and instead explicitly casts the variable as volatile in
> > atomic_read(). This leaves little room for creative optimization by the
> > compiler, and is in keeping with the principles behind "volatile considered
> > harmful".
>
> volatile is generally harmful even in atomic_read(). Barriers control
> visibility and AFAICT things are fine.
Frankly, I don't see the need for this series myself either. Personal
opinion (others may differ), but I consider "volatile" to be a sad /
unfortunate wart in C (numerous threads on this list and on the gcc
lists/bugzilla over the years stand testimony to this) and if we _can_
steer clear of it, then why not -- why use this ill-defined primitive
whose implementation has often differed over compiler versions and
platforms? Granted, barrier() _is_ heavy-handed in that it makes the
optimizer forget _everything_, but then somebody did post a forget()
macro on this thread itself ...
[ BTW, why do we want the compiler to not optimize atomic_read()'s in
the first place? Atomic ops guarantee atomicity, which has nothing
to do with "volatility" -- users that expect "volatility" from
atomic ops are the ones who must be fixed instead, IMHO. ]
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Chris Snook @ 2007-08-14 23:04 UTC (permalink / raw)
To: Satyam Sharma
Cc: Christoph Lameter, Linux Kernel Mailing List, linux-arch,
torvalds, netdev, Andrew Morton, ak, heiko.carstens, davem,
schwidefsky, wensong, horms, wjiang, cfriesen, zlynx, rpjday,
jesper.juhl, segher
In-Reply-To: <alpine.LFD.0.999.0708150417240.6482@enigma.security.iitk.ac.in>
Satyam Sharma wrote:
>
> On Tue, 14 Aug 2007, Christoph Lameter wrote:
>
>> On Thu, 9 Aug 2007, Chris Snook wrote:
>>
>>> This patchset makes the behavior of atomic_read uniform by removing the
>>> volatile keyword from all atomic_t and atomic64_t definitions that currently
>>> have it, and instead explicitly casts the variable as volatile in
>>> atomic_read(). This leaves little room for creative optimization by the
>>> compiler, and is in keeping with the principles behind "volatile considered
>>> harmful".
>> volatile is generally harmful even in atomic_read(). Barriers control
>> visibility and AFAICT things are fine.
>
> Frankly, I don't see the need for this series myself either. Personal
> opinion (others may differ), but I consider "volatile" to be a sad /
> unfortunate wart in C (numerous threads on this list and on the gcc
> lists/bugzilla over the years stand testimony to this) and if we _can_
> steer clear of it, then why not -- why use this ill-defined primitive
> whose implementation has often differed over compiler versions and
> platforms? Granted, barrier() _is_ heavy-handed in that it makes the
> optimizer forget _everything_, but then somebody did post a forget()
> macro on this thread itself ...
>
> [ BTW, why do we want the compiler to not optimize atomic_read()'s in
> the first place? Atomic ops guarantee atomicity, which has nothing
> to do with "volatility" -- users that expect "volatility" from
> atomic ops are the ones who must be fixed instead, IMHO. ]
Because atomic operations are generally used for synchronization, which requires
volatile behavior. Most such codepaths currently use an inefficient barrier().
Some forget to and we get bugs, because people assume that atomic_read()
actually reads something, and atomic_write() actually writes something. Worse,
these are architecture-specific, even compiler version-specific bugs that are
often difficult to track down.
-- Chris
^ permalink raw reply
* [PATCH] pcnet32: add suspend and resume capability
From: Don Fry @ 2007-08-14 22:08 UTC (permalink / raw)
To: jgarzik; +Cc: netdev
Add suspend and resume capability to the driver.
Tested both to ram and to disk on x86_64 platform.
Signed-off-by: Don Fry <pcnet32@verizon.net>
---
--- linux-2.6.23-rc3/drivers/net/pcnet32.c.orig 2007-08-14 13:52:24.000000000 -0700
+++ linux-2.6.23-rc3/drivers/net/pcnet32.c 2007-08-14 14:16:55.000000000 -0700
@@ -23,11 +23,11 @@
#define DRV_NAME "pcnet32"
#ifdef CONFIG_PCNET32_NAPI
-#define DRV_VERSION "1.33-NAPI"
+#define DRV_VERSION "1.34-NAPI"
#else
-#define DRV_VERSION "1.33"
+#define DRV_VERSION "1.34"
#endif
-#define DRV_RELDATE "27.Jun.2006"
+#define DRV_RELDATE "14.Aug.2007"
#define PFX DRV_NAME ": "
static const char *const version =
@@ -2943,6 +2943,33 @@ static void pcnet32_watchdog(struct net_
mod_timer(&(lp->watchdog_timer), PCNET32_WATCHDOG_TIMEOUT);
}
+static int pcnet32_pm_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ struct net_device *dev = pci_get_drvdata(pdev);
+
+ if (netif_running(dev)) {
+ netif_device_detach(dev);
+ pcnet32_close(dev);
+ }
+ pci_save_state(pdev);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
+ return 0;
+}
+
+static int pcnet32_pm_resume(struct pci_dev *pdev)
+{
+ struct net_device *dev = pci_get_drvdata(pdev);
+
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+
+ if (netif_running(dev)) {
+ pcnet32_open(dev);
+ netif_device_attach(dev);
+ }
+ return 0;
+}
+
static void __devexit pcnet32_remove_one(struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
@@ -2966,6 +2993,8 @@ static struct pci_driver pcnet32_driver
.probe = pcnet32_probe_pci,
.remove = __devexit_p(pcnet32_remove_one),
.id_table = pcnet32_pci_tbl,
+ .suspend = pcnet32_pm_suspend,
+ .resume = pcnet32_pm_resume,
};
/* An additional parameter that may be passed in... */
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Christoph Lameter @ 2007-08-14 23:14 UTC (permalink / raw)
To: Chris Snook
Cc: Satyam Sharma, Linux Kernel Mailing List, linux-arch, torvalds,
netdev, Andrew Morton, ak, heiko.carstens, davem, schwidefsky,
wensong, horms, wjiang, cfriesen, zlynx, rpjday, jesper.juhl,
segher
In-Reply-To: <46C2350A.1010807@redhat.com>
On Tue, 14 Aug 2007, Chris Snook wrote:
> Because atomic operations are generally used for synchronization, which
> requires volatile behavior. Most such codepaths currently use an inefficient
> barrier(). Some forget to and we get bugs, because people assume that
> atomic_read() actually reads something, and atomic_write() actually writes
> something. Worse, these are architecture-specific, even compiler
> version-specific bugs that are often difficult to track down.
Looks like we need to have lock and unlock semantics?
atomic_read()
which has no barrier or volatile implications.
atomic_read_for_lock
Acquire semantics?
atomic_read_for_unlock
Release semantics?
^ permalink raw reply
* Re: [PATCH 2/13] cxgb3 - Update rx coalescing length
From: Divy Le Ray @ 2007-08-14 23:22 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel, Steve Wise
In-Reply-To: <46C14096.3020905@garzik.org>
Jeff Garzik wrote:
>
> Divy Le Ray wrote:
> > From: Divy Le Ray <divy@chelsio.com>
> >
> > Set max Rx coalescing length to 12288
> >
> > Signed-off-by: Divy Le Ray <divy@chelsio.com>
> > ---
> >
> > drivers/net/cxgb3/common.h | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
> > index c46c249..55922ed 100644
> > --- a/drivers/net/cxgb3/common.h
> > +++ b/drivers/net/cxgb3/common.h
> > @@ -104,7 +104,7 @@ enum {
> > PROTO_SRAM_LINES = 128, /* size of TP sram */
> > };
> >
> > -#define MAX_RX_COALESCING_LEN 16224U
> > +#define MAX_RX_COALESCING_LEN 12288U
>
> neither the patch nor description explains -why-
>
We're seeing back pressure from PCIe with large bursts, this patch
allows to cut down on the burst size.
Divy
^ permalink raw reply
* Re: [PATCH 4/13] cxgb3 - use immediate data for offload Tx
From: Divy Le Ray @ 2007-08-14 23:25 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel, Steve Wise
In-Reply-To: <46C14106.4080604@garzik.org>
Jeff Garzik wrote:
>
> Divy Le Ray wrote:
> > From: Divy Le Ray <divy@chelsio.com>
> >
> > Send small TX_DATA work requests as immediate data even when
> > there are fragments.
> >
> > Signed-off-by: Divy Le Ray <divy@chelsio.com>
> > ---
> >
> > drivers/net/cxgb3/sge.c | 17 +++++++++++------
> > 1 files changed, 11 insertions(+), 6 deletions(-)
>
> needs additional explanation. don't just describe the new post-change
> behavior, describe why this change is needed.
>
>
It's an optimization avoiding doing multiple DMAs for small fragmented
packets.
The driver already implements this optimization for small contiguous
packets.
Divy
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Paul E. McKenney @ 2007-08-14 23:26 UTC (permalink / raw)
To: Satyam Sharma
Cc: Christoph Lameter, Chris Snook, Linux Kernel Mailing List,
linux-arch, torvalds, netdev, Andrew Morton, ak, heiko.carstens,
davem, schwidefsky, wensong, horms, wjiang, cfriesen, zlynx,
rpjday, jesper.juhl, segher
In-Reply-To: <alpine.LFD.0.999.0708150417240.6482@enigma.security.iitk.ac.in>
On Wed, Aug 15, 2007 at 04:38:54AM +0530, Satyam Sharma wrote:
>
>
> On Tue, 14 Aug 2007, Christoph Lameter wrote:
>
> > On Thu, 9 Aug 2007, Chris Snook wrote:
> >
> > > This patchset makes the behavior of atomic_read uniform by removing the
> > > volatile keyword from all atomic_t and atomic64_t definitions that currently
> > > have it, and instead explicitly casts the variable as volatile in
> > > atomic_read(). This leaves little room for creative optimization by the
> > > compiler, and is in keeping with the principles behind "volatile considered
> > > harmful".
> >
> > volatile is generally harmful even in atomic_read(). Barriers control
> > visibility and AFAICT things are fine.
>
> Frankly, I don't see the need for this series myself either. Personal
> opinion (others may differ), but I consider "volatile" to be a sad /
> unfortunate wart in C (numerous threads on this list and on the gcc
> lists/bugzilla over the years stand testimony to this) and if we _can_
> steer clear of it, then why not -- why use this ill-defined primitive
> whose implementation has often differed over compiler versions and
> platforms? Granted, barrier() _is_ heavy-handed in that it makes the
> optimizer forget _everything_, but then somebody did post a forget()
> macro on this thread itself ...
>
> [ BTW, why do we want the compiler to not optimize atomic_read()'s in
> the first place? Atomic ops guarantee atomicity, which has nothing
> to do with "volatility" -- users that expect "volatility" from
> atomic ops are the ones who must be fixed instead, IMHO. ]
Interactions between mainline code and interrupt/NMI handlers on the same
CPU (for example, when both are using per-CPU variables. See examples
previously posted in this thread, or look at the rcu_read_lock() and
rcu_read_unlock() implementations in http://lkml.org/lkml/2007/8/7/280.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 5/13] cxgb3 - Expose HW memory page info
From: Divy Le Ray @ 2007-08-14 23:27 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel, swise
In-Reply-To: <46C14140.2000104@garzik.org>
Jeff Garzik wrote:
> Divy Le Ray wrote:
>> From: Divy Le Ray <divy@chelsio.com>
>>
>> Let the RDMA driver get HW page info to work around HW issues.
>> Assign explicit enum values.
>>
>> Signed-off-by: Divy Le Ray <divy@chelsio.com>
>
> "HW issues" -- you need to go into far more detail, when adding a new
> interface. what hw issues? why was this the best/only solution?
>
>
A HW issue requires limiting the receive window size to 23 pages of
internal memory.
These pages can be configured to different sizes, thus the RDMA driver
needs to know the
page size to enforce the upper limit.
Divy
^ permalink raw reply
* Re: [PATCH 9/13] cxgb3 - Update internal memory management
From: Divy Le Ray @ 2007-08-15 0:09 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel, Steve Wise
In-Reply-To: <46C14189.8010304@garzik.org>
Jeff Garzik wrote:
>
> Divy Le Ray wrote:
> > From: Divy Le Ray <divy@chelsio.com>
> >
> > Set PM1 internal memory to round robin mode
> >
> > Signed-off-by: Divy Le Ray <divy@chelsio.com>
>
> why?
>
For multiport adapters, it balances access to this internal memory.
Divy
^ permalink raw reply
* Re: [PATCH] econet: remove econet_packet_type on unload
From: David Miller @ 2007-08-15 0:24 UTC (permalink / raw)
To: adobriyan; +Cc: akpm, netdev
In-Reply-To: <20070814212553.GB5873@martell.zuzino.mipt.ru>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Wed, 15 Aug 2007 01:25:53 +0400
> Steps to reproduce:
>
> modprobe econet
> rmmod econet
> modprobe econet
>
> Unable to handle kernel paging request at ffffffff8870a098 RIP:
> [<ffffffff8040bfb8>] dev_add_pack+0x48/0x90
...
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Patch applied, thanks a lot Alexey.
^ permalink raw reply
* Re: [PATCH] ax25: don't free pointers to statically allocated data
From: David Miller @ 2007-08-15 0:25 UTC (permalink / raw)
To: adobriyan; +Cc: akpm, netdev, linux-hams
In-Reply-To: <20070814193038.GA5873@martell.zuzino.mipt.ru>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Tue, 14 Aug 2007 23:30:38 +0400
> commit 8d5cf596d10d740b69b5f4bbdb54b85abf75810d started to add statically
> allocated ax25_protocol's to list. However kfree() was still in place waiting
> for unsuspecting ones on module removal.
>
> Steps to reproduce:
>
> modprobe netrom
> rmmod netrom
>
> P.S.: code would benefit greatly from list_add/list_del usage
>
> kernel BUG at mm/slab.c:592!
> invalid opcode: 0000 [1] PREEMPT SMP
...
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Also applied, thanks a lot.
^ permalink raw reply
* Please pull 'fixes-davem' branch of wireless-2.6
From: John W. Linville @ 2007-08-15 0:32 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
These are a few more items intended for 2.6.23.
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-davem
Thanks!
John
---
The following changes since commit 39d3520c92cf7a28c07229ca00cc35a1e8026c77:
Linus Torvalds (1):
Linux 2.6.23-rc3
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-davem
Johannes Berg (1):
mac80211: fix tx status frame code
John W. Linville (1):
mac80211: probe for hidden SSIDs in pre-auth scan
net/mac80211/ieee80211.c | 1 -
net/mac80211/ieee80211_sta.c | 6 +++++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index 8ec5ed1..7286c38 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -4678,7 +4678,6 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb,
memset(skb->cb, 0, sizeof(skb->cb));
netif_rx(skb);
skb = skb2;
- break;
}
}
out:
diff --git a/net/mac80211/ieee80211_sta.c b/net/mac80211/ieee80211_sta.c
index 7ba352e..0d99b68 100644
--- a/net/mac80211/ieee80211_sta.c
+++ b/net/mac80211/ieee80211_sta.c
@@ -2154,7 +2154,11 @@ static int ieee80211_sta_config_auth(struct net_device *dev,
return 0;
} else {
if (ifsta->state != IEEE80211_AUTHENTICATE) {
- ieee80211_sta_start_scan(dev, NULL, 0);
+ if (ifsta->auto_ssid_sel)
+ ieee80211_sta_start_scan(dev, NULL, 0);
+ else
+ ieee80211_sta_start_scan(dev, ifsta->ssid,
+ ifsta->ssid_len);
ifsta->state = IEEE80211_AUTHENTICATE;
set_bit(IEEE80211_STA_REQ_AUTH, &ifsta->request);
} else
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply related
* Please pull 'upstream-davem' branch of wireless-2.6
From: John W. Linville @ 2007-08-15 0:34 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070815003234.GI7198-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
More items intended for 2.6.24, based-off the preceding fixes-davem
request.
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-davem
Thanks!
John
---
The following changes since commit b9bf1e60a294fc7795d5198f94a917290e52865b:
John W. Linville (1):
mac80211: probe for hidden SSIDs in pre-auth scan
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-davem
Johannes Berg (1):
radiotap parser: accept all other fields
Larry Finger (1):
mac80211: Add SIOCGIWTXPOWER routine
net/mac80211/ieee80211_ioctl.c | 16 +++++++++++++++-
net/wireless/radiotap.c | 6 +++++-
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/ieee80211_ioctl.c b/net/mac80211/ieee80211_ioctl.c
index e7904db..f459d89 100644
--- a/net/mac80211/ieee80211_ioctl.c
+++ b/net/mac80211/ieee80211_ioctl.c
@@ -798,6 +798,20 @@ static int ieee80211_ioctl_giwrate(struct net_device *dev,
return 0;
}
+static int ieee80211_ioctl_giwtxpower(struct net_device *dev,
+ struct iw_request_info *info,
+ union iwreq_data *data, char *extra)
+{
+ struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
+
+ data->txpower.fixed = 1;
+ data->txpower.disabled = !(local->hw.conf.radio_enabled);
+ data->txpower.value = local->hw.conf.power_level;
+ data->txpower.flags = IW_TXPOW_DBM;
+
+ return 0;
+}
+
static int ieee80211_ioctl_siwrts(struct net_device *dev,
struct iw_request_info *info,
struct iw_param *rts, char *extra)
@@ -1580,7 +1594,7 @@ static const iw_handler ieee80211_handler[] =
(iw_handler) ieee80211_ioctl_siwfrag, /* SIOCSIWFRAG */
(iw_handler) ieee80211_ioctl_giwfrag, /* SIOCGIWFRAG */
(iw_handler) NULL, /* SIOCSIWTXPOW */
- (iw_handler) NULL, /* SIOCGIWTXPOW */
+ (iw_handler) ieee80211_ioctl_giwtxpower, /* SIOCGIWTXPOW */
(iw_handler) ieee80211_ioctl_siwretry, /* SIOCSIWRETRY */
(iw_handler) ieee80211_ioctl_giwretry, /* SIOCGIWRETRY */
(iw_handler) ieee80211_ioctl_siwencode, /* SIOCSIWENCODE */
diff --git a/net/wireless/radiotap.c b/net/wireless/radiotap.c
index 68c11d0..28fbd0b 100644
--- a/net/wireless/radiotap.c
+++ b/net/wireless/radiotap.c
@@ -161,7 +161,11 @@ int ieee80211_radiotap_iterator_next(
[IEEE80211_RADIOTAP_DBM_TX_POWER] = 0x11,
[IEEE80211_RADIOTAP_ANTENNA] = 0x11,
[IEEE80211_RADIOTAP_DB_ANTSIGNAL] = 0x11,
- [IEEE80211_RADIOTAP_DB_ANTNOISE] = 0x11
+ [IEEE80211_RADIOTAP_DB_ANTNOISE] = 0x11,
+ [IEEE80211_RADIOTAP_RX_FLAGS] = 0x22,
+ [IEEE80211_RADIOTAP_TX_FLAGS] = 0x22,
+ [IEEE80211_RADIOTAP_RTS_RETRIES] = 0x11,
+ [IEEE80211_RADIOTAP_DATA_RETRIES] = 0x11,
/*
* add more here as they are defined in
* include/net/ieee80211_radiotap.h
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply related
* Please pull 'upstream-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2007-08-15 0:36 UTC (permalink / raw)
To: jeff-o2qLIJkoznsdnm+yROfE0A
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
A few items intended for 2.6.24.
Individual patches here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-jgarzik/
Thanks!
John
---
The following changes since commit 39d3520c92cf7a28c07229ca00cc35a1e8026c77:
Linus Torvalds (1):
Linux 2.6.23-rc3
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-jgarzik
Daniel Drake (2):
zd1211rw: Add ID for Sitecom WL-162
zd1211rw: Add ID for ZyXEL M-202 XtremeMIMO
Mariusz Kozlowski (1):
drivers/net/wireless/wl3501_cs.c: remove redundant memset
Ulrich Kunitz (2):
zd1211rw: removed noisy debug messages
zd1211rw: consistent handling of ZD1211 specific rates
drivers/net/wireless/wl3501_cs.c | 1 -
drivers/net/wireless/zd1211rw/zd_chip.c | 69 +++++++-----------
drivers/net/wireless/zd1211rw/zd_ieee80211.h | 43 +++++++----
drivers/net/wireless/zd1211rw/zd_mac.c | 99 +++++++-------------------
drivers/net/wireless/zd1211rw/zd_mac.h | 65 +++++++++++------
drivers/net/wireless/zd1211rw/zd_usb.c | 2 +
6 files changed, 128 insertions(+), 151 deletions(-)
diff --git a/drivers/net/wireless/wl3501_cs.c b/drivers/net/wireless/wl3501_cs.c
index c8b5c22..62b8669 100644
--- a/drivers/net/wireless/wl3501_cs.c
+++ b/drivers/net/wireless/wl3501_cs.c
@@ -1841,7 +1841,6 @@ static int wl3501_get_encode(struct net_device *dev,
tocopy = min_t(u8, len_keys, wrqu->encoding.length);
tocopy = min_t(u8, tocopy, 100);
wrqu->encoding.length = tocopy;
- memset(extra, 0, tocopy);
memcpy(extra, keys, tocopy);
out:
return rc;
diff --git a/drivers/net/wireless/zd1211rw/zd_chip.c b/drivers/net/wireless/zd1211rw/zd_chip.c
index c39f198..4959042 100644
--- a/drivers/net/wireless/zd1211rw/zd_chip.c
+++ b/drivers/net/wireless/zd1211rw/zd_chip.c
@@ -500,8 +500,6 @@ int zd_chip_lock_phy_regs(struct zd_chip *chip)
return r;
}
- dev_dbg_f(zd_chip_dev(chip),
- "CR_REG1: 0x%02x -> 0x%02x\n", tmp, tmp & ~UNLOCK_PHY_REGS);
tmp &= ~UNLOCK_PHY_REGS;
r = zd_iowrite32_locked(chip, tmp, CR_REG1);
@@ -523,8 +521,6 @@ int zd_chip_unlock_phy_regs(struct zd_chip *chip)
return r;
}
- dev_dbg_f(zd_chip_dev(chip),
- "CR_REG1: 0x%02x -> 0x%02x\n", tmp, tmp | UNLOCK_PHY_REGS);
tmp |= UNLOCK_PHY_REGS;
r = zd_iowrite32_locked(chip, tmp, CR_REG1);
@@ -841,8 +837,6 @@ static int get_aw_pt_bi(struct zd_chip *chip, struct aw_pt_bi *s)
s->atim_wnd_period = values[0];
s->pre_tbtt = values[1];
s->beacon_interval = values[2];
- dev_dbg_f(zd_chip_dev(chip), "aw %u pt %u bi %u\n",
- s->atim_wnd_period, s->pre_tbtt, s->beacon_interval);
return 0;
}
@@ -864,9 +858,6 @@ static int set_aw_pt_bi(struct zd_chip *chip, struct aw_pt_bi *s)
reqs[2].addr = CR_BCN_INTERVAL;
reqs[2].value = s->beacon_interval;
- dev_dbg_f(zd_chip_dev(chip),
- "aw %u pt %u bi %u\n", s->atim_wnd_period, s->pre_tbtt,
- s->beacon_interval);
return zd_iowrite32a_locked(chip, reqs, ARRAY_SIZE(reqs));
}
@@ -1018,19 +1009,19 @@ int zd_chip_set_rts_cts_rate_locked(struct zd_chip *chip,
u32 value = 0;
/* Modulation bit */
- if (ZD_CS_TYPE(rts_rate) == ZD_CS_OFDM)
+ if (ZD_MODULATION_TYPE(rts_rate) == ZD_OFDM)
rts_mod = ZD_RX_OFDM;
dev_dbg_f(zd_chip_dev(chip), "rts_rate=%x preamble=%x\n",
rts_rate, preamble);
- value |= rts_rate << RTSCTS_SH_RTS_RATE;
+ value |= ZD_PURE_RATE(rts_rate) << RTSCTS_SH_RTS_RATE;
value |= rts_mod << RTSCTS_SH_RTS_MOD_TYPE;
value |= preamble << RTSCTS_SH_RTS_PMB_TYPE;
value |= preamble << RTSCTS_SH_CTS_PMB_TYPE;
/* We always send 11M self-CTS messages, like the vendor driver. */
- value |= ZD_CCK_RATE_11M << RTSCTS_SH_CTS_RATE;
+ value |= ZD_PURE_RATE(ZD_CCK_RATE_11M) << RTSCTS_SH_CTS_RATE;
value |= ZD_RX_CCK << RTSCTS_SH_CTS_MOD_TYPE;
return zd_iowrite32_locked(chip, value, CR_RTS_CTS_RATE);
@@ -1160,16 +1151,12 @@ out:
static int update_pwr_int(struct zd_chip *chip, u8 channel)
{
u8 value = chip->pwr_int_values[channel - 1];
- dev_dbg_f(zd_chip_dev(chip), "channel %d pwr_int %#04x\n",
- channel, value);
return zd_iowrite16_locked(chip, value, CR31);
}
static int update_pwr_cal(struct zd_chip *chip, u8 channel)
{
u8 value = chip->pwr_cal_values[channel-1];
- dev_dbg_f(zd_chip_dev(chip), "channel %d pwr_cal %#04x\n",
- channel, value);
return zd_iowrite16_locked(chip, value, CR68);
}
@@ -1184,9 +1171,6 @@ static int update_ofdm_cal(struct zd_chip *chip, u8 channel)
ioreqs[2].addr = CR65;
ioreqs[2].value = chip->ofdm_cal_values[OFDM_54M_INDEX][channel-1];
- dev_dbg_f(zd_chip_dev(chip),
- "channel %d ofdm_cal 36M %#04x 48M %#04x 54M %#04x\n",
- channel, ioreqs[0].value, ioreqs[1].value, ioreqs[2].value);
return zd_iowrite16a_locked(chip, ioreqs, ARRAY_SIZE(ioreqs));
}
@@ -1344,7 +1328,7 @@ int zd_chip_set_basic_rates_locked(struct zd_chip *chip, u16 cr_rates)
return zd_iowrite32_locked(chip, cr_rates, CR_BASIC_RATE_TBL);
}
-static int ofdm_qual_db(u8 status_quality, u8 rate, unsigned int size)
+static int ofdm_qual_db(u8 status_quality, u8 zd_rate, unsigned int size)
{
static const u16 constants[] = {
715, 655, 585, 540, 470, 410, 360, 315,
@@ -1358,7 +1342,7 @@ static int ofdm_qual_db(u8 status_quality, u8 rate, unsigned int size)
/* It seems that their quality parameter is somehow per signal
* and is now transferred per bit.
*/
- switch (rate) {
+ switch (zd_rate) {
case ZD_OFDM_RATE_6M:
case ZD_OFDM_RATE_12M:
case ZD_OFDM_RATE_24M:
@@ -1385,7 +1369,7 @@ static int ofdm_qual_db(u8 status_quality, u8 rate, unsigned int size)
break;
}
- switch (rate) {
+ switch (zd_rate) {
case ZD_OFDM_RATE_6M:
case ZD_OFDM_RATE_9M:
i += 3;
@@ -1409,11 +1393,11 @@ static int ofdm_qual_db(u8 status_quality, u8 rate, unsigned int size)
return i;
}
-static int ofdm_qual_percent(u8 status_quality, u8 rate, unsigned int size)
+static int ofdm_qual_percent(u8 status_quality, u8 zd_rate, unsigned int size)
{
int r;
- r = ofdm_qual_db(status_quality, rate, size);
+ r = ofdm_qual_db(status_quality, zd_rate, size);
ZD_ASSERT(r >= 0);
if (r < 0)
r = 0;
@@ -1474,12 +1458,17 @@ static int cck_qual_percent(u8 status_quality)
return r <= 100 ? r : 100;
}
+static inline u8 zd_rate_from_ofdm_plcp_header(const void *rx_frame)
+{
+ return ZD_OFDM | zd_ofdm_plcp_header_rate(rx_frame);
+}
+
u8 zd_rx_qual_percent(const void *rx_frame, unsigned int size,
const struct rx_status *status)
{
return (status->frame_status&ZD_RX_OFDM) ?
ofdm_qual_percent(status->signal_quality_ofdm,
- zd_ofdm_plcp_header_rate(rx_frame),
+ zd_rate_from_ofdm_plcp_header(rx_frame),
size) :
cck_qual_percent(status->signal_quality_cck);
}
@@ -1495,32 +1484,32 @@ u8 zd_rx_strength_percent(u8 rssi)
u16 zd_rx_rate(const void *rx_frame, const struct rx_status *status)
{
static const u16 ofdm_rates[] = {
- [ZD_OFDM_RATE_6M] = 60,
- [ZD_OFDM_RATE_9M] = 90,
- [ZD_OFDM_RATE_12M] = 120,
- [ZD_OFDM_RATE_18M] = 180,
- [ZD_OFDM_RATE_24M] = 240,
- [ZD_OFDM_RATE_36M] = 360,
- [ZD_OFDM_RATE_48M] = 480,
- [ZD_OFDM_RATE_54M] = 540,
+ [ZD_OFDM_PLCP_RATE_6M] = 60,
+ [ZD_OFDM_PLCP_RATE_9M] = 90,
+ [ZD_OFDM_PLCP_RATE_12M] = 120,
+ [ZD_OFDM_PLCP_RATE_18M] = 180,
+ [ZD_OFDM_PLCP_RATE_24M] = 240,
+ [ZD_OFDM_PLCP_RATE_36M] = 360,
+ [ZD_OFDM_PLCP_RATE_48M] = 480,
+ [ZD_OFDM_PLCP_RATE_54M] = 540,
};
u16 rate;
if (status->frame_status & ZD_RX_OFDM) {
+ /* Deals with PLCP OFDM rate (not zd_rates) */
u8 ofdm_rate = zd_ofdm_plcp_header_rate(rx_frame);
rate = ofdm_rates[ofdm_rate & 0xf];
} else {
- u8 cck_rate = zd_cck_plcp_header_rate(rx_frame);
- switch (cck_rate) {
- case ZD_CCK_SIGNAL_1M:
+ switch (zd_cck_plcp_header_signal(rx_frame)) {
+ case ZD_CCK_PLCP_SIGNAL_1M:
rate = 10;
break;
- case ZD_CCK_SIGNAL_2M:
+ case ZD_CCK_PLCP_SIGNAL_2M:
rate = 20;
break;
- case ZD_CCK_SIGNAL_5M5:
+ case ZD_CCK_PLCP_SIGNAL_5M5:
rate = 55;
break;
- case ZD_CCK_SIGNAL_11M:
+ case ZD_CCK_PLCP_SIGNAL_11M:
rate = 110;
break;
default:
@@ -1638,7 +1627,5 @@ int zd_chip_set_multicast_hash(struct zd_chip *chip,
{ CR_GROUP_HASH_P2, hash->high },
};
- dev_dbg_f(zd_chip_dev(chip), "hash l 0x%08x h 0x%08x\n",
- ioreqs[0].value, ioreqs[1].value);
return zd_iowrite32a(chip, ioreqs, ARRAY_SIZE(ioreqs));
}
diff --git a/drivers/net/wireless/zd1211rw/zd_ieee80211.h b/drivers/net/wireless/zd1211rw/zd_ieee80211.h
index c4f36d3..fbf6491 100644
--- a/drivers/net/wireless/zd1211rw/zd_ieee80211.h
+++ b/drivers/net/wireless/zd1211rw/zd_ieee80211.h
@@ -43,21 +43,25 @@ struct ofdm_plcp_header {
__le16 service;
} __attribute__((packed));
-static inline u8 zd_ofdm_plcp_header_rate(
- const struct ofdm_plcp_header *header)
+static inline u8 zd_ofdm_plcp_header_rate(const struct ofdm_plcp_header *header)
{
return header->prefix[0] & 0xf;
}
-/* These are referred to as zd_rates */
-#define ZD_OFDM_RATE_6M 0xb
-#define ZD_OFDM_RATE_9M 0xf
-#define ZD_OFDM_RATE_12M 0xa
-#define ZD_OFDM_RATE_18M 0xe
-#define ZD_OFDM_RATE_24M 0x9
-#define ZD_OFDM_RATE_36M 0xd
-#define ZD_OFDM_RATE_48M 0x8
-#define ZD_OFDM_RATE_54M 0xc
+/* The following defines give the encoding of the 4-bit rate field in the
+ * OFDM (802.11a/802.11g) PLCP header. Notify that these values are used to
+ * define the zd-rate values for OFDM.
+ *
+ * See the struct zd_ctrlset definition in zd_mac.h.
+ */
+#define ZD_OFDM_PLCP_RATE_6M 0xb
+#define ZD_OFDM_PLCP_RATE_9M 0xf
+#define ZD_OFDM_PLCP_RATE_12M 0xa
+#define ZD_OFDM_PLCP_RATE_18M 0xe
+#define ZD_OFDM_PLCP_RATE_24M 0x9
+#define ZD_OFDM_PLCP_RATE_36M 0xd
+#define ZD_OFDM_PLCP_RATE_48M 0x8
+#define ZD_OFDM_PLCP_RATE_54M 0xc
struct cck_plcp_header {
u8 signal;
@@ -66,15 +70,22 @@ struct cck_plcp_header {
__le16 crc16;
} __attribute__((packed));
-static inline u8 zd_cck_plcp_header_rate(const struct cck_plcp_header *header)
+static inline u8 zd_cck_plcp_header_signal(const struct cck_plcp_header *header)
{
return header->signal;
}
-#define ZD_CCK_SIGNAL_1M 0x0a
-#define ZD_CCK_SIGNAL_2M 0x14
-#define ZD_CCK_SIGNAL_5M5 0x37
-#define ZD_CCK_SIGNAL_11M 0x6e
+/* These defines give the encodings of the signal field in the 802.11b PLCP
+ * header. The signal field gives the bit rate of the following packet. Even
+ * if technically wrong we use CCK here also for the 1 MBit/s and 2 MBit/s
+ * rate to stay consistent with Zydas and our use of the term.
+ *
+ * Notify that these values are *not* used in the zd-rates.
+ */
+#define ZD_CCK_PLCP_SIGNAL_1M 0x0a
+#define ZD_CCK_PLCP_SIGNAL_2M 0x14
+#define ZD_CCK_PLCP_SIGNAL_5M5 0x37
+#define ZD_CCK_PLCP_SIGNAL_11M 0x6e
enum ieee80211_std {
IEEE80211B = 0x01,
diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c b/drivers/net/wireless/zd1211rw/zd_mac.c
index 26869d1..f9cd317 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -582,28 +582,6 @@ u8 zd_mac_get_channel(struct zd_mac *mac)
return channel;
}
-/* If wrong rate is given, we are falling back to the slowest rate: 1MBit/s */
-static u8 zd_rate_typed(u8 zd_rate)
-{
- static const u8 typed_rates[16] = {
- [ZD_CCK_RATE_1M] = ZD_CS_CCK|ZD_CCK_RATE_1M,
- [ZD_CCK_RATE_2M] = ZD_CS_CCK|ZD_CCK_RATE_2M,
- [ZD_CCK_RATE_5_5M] = ZD_CS_CCK|ZD_CCK_RATE_5_5M,
- [ZD_CCK_RATE_11M] = ZD_CS_CCK|ZD_CCK_RATE_11M,
- [ZD_OFDM_RATE_6M] = ZD_CS_OFDM|ZD_OFDM_RATE_6M,
- [ZD_OFDM_RATE_9M] = ZD_CS_OFDM|ZD_OFDM_RATE_9M,
- [ZD_OFDM_RATE_12M] = ZD_CS_OFDM|ZD_OFDM_RATE_12M,
- [ZD_OFDM_RATE_18M] = ZD_CS_OFDM|ZD_OFDM_RATE_18M,
- [ZD_OFDM_RATE_24M] = ZD_CS_OFDM|ZD_OFDM_RATE_24M,
- [ZD_OFDM_RATE_36M] = ZD_CS_OFDM|ZD_OFDM_RATE_36M,
- [ZD_OFDM_RATE_48M] = ZD_CS_OFDM|ZD_OFDM_RATE_48M,
- [ZD_OFDM_RATE_54M] = ZD_CS_OFDM|ZD_OFDM_RATE_54M,
- };
-
- ZD_ASSERT(ZD_CS_RATE_MASK == 0x0f);
- return typed_rates[zd_rate & ZD_CS_RATE_MASK];
-}
-
int zd_mac_set_mode(struct zd_mac *mac, u32 mode)
{
struct ieee80211_device *ieee;
@@ -707,25 +685,30 @@ int zd_mac_get_range(struct zd_mac *mac, struct iw_range *range)
static int zd_calc_tx_length_us(u8 *service, u8 zd_rate, u16 tx_length)
{
+ /* ZD_PURE_RATE() must be used to remove the modulation type flag of
+ * the zd-rate values. */
static const u8 rate_divisor[] = {
- [ZD_CCK_RATE_1M] = 1,
- [ZD_CCK_RATE_2M] = 2,
- [ZD_CCK_RATE_5_5M] = 11, /* bits must be doubled */
- [ZD_CCK_RATE_11M] = 11,
- [ZD_OFDM_RATE_6M] = 6,
- [ZD_OFDM_RATE_9M] = 9,
- [ZD_OFDM_RATE_12M] = 12,
- [ZD_OFDM_RATE_18M] = 18,
- [ZD_OFDM_RATE_24M] = 24,
- [ZD_OFDM_RATE_36M] = 36,
- [ZD_OFDM_RATE_48M] = 48,
- [ZD_OFDM_RATE_54M] = 54,
+ [ZD_PURE_RATE(ZD_CCK_RATE_1M)] = 1,
+ [ZD_PURE_RATE(ZD_CCK_RATE_2M)] = 2,
+
+ /* bits must be doubled */
+ [ZD_PURE_RATE(ZD_CCK_RATE_5_5M)] = 11,
+
+ [ZD_PURE_RATE(ZD_CCK_RATE_11M)] = 11,
+ [ZD_PURE_RATE(ZD_OFDM_RATE_6M)] = 6,
+ [ZD_PURE_RATE(ZD_OFDM_RATE_9M)] = 9,
+ [ZD_PURE_RATE(ZD_OFDM_RATE_12M)] = 12,
+ [ZD_PURE_RATE(ZD_OFDM_RATE_18M)] = 18,
+ [ZD_PURE_RATE(ZD_OFDM_RATE_24M)] = 24,
+ [ZD_PURE_RATE(ZD_OFDM_RATE_36M)] = 36,
+ [ZD_PURE_RATE(ZD_OFDM_RATE_48M)] = 48,
+ [ZD_PURE_RATE(ZD_OFDM_RATE_54M)] = 54,
};
u32 bits = (u32)tx_length * 8;
u32 divisor;
- divisor = rate_divisor[zd_rate];
+ divisor = rate_divisor[ZD_PURE_RATE(zd_rate)];
if (divisor == 0)
return -EINVAL;
@@ -748,52 +731,24 @@ static int zd_calc_tx_length_us(u8 *service, u8 zd_rate, u16 tx_length)
return bits/divisor;
}
-enum {
- R2M_SHORT_PREAMBLE = 0x01,
- R2M_11A = 0x02,
-};
-
-static u8 zd_rate_to_modulation(u8 zd_rate, int flags)
-{
- u8 modulation;
-
- modulation = zd_rate_typed(zd_rate);
- if (flags & R2M_SHORT_PREAMBLE) {
- switch (ZD_CS_RATE(modulation)) {
- case ZD_CCK_RATE_2M:
- case ZD_CCK_RATE_5_5M:
- case ZD_CCK_RATE_11M:
- modulation |= ZD_CS_CCK_PREA_SHORT;
- return modulation;
- }
- }
- if (flags & R2M_11A) {
- if (ZD_CS_TYPE(modulation) == ZD_CS_OFDM)
- modulation |= ZD_CS_OFDM_MODE_11A;
- }
- return modulation;
-}
-
static void cs_set_modulation(struct zd_mac *mac, struct zd_ctrlset *cs,
struct ieee80211_hdr_4addr *hdr)
{
struct ieee80211softmac_device *softmac = ieee80211_priv(mac->netdev);
u16 ftype = WLAN_FC_GET_TYPE(le16_to_cpu(hdr->frame_ctl));
- u8 rate, zd_rate;
+ u8 rate;
int is_mgt = (ftype == IEEE80211_FTYPE_MGMT) != 0;
int is_multicast = is_multicast_ether_addr(hdr->addr1);
int short_preamble = ieee80211softmac_short_preamble_ok(softmac,
is_multicast, is_mgt);
- int flags = 0;
- /* FIXME: 802.11a? */
rate = ieee80211softmac_suggest_txrate(softmac, is_multicast, is_mgt);
+ cs->modulation = rate_to_zd_rate(rate);
- if (short_preamble)
- flags |= R2M_SHORT_PREAMBLE;
-
- zd_rate = rate_to_zd_rate(rate);
- cs->modulation = zd_rate_to_modulation(zd_rate, flags);
+ /* Set short preamble bit when appropriate */
+ if (short_preamble && ZD_MODULATION_TYPE(cs->modulation) == ZD_CCK
+ && cs->modulation != ZD_CCK_RATE_1M)
+ cs->modulation |= ZD_CCK_PREA_SHORT;
}
static void cs_set_control(struct zd_mac *mac, struct zd_ctrlset *cs,
@@ -832,7 +787,7 @@ static void cs_set_control(struct zd_mac *mac, struct zd_ctrlset *cs,
cs->control |= ZD_CS_RTS;
/* Use CTS-to-self protection if required */
- if (ZD_CS_TYPE(cs->modulation) == ZD_CS_OFDM &&
+ if (ZD_MODULATION_TYPE(cs->modulation) == ZD_OFDM &&
ieee80211softmac_protection_needed(softmac)) {
/* FIXME: avoid sending RTS *and* self-CTS, is that correct? */
cs->control &= ~ZD_CS_RTS;
@@ -893,7 +848,7 @@ static int fill_ctrlset(struct zd_mac *mac,
* - see line 53 of zdinlinef.h
*/
cs->service = 0;
- r = zd_calc_tx_length_us(&cs->service, ZD_CS_RATE(cs->modulation),
+ r = zd_calc_tx_length_us(&cs->service, ZD_RATE(cs->modulation),
le16_to_cpu(cs->tx_length));
if (r < 0)
return r;
@@ -902,7 +857,7 @@ static int fill_ctrlset(struct zd_mac *mac,
if (next_frag_len == 0) {
cs->next_frame_length = 0;
} else {
- r = zd_calc_tx_length_us(NULL, ZD_CS_RATE(cs->modulation),
+ r = zd_calc_tx_length_us(NULL, ZD_RATE(cs->modulation),
next_frag_len);
if (r < 0)
return r;
diff --git a/drivers/net/wireless/zd1211rw/zd_mac.h b/drivers/net/wireless/zd1211rw/zd_mac.h
index 9f9344e..1b15bde 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.h
+++ b/drivers/net/wireless/zd1211rw/zd_mac.h
@@ -40,28 +40,51 @@ struct zd_ctrlset {
#define ZD_CS_RESERVED_SIZE 25
-/* zd_crtlset field modulation */
-#define ZD_CS_RATE_MASK 0x0f
-#define ZD_CS_TYPE_MASK 0x10
-#define ZD_CS_RATE(modulation) ((modulation) & ZD_CS_RATE_MASK)
-#define ZD_CS_TYPE(modulation) ((modulation) & ZD_CS_TYPE_MASK)
-
-#define ZD_CS_CCK 0x00
-#define ZD_CS_OFDM 0x10
-
-/* These are referred to as zd_rates */
-#define ZD_CCK_RATE_1M 0x00
-#define ZD_CCK_RATE_2M 0x01
-#define ZD_CCK_RATE_5_5M 0x02
-#define ZD_CCK_RATE_11M 0x03
-/* The rates for OFDM are encoded as in the PLCP header. Use ZD_OFDM_RATE_*.
+/* The field modulation of struct zd_ctrlset controls the bit rate, the use
+ * of short or long preambles in 802.11b (CCK mode) or the use of 802.11a or
+ * 802.11g in OFDM mode.
+ *
+ * The term zd-rate is used for the combination of the modulation type flag
+ * and the "pure" rate value.
*/
-
-/* bit 5 is preamble (when in CCK mode), or a/g selection (when in OFDM mode) */
-#define ZD_CS_CCK_PREA_LONG 0x00
-#define ZD_CS_CCK_PREA_SHORT 0x20
-#define ZD_CS_OFDM_MODE_11G 0x00
-#define ZD_CS_OFDM_MODE_11A 0x20
+#define ZD_PURE_RATE_MASK 0x0f
+#define ZD_MODULATION_TYPE_MASK 0x10
+#define ZD_RATE_MASK (ZD_PURE_RATE_MASK|ZD_MODULATION_TYPE_MASK)
+#define ZD_PURE_RATE(modulation) ((modulation) & ZD_PURE_RATE_MASK)
+#define ZD_MODULATION_TYPE(modulation) ((modulation) & ZD_MODULATION_TYPE_MASK)
+#define ZD_RATE(modulation) ((modulation) & ZD_RATE_MASK)
+
+/* The two possible modulation types. Notify that 802.11b doesn't use the CCK
+ * codeing for the 1 and 2 MBit/s rate. We stay with the term here to remain
+ * consistent with uses the term at other places.
+ */
+#define ZD_CCK 0x00
+#define ZD_OFDM 0x10
+
+/* The ZD1211 firmware uses proprietary encodings of the 802.11b (CCK) rates.
+ * For OFDM the PLCP rate encodings are used. We combine these "pure" rates
+ * with the modulation type flag and call the resulting values zd-rates.
+ */
+#define ZD_CCK_RATE_1M (ZD_CCK|0x00)
+#define ZD_CCK_RATE_2M (ZD_CCK|0x01)
+#define ZD_CCK_RATE_5_5M (ZD_CCK|0x02)
+#define ZD_CCK_RATE_11M (ZD_CCK|0x03)
+#define ZD_OFDM_RATE_6M (ZD_OFDM|ZD_OFDM_PLCP_RATE_6M)
+#define ZD_OFDM_RATE_9M (ZD_OFDM|ZD_OFDM_PLCP_RATE_9M)
+#define ZD_OFDM_RATE_12M (ZD_OFDM|ZD_OFDM_PLCP_RATE_12M)
+#define ZD_OFDM_RATE_18M (ZD_OFDM|ZD_OFDM_PLCP_RATE_18M)
+#define ZD_OFDM_RATE_24M (ZD_OFDM|ZD_OFDM_PLCP_RATE_24M)
+#define ZD_OFDM_RATE_36M (ZD_OFDM|ZD_OFDM_PLCP_RATE_36M)
+#define ZD_OFDM_RATE_48M (ZD_OFDM|ZD_OFDM_PLCP_RATE_48M)
+#define ZD_OFDM_RATE_54M (ZD_OFDM|ZD_OFDM_PLCP_RATE_54M)
+
+/* The bit 5 of the zd_ctrlset modulation field controls the preamble in CCK
+ * mode or the 802.11a/802.11g selection in OFDM mode.
+ */
+#define ZD_CCK_PREA_LONG 0x00
+#define ZD_CCK_PREA_SHORT 0x20
+#define ZD_OFDM_MODE_11G 0x00
+#define ZD_OFDM_MODE_11A 0x20
/* zd_ctrlset control field */
#define ZD_CS_NEED_RANDOM_BACKOFF 0x01
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c b/drivers/net/wireless/zd1211rw/zd_usb.c
index a9c339e..e49628b 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -74,6 +74,8 @@ static struct usb_device_id usb_ids[] = {
{ USB_DEVICE(0x0411, 0x00da), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x2019, 0x5303), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x129b, 0x1667), .driver_info = DEVICE_ZD1211B },
+ { USB_DEVICE(0x0cde, 0x001a), .driver_info = DEVICE_ZD1211B },
+ { USB_DEVICE(0x0586, 0x340a), .driver_info = DEVICE_ZD1211B },
/* "Driverless" devices that need ejecting */
{ USB_DEVICE(0x0ace, 0x2011), .driver_info = DEVICE_INSTALLER },
{ USB_DEVICE(0x0ace, 0x20ff), .driver_info = DEVICE_INSTALLER },
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply related
* Re: [PATCH] IOAT: Fix ioatdma descriptor cache miss
From: David Miller @ 2007-08-15 0:37 UTC (permalink / raw)
To: shannon.nelson; +Cc: netdev, jgarzik
In-Reply-To: <BAE9DCEF64577A439B3A37F36F9B691C02DBB8B7@orsmsx418.amr.corp.intel.com>
From: "Nelson, Shannon" <shannon.nelson@intel.com>
Date: Tue, 14 Aug 2007 14:20:02 -0700
> The layout for struct ioat_desc_sw is non-optimal and causes an extra
> cache hit for every descriptor processed. By tightening up the struct
> layout and removing one item, we pull in the fields that get used in
> the speedpath and get a little better performance.
...
> Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Patch applied, thanks.
> @@ -347,8 +347,7 @@ ioat_dma_prep_memcpy(struct dma_chan *chan, size_t
> len, int int_en)
Your email client is wrapping long lines in patches, corrupting
them.
I fixed it up this time, but please take care of this in the
future.
^ permalink raw reply
* Re: [2.6 patch] unexport dev_ethtool
From: David Miller @ 2007-08-15 0:39 UTC (permalink / raw)
To: matthew; +Cc: bunk, netdev
In-Reply-To: <20070814212325.GW16277@parisc-linux.org>
From: Matthew Wilcox <matthew@wil.cx>
Date: Tue, 14 Aug 2007 15:23:26 -0600
> On Tue, Aug 14, 2007 at 11:22:03PM +0200, Adrian Bunk wrote:
> > This patch removes the no longer used EXPORT_SYMBOL(dev_ethtool).
> >
> > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> Acked-by: Matthew Wilcox <matthew@wil.cx>
Applied, thanks.
^ permalink raw reply
* Re: [2.6 patch] net/8021q/vlanproc.c: fix check-after-use
From: David Miller @ 2007-08-15 0:39 UTC (permalink / raw)
To: bunk; +Cc: netdev, linux-kernel
In-Reply-To: <20070814212244.GB18945@stusta.de>
From: Adrian Bunk <bunk@kernel.org>
Date: Tue, 14 Aug 2007 23:22:44 +0200
> The Coverity checker spotted that we'd have already oops'ed if "vlandev"
> was NULL.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Fair enough, applied, thanks Adrian.
^ permalink raw reply
* Re: [RFC: -mm patch] improve the SSB dependencies
From: John W. Linville @ 2007-08-15 0:40 UTC (permalink / raw)
To: Adrian Bunk
Cc: Michael Buesch, Johannes Berg, Andrew Morton, Linux Netdev List
In-Reply-To: <20070812224401.GA18945@stusta.de>
On Mon, Aug 13, 2007 at 12:44:02AM +0200, Adrian Bunk wrote:
> On Sun, Aug 12, 2007 at 02:00:26PM +0200, Michael Buesch wrote:
> > Ok, I'll give it a try, with small modifications.
>
> Thanks.
>
> > On Sunday 12 August 2007, Adrian Bunk wrote:
> > > Additional changes in this patch:
> > > - small help text changes
> > > - B44_PCI is no longer usr visible (automatically enabled when possible)
> >
> > I think we want that to be selectable, as it's not needed
> > on some embedded devices. And we need to save memory there.
> >...
>
> Makes sense, but then:
>
> config B44_PCI
> bool "Broadcom 440x PCI device support" if EMBEDDED
> ...
> default y
> ...
>
> I don't care about how many options we present if CONFIG_EMBEDDED=y, but
> for the normal CONFIG_EMBEDDED=n case we should not bother the user with
> this option.
Was all this resolved? Was there another patch? If so, I missed it...
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: Please pull 'fixes-davem' branch of wireless-2.6
From: David Miller @ 2007-08-15 1:33 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20070815003234.GI7198-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Tue, 14 Aug 2007 20:32:34 -0400
> These are a few more items intended for 2.6.23.
...
> The following changes since commit 39d3520c92cf7a28c07229ca00cc35a1e8026c77:
> Linus Torvalds (1):
> Linux 2.6.23-rc3
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-davem
>
> Johannes Berg (1):
> mac80211: fix tx status frame code
>
> John W. Linville (1):
> mac80211: probe for hidden SSIDs in pre-auth scan
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH 1/1] bonding: eliminate RTNL assertion spew
From: Mike Snitzer @ 2007-08-15 3:14 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Stephen Hemminger, Jeff Garzik, fubar, netdev
In-Reply-To: <20070110193355.GA13249@gospo.rdu.redhat.com>
Andy,
Is there an updated version of this patch?
Please advise, thanks.
On 1/10/07, Andy Gospodarek <andy@greyhouse.net> wrote:
> On Tue, Jan 09, 2007 at 03:09:35PM -0800, Stephen Hemminger wrote:
> > On Tue, 9 Jan 2007 17:59:01 -0500
> > Andy Gospodarek <andy@greyhouse.net> wrote:
> >
> > >
> > > These changes eliminate the messages indicating that the rtnetlink lock
> > > isn't held when bonding tries to change the MAC address of an interface.
> > > These calls generally come from timer-pops, but also from sysfs events
> > > since neither hold the rtnl lock.
> > >
> > > The spew generally looks something like this:
> > >
> > > RTNL: assertion failed at net/core/fib_rules.c (391)
> > > [<c028d12e>] fib_rules_event+0x3a/0xeb
> > > [<c02da576>] notifier_call_chain+0x19/0x29
> > > [<c0280ce6>] dev_set_mac_address+0x46/0x4b
> > > [<f8a2a686>] alb_set_slave_mac_addr+0x5d/0x88 [bonding]
> > > [<f8a2aa7e>] alb_swap_mac_addr+0x88/0x134 [bonding]
> > > [<f8a25ed9>] bond_change_active_slave+0x1a1/0x2c5 [bonding]
> > > [<f8a262e8>] bond_select_active_slave+0xa8/0xe1 [bonding]
> > > [<f8a27ecb>] bond_mii_monitor+0x3af/0x3fd [bonding]
> > > [<c0121896>] run_workqueue+0x85/0xc5
> > > [<f8a27b1c>] bond_mii_monitor+0x0/0x3fd [bonding]
> > > [<c0121d83>] worker_thread+0xe8/0x119
> > > [<c0111179>] default_wake_function+0x0/0xc
> > > [<c0121c9b>] worker_thread+0x0/0x119
> > > [<c0124099>] kthread+0xad/0xd8
> > > [<c0123fec>] kthread+0x0/0xd8
> > > .....
> > >
> > > This patch was mostly inspired from parts of some potential bonding
> > > updates Jay Vosburgh <fubar@us.ibm.com> and I discussed in December, so
> > > he deserves most of the credit for the idea.
> > >
> > > I've tested it on several systems and it works as I expect. Deadlocks
> > > between the rtnl and global bond lock are avoided since we drop the
> > > global bond lock before taking the rtnl lock.
> > >
> >
> >
> > This seems like the ugly way to do it. Couldn't you just change figure out
> > how to acquire RTNL first. It wouldn't hurt to acquire it in the monitor
> > routine even if you don't need it.
> >
> > Conditional locking is a bad road to start down.
>
>
> Stephen and Jeff,
>
> Does this seem like a better alternative? Taking the rtnetlink lock
> before the global bond luck should avoid deadlocks since it is done that
> way throughout the bonding code. I didn't notice any immediate problems,
> but it was by no means and exhaustive stress test.
>
> Thanks,
>
> -andy
>
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> ---
>
> bond_main.c | 15 +++++++++++++++
> bond_sysfs.c | 6 ++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 6482aed..e324235 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -2024,6 +2024,9 @@ void bond_mii_monitor(struct net_device
> int delta_in_ticks;
> int i;
>
> + /* grab rtnl lock before taking bond lock*/
> + rtnl_lock();
> +
> read_lock(&bond->lock);
>
> delta_in_ticks = (bond->params.miimon * HZ) / 1000;
> @@ -2252,6 +2255,8 @@ re_arm:
> }
> out:
> read_unlock(&bond->lock);
> +
> + rtnl_unlock();
> }
>
>
> @@ -2557,6 +2562,9 @@ void bond_loadbalance_arp_mon(struct net
> int delta_in_ticks;
> int i;
>
> + /* grab rtnl lock before taking bond lock*/
> + rtnl_lock();
> +
> read_lock(&bond->lock);
>
> delta_in_ticks = (bond->params.arp_interval * HZ) / 1000;
> @@ -2663,6 +2671,8 @@ re_arm:
> }
> out:
> read_unlock(&bond->lock);
> +
> + rtnl_unlock();
> }
>
> /*
> @@ -2687,6 +2697,9 @@ void bond_activebackup_arp_mon(struct ne
> int delta_in_ticks;
> int i;
>
> + /* grab rtnl lock before taking bond lock*/
> + rtnl_lock();
> +
> read_lock(&bond->lock);
>
> delta_in_ticks = (bond->params.arp_interval * HZ) / 1000;
> @@ -2911,6 +2924,8 @@ re_arm:
> }
> out:
> read_unlock(&bond->lock);
> +
> + rtnl_unlock();
> }
>
> /*------------------------------ proc/seq_file-------------------------------*/
> diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
> index ced9ed8..d23057a 100644
> --- a/drivers/net/bonding/bond_sysfs.c
> +++ b/drivers/net/bonding/bond_sysfs.c
> @@ -1028,6 +1028,8 @@ static ssize_t bonding_store_primary(str
> struct slave *slave;
> struct bonding *bond = to_bond(cd);
>
> + /* grab rtnl lock before taking bond lock*/
> + rtnl_lock();
> write_lock_bh(&bond->lock);
> if (!USES_PRIMARY(bond->params.mode)) {
> printk(KERN_INFO DRV_NAME
> @@ -1063,6 +1065,7 @@ static ssize_t bonding_store_primary(str
> }
> out:
> write_unlock_bh(&bond->lock);
> + rtnl_unlock();
> return count;
> }
> static CLASS_DEVICE_ATTR(primary, S_IRUGO | S_IWUSR, bonding_show_primary, bonding_store_primary);
> @@ -1134,6 +1137,8 @@ static ssize_t bonding_store_active_slav
> struct slave *new_active = NULL;
> struct bonding *bond = to_bond(cd);
>
> + /* grab rtnl lock before taking bond lock*/
> + rtnl_lock();
> write_lock_bh(&bond->lock);
> if (!USES_PRIMARY(bond->params.mode)) {
> printk(KERN_INFO DRV_NAME
> @@ -1191,6 +1196,7 @@ static ssize_t bonding_store_active_slav
> }
> out:
> write_unlock_bh(&bond->lock);
> + rtnl_unlock();
> return count;
>
> }
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 1/1] bonding: eliminate RTNL assertion spew
From: Andy Gospodarek @ 2007-08-15 3:27 UTC (permalink / raw)
To: Mike Snitzer; +Cc: Stephen Hemminger, Jeff Garzik, fubar, netdev
In-Reply-To: <170fa0d20708142014l217b8804g66426a84547ba91d@mail.gmail.com>
On 8/14/07, Mike Snitzer <snitzer@gmail.com> wrote:
> Andy,
>
> Is there an updated version of this patch?
>
> Please advise, thanks.
>
>
Mike,
There is a version that Jay and I have been testing and if you would
like to help out, we could probably send you some patches.
Jay has split the entire patch into smaller chunks, and we hope to
post the entire thing quite soon (days not months).
-andy
^ permalink raw reply
* Re: Realtek r8168 slow outbound transfer - potential fix/workaround
From: Bruce Cole @ 2007-08-15 5:46 UTC (permalink / raw)
To: gundy; +Cc: netdev, bacole
In-Reply-To: <25536.1187071305@iinet.net.au>
gundy@iinet.net.au wrote:
> Bruce,
>
> I settled on using ndelay(10) rather than udelay(25) in the end..
> it's probably a bit safer & less likely to cause problems with higher
> throughputs.
Yes, I saw that you later recommended the change but opted to try it the
way you tested first.
>
> When I was diagnosing the problem I used 2 machines. One machine was
> running Samba on linux (the 'problem' machine), and one was a windows
> XP machine.
Likewise, tho I also tested vista.
>
> I used tcpdump to capture the traffic on the Samba machine, and used
> wireshark to capture the traffic on the windows machine. What i found
> was happening was that samba was attempting to send two packets to the
> windows machine in quick succession (ie. something in the order of a
> 1/10,000th or less of a second apart). Although both packets showed
> up in the tcpdump output from the linux machine, only the first packet
> appeared to be making it to the windows machine. Because the second
> packet was 'lost', it had to be retried after a delay and this is what
> was causing the abysmal performance.
>
> The reasoning behind my patch was that I figured the TxPoll register
> wasn't being given enough time to reset itself after sending the
> previous packet. I may or may not have been correct with that
> assumption, but as you noticed the delay does seem to make it behave a
> bit better.
Disclaimer: I haven't seen the definition for that register so I'm just
guessing here.
I suppose the danger is that your fix may just be changing the timing
around such that the time-dependent bug does not occur as readily, yet a
bug remains. Does anyone have the programming spec for this chip from
realtek, or are we all just forced to guess :)?
>
> I understand that Francios came up with a similar patch that he said
> also worked, and that he thought was a bit more robust than my
> method. I'd check with him on what the status of that particular
> patch is.
Thanks, I don't see that patch in 2.6.23-rc3 but I'll try Francios'
recommendations first and if that doesn't work I'll test out things with
the shorter ndelay().
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Herbert Xu @ 2007-08-15 6:49 UTC (permalink / raw)
To: Chris Snook
Cc: satyam, clameter, linux-kernel, linux-arch, torvalds, netdev,
akpm, ak, heiko.carstens, davem, schwidefsky, wensong, horms,
wjiang, cfriesen, zlynx, rpjday, jesper.juhl, segher
In-Reply-To: <46C2350A.1010807@redhat.com>
Chris Snook <csnook@redhat.com> wrote:
>
> Because atomic operations are generally used for synchronization, which requires
> volatile behavior. Most such codepaths currently use an inefficient barrier().
> Some forget to and we get bugs, because people assume that atomic_read()
> actually reads something, and atomic_write() actually writes something. Worse,
> these are architecture-specific, even compiler version-specific bugs that are
> often difficult to track down.
I'm yet to see a single example from the current tree where
this patch series is the correct solution. So far the only
example has been a buggy piece of code which has since been
fixed with a cpu_relax.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Realtek r8168 slow outbound transfer - potential fix/workaround
From: Bruce Cole @ 2007-08-15 7:17 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, David Gundersen
In-Reply-To: <20070814211954.GA3552@electric-eye.fr.zoreil.com>
Francois Romieu wrote:
> Bruce Cole <bacole@gmail.com> :
> [...]
>
>> What's the status of this fix? It (or something more refined) seems
>> necessary to correct the current performance problems with this driver.
>>
>
> An explanation or something more refined would be welcome.
>
>
Are you indicating that you need more information on how to reproduce
the problem? I believe the problem is 100% reproducible if you
configure a samba server with a realtek r8111 interface and drag&drop a
file from that server to a windows host on the directly connected lan.
This with both machine's host interfaces reporting 1000mbps full duplex
and a gig-e hub between.
I've just reproduced using a linux client as well, so it would be easy
to compare tcpdumps of the TCP sessions from both ends. Note the
abysmal performance when I transfer *from* the server, but the
performance is fine when I transfer *to* the server:
zpad(root): mount -t cifs -o username=cole //192.168.1.11/u4 /mnt1
Password:
zpad(root): cd /mnt1/test
zpad(root): ls -l t
-rw-r--r-- 1 cole cole 52428800 2007-08-14 23:52 t
zpad(root): date; cp -pr t ~/test/; date
Tue Aug 14 11:57:35 PM
Wed Aug 15 12:01:11 AM
zpad(root): ls -l ~/test/t
-rw-r--r-- 1 cole cole 50M 2007-08-14 23:52 /home/cole/test/t
zpad(root): date; cp -pr ~/test/t tt; date
Wed Aug 15 12:02:11 AM
cp: setting permissions for `tt': Permission denied
Wed Aug 15 12:02:13 AM
zpad(root): ls -l tt
-rwx------ 1 cole cole 52428800 2007-08-14 23:52 tt*
zpad(root):
This test is with the vanilla 2.6.23-rc3 driver with NAPI enabled.
If you're hoping to receive a better fix than the spin wait, I could
probably help with that too but I'd need to see realtek's programming
documentation for this chip.
> [...]
>
>> I can troubleshoot in more detail if that would help get a proper fix
>> developed.
>>
>
> Can you try 2.6.23-rc3 with NAPI enabled and send a complete dmesg +
> /proc/interrupts + ethtool -S output ?
>
Sure, see below:
dmesg:
Linux version 2.6.23-0.104.rc3.fc8
(kojibuilder@xenbuilder2.fedora.redhat.com) (gcc version 4.1.2 20070723
(Red Hat 4.1.2-17)) #1 SMP Mon Aug 13 15:58:43 EDT 2007
Command line: ro root=/dev/sda6 rhgb quiet
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009e800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000007fee0000 (usable)
BIOS-e820: 000000007fee0000 - 000000007fee3000 (ACPI NVS)
BIOS-e820: 000000007fee3000 - 000000007fef0000 (ACPI data)
BIOS-e820: 000000007fef0000 - 000000007ff00000 (reserved)
BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
Entering add_active_range(0, 0, 158) 0 entries of 3200 used
Entering add_active_range(0, 256, 524000) 1 entries of 3200 used
end_pfn_map = 1048576
DMI 2.4 present.
ACPI: RSDP 000F6FE0, 0014 (r0 GBT )
ACPI: RSDT 7FEE3040, 003C (r1 GBT GBTUACPI 42302E31 GBTU 1010101)
ACPI: FACP 7FEE30C0, 0074 (r1 GBT GBTUACPI 42302E31 GBTU 1010101)
ACPI: DSDT 7FEE3180, 4B36 (r1 GBT GBTUACPI 1000 MSFT 100000C)
ACPI: FACS 7FEE0000, 0040
ACPI: HPET 7FEE7E00, 0038 (r1 GBT GBTUACPI 42302E31 GBTU 98)
ACPI: MCFG 7FEE7E80, 003C (r1 GBT GBTUACPI 42302E31 GBTU 1010101)
ACPI: APIC 7FEE7D00, 0084 (r1 GBT GBTUACPI 42302E31 GBTU 1010101)
ACPI: SSDT 7FEE7F00, 015C (r1 PmRef Cpu0Ist 3000 INTL 20040311)
ACPI: SSDT 7FEE8390, 0275 (r1 PmRef CpuPm 3000 INTL 20040311)
No NUMA configuration found
Faking a node at 0000000000000000-000000007fee0000
Entering add_active_range(0, 0, 158) 0 entries of 3200 used
Entering add_active_range(0, 256, 524000) 1 entries of 3200 used
Bootmem setup node 0 0000000000000000-000000007fee0000
Zone PFN ranges:
DMA 0 -> 4096
DMA32 4096 -> 1048576
Normal 1048576 -> 1048576
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0 -> 158
0: 256 -> 524000
On node 0 totalpages: 523902
DMA zone: 96 pages used for memmap
DMA zone: 2488 pages reserved
DMA zone: 1414 pages, LIFO batch:0
DMA32 zone: 12185 pages used for memmap
DMA32 zone: 507719 pages, LIFO batch:31
Normal zone: 0 pages used for memmap
Movable zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23
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 flat
ACPI: HPET id: 0x8086a201 base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 000000000009e000 - 00000000000a0000
swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000f0000
swsusp: Registered nosave memory region: 00000000000f0000 - 0000000000100000
Allocating PCI resources starting at 80000000 (gap: 7ff00000:70100000)
SMP: Allowing 4 CPUs, 2 hotplug CPUs
PERCPU: Allocating 435848 bytes of per cpu data
Built 1 zonelists in Node order. Total pages: 509133
Policy zone: DMA32
Kernel command line: ro root=/dev/sda6 rhgb quiet
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
hpet clockevent registered
TSC calibrated against HPET
time.c: Detected 2800.002 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 30
... MAX_LOCKDEP_KEYS: 2048
... CLASSHASH_SIZE: 1024
... MAX_LOCKDEP_ENTRIES: 8192
... MAX_LOCKDEP_CHAINS: 16384
... CHAINHASH_SIZE: 8192
memory used by lock dependency info: 1712 kB
per task-struct memory footprint: 2160 bytes
Checking aperture...
Calgary: detecting Calgary via BIOS EBDA area
Calgary: Unable to locate Rio Grande table in EBDA - bailing!
Memory: 2031412k/2096000k available (2473k kernel code, 64196k reserved,
1434k data, 708k init)
SLUB: Genslabs=23, HWalign=64, Order=0-1, MinObjects=4, CPUs=4, Nodes=1
Calibrating delay using timer specific routine.. 5604.00 BogoMIPS
(lpj=2802000)
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
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Mount-cache hash table entries: 256
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
CPU 0/0 -> Node 0
using mwait in idle threads.
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU0: Thermal monitoring enabled (TM2)
lockdep: not fixing up alternatives.
ACPI: Core revision 20070126
Using local APIC timer interrupts.
APIC timer calibration result 21874999
Detected 21.874 MHz APIC timer.
lockdep: not fixing up alternatives.
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 5599.77 BogoMIPS
(lpj=2799888)
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
CPU 1/1 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
CPU1: Thermal monitoring enabled (TM2)
Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz stepping 0b
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
Brought up 2 CPUs
sizeof(vma)=176 bytes
sizeof(page)=96 bytes
sizeof(inode)=1088 bytes
sizeof(dentry)=256 bytes
sizeof(ext3inode)=1488 bytes
sizeof(buffer_head)=104 bytes
sizeof(skbuff)=232 bytes
sizeof(task_struct)=4464 bytes
khelper used greatest stack depth: 6600 bytes left
khelper used greatest stack depth: 6352 bytes left
Time: 23:09:36 Date: 07/14/107
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using MMCONFIG at f0000000 - f3ffffff
mtrr: your CPUs had inconsistent variable MTRR settings
mtrr: probably your BIOS does not setup all CPUs.
mtrr: corrected configuration.
ACPI: EC: Look up EC in DSDT
ACPI: Interpreter enabled
ACPI: (supports S0 S3)
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX5._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 14 *15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 *14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0,
disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 *7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 6 7 9 10 11 *12 14 15)
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 13 devices
ACPI: ACPI bus type pnp unregistered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a
report
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
PCI-GART: No AMD northbridge found.
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
hpet0: 4 64-bit timers, 14318180 Hz
ACPI: RTC can wake from S4
Time: tsc clocksource has been installed.
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
pnp: 00:09: ioport range 0x400-0x4bf has been reserved
pnp: 00:0a: iomem range 0xf0000000-0xf3ffffff could not be reserved
pnp: 00:0b: iomem range 0xd5000-0xd7fff has been reserved
pnp: 00:0b: iomem range 0xf0000-0xf7fff could not be reserved
pnp: 00:0b: iomem range 0xf8000-0xfbfff could not be reserved
pnp: 00:0b: iomem range 0xfc000-0xfffff could not be reserved
PCI: Bridge: 0000:00:01.0
IO window: b000-bfff
MEM window: f4000000-f6ffffff
PREFETCH window: e0000000-efffffff
PCI: Bridge: 0000:00:1c.0
IO window: a000-afff
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.4
IO window: c000-cfff
MEM window: f9000000-f90fffff
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.5
IO window: d000-dfff
MEM window: f7000000-f8ffffff
PREFETCH window: 80000000-800fffff
PCI: Bridge: 0000:00:1e.0
IO window: disabled.
MEM window: f9100000-f91fffff
PREFETCH window: disabled.
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:01.0 to 64
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.0 to 64
ACPI: PCI Interrupt 0000:00:1c.4[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.4 to 64
ACPI: PCI Interrupt 0000:00:1c.5[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.5 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 7, 524288 bytes)
TCP established hash table entries: 262144 (order: 12, 18874368 bytes)
TCP bind hash table entries: 65536 (order: 10, 4194304 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
checking if image is initramfs... it is
Freeing initrd memory: 3102k freed
khelper used greatest stack depth: 6280 bytes left
audit: initializing netlink socket (disabled)
audit(1187132976.577: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
ksign: Installing public key data
Loading keyring
- Added public key 4C876821E00CB140
- 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)
Boot video device is 0000:01:00.0
PCI: Setting latency timer of device 0000:00:01.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:01.0:pcie00]
Allocate Port Service[0000:00:01.0:pcie03]
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.0:pcie00]
Allocate Port Service[0000:00:1c.0:pcie02]
Allocate Port Service[0000:00:1c.0:pcie03]
PCI: Setting latency timer of device 0000:00:1c.4 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.4:pcie00]
Allocate Port Service[0000:00:1c.4:pcie02]
Allocate Port Service[0000:00:1c.4:pcie03]
PCI: Setting latency timer of device 0000:00:1c.5 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.5:pcie00]
Allocate Port Service[0000:00:1c.5:pcie02]
Allocate Port Service[0000:00:1c.5:pcie03]
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI: Processor [CPU0] (supports 2 throttling states)
ACPI: SSDT 7FEE8300, 0087 (r1 PmRef Cpu1Ist 3000 INTL 20040311)
ACPI: Processor [CPU1] (supports 2 throttling states)
ACPI Exception (processor_core-0791): AE_NOT_FOUND, Processor Device is
not present [20070126]
ACPI Exception (processor_core-0791): AE_NOT_FOUND, Processor Device is
not present [20070126]
cpuidle: driver acpi_idle failed to attach to cpu 1
cpuidle: driver acpi_idle failed to attach to cpu 0
Generic RTC Driver v1.07
Non-volatile memory driver v1.2
Linux agpgart interface v0.102
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
input: Macintosh mouse button emulation as /class/input/input0
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 appears to have AUX port disabled, if this is incorrect please
boot with i8042.nopnp
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input1
cpuidle: using governor menu
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Magic number: 3:122:201
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Freeing unused kernel memory: 708k freed
Write protecting the kernel read-only data: 1032k
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1a.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1a.0 to 64
uhci_hcd 0000:00:1a.0: UHCI Host Controller
uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000e100
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1a.1[B] -> GSI 21 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:1a.1 to 64
uhci_hcd 0000:00:1a.1: UHCI Host Controller
uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000e200
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1a.2[C] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1a.2 to 64
uhci_hcd 0000:00:1a.2: UHCI Host Controller
uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1a.2: irq 18, io base 0x0000e000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000e300
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb 1-1: new full speed USB device using uhci_hcd and address 2
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000e400
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 6
uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000e500
usb usb6: configuration #1 chosen from 1 choice
hub 6-0:1.0: USB hub found
hub 6-0:1.0: 2 ports detected
insmod used greatest stack depth: 5272 bytes left
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ACPI: PCI Interrupt 0000:00:1a.7[C] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1a.7 to 64
ehci_hcd 0000:00:1a.7: EHCI Host Controller
ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 7
PCI: cache line size of 32 is not supported by device 0000:00:1a.7
ehci_hcd 0000:00:1a.7: irq 18, io mem 0xf9205000
ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb7: configuration #1 chosen from 1 choice
hub 7-0:1.0: USB hub found
hub 7-0:1.0: 6 ports detected
ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 8
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 23, io mem 0xf9204000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb 1-1: USB disconnect, address 2
usb usb8: configuration #1 chosen from 1 choice
hub 8-0:1.0: USB hub found
hub 8-0:1.0: 6 ports detected
insmod used greatest stack depth: 5264 bytes left
SCSI subsystem initialized
libata version 2.21 loaded.
ahci 0000:00:1f.2: version 2.3
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
usb 7-1: new high speed USB device using ehci_hcd and address 2
usb 7-1: configuration #1 chosen from 1 choice
hub 7-1:1.0: USB hub found
hub 7-1:1.0: 2 ports detected
usb 7-1.1: new high speed USB device using ehci_hcd and address 4
ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA
mode
ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pmp pio slum part
PCI: Setting latency timer of device 0000:00:1f.2 to 64
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
scsi3 : ahci
scsi4 : ahci
scsi5 : ahci
ata1: SATA max UDMA/133 cmd 0xffffc2000033a100 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 2299
ata2: SATA max UDMA/133 cmd 0xffffc2000033a180 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 2299
ata3: SATA max UDMA/133 cmd 0xffffc2000033a200 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 2299
ata4: SATA max UDMA/133 cmd 0xffffc2000033a280 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 2299
ata5: SATA max UDMA/133 cmd 0xffffc2000033a300 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 2299
ata6: SATA max UDMA/133 cmd 0xffffc2000033a380 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 2299
usb 7-1.1: configuration #1 chosen from 1 choice
hub 7-1.1:1.0: USB hub found
hub 7-1.1:1.0: 4 ports detected
usb 7-1.2: new high speed USB device using ehci_hcd and address 5
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7: Maxtor 6H500F0, HA431DD0, max UDMA/133
ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
usb 7-1.2: configuration #1 chosen from 1 choice
usb 1-2: new low speed USB device using uhci_hcd and address 3
ata2: SATA link down (SStatus 0 SControl 300)
usb 1-2: configuration #1 chosen from 1 choice
input: Microsft Microsoft Wireless Optical Desktop® 2.10 as
/class/input/input2
input: USB HID v1.11 Mouse [Microsft Microsoft Wireless Optical Desktop®
2.10] on usb-0000:00:1a.0-2
ata3: SATA link down (SStatus 0 SControl 300)
usb 6-1: new low speed USB device using uhci_hcd and address 2
usb 6-1: configuration #1 chosen from 1 choice
hiddev96: USB HID v1.00 Device [SmartHome SmartHome PowerLinc
Controller] on usb-0000:00:1d.2-1
ata4: SATA link down (SStatus 0 SControl 300)
ata5: SATA link down (SStatus 0 SControl 300)
ata6: SATA link down (SStatus 0 SControl 300)
scsi 0:0:0:0: Direct-Access ATA Maxtor 6H500F0 HA43 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 >
sd 0:0:0:0: [sda] Attached SCSI disk
ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 16 (level, low) -> IRQ 16
ahci 0000:03:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
ahci 0000:03:00.0: flags: 64bit ncq pm led clo pmp pio slum part
PCI: Setting latency timer of device 0000:03:00.0 to 64
scsi6 : ahci
scsi7 : ahci
ata7: SATA max UDMA/133 cmd 0xffffc2000033c100 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 16
ata8: SATA max UDMA/133 cmd 0xffffc2000033c180 ctl 0x0000000000000000
bmdma 0x0000000000000000 irq 16
ata7: SATA link down (SStatus 0 SControl 300)
ata8: SATA link down (SStatus 0 SControl 300)
insmod used greatest stack depth: 3560 bytes left
Initializing USB Mass Storage driver...
scsi8 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 5
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 8:0:0:0: Direct-Access SMSC 223 U HS-CF 3.60 PQ: 0 ANSI: 0
scsi 8:0:0:1: Direct-Access SMSC 223 U HS-MS 3.60 PQ: 0 ANSI: 0
scsi 8:0:0:2: Direct-Access SMSC 223 U HS-SM 3.60 PQ: 0 ANSI: 0
scsi 8:0:0:3: Direct-Access SMSC 223 U HS-SD/MMC 3.60 PQ: 0 ANSI: 0
sd 8:0:0:0: [sdb] Attached SCSI removable disk
sd 8:0:0:1: [sdc] Attached SCSI removable disk
sd 8:0:0:2: [sdd] Attached SCSI removable disk
sd 8:0:0:3: [sde] Attached SCSI removable disk
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: Disabled at runtime.
SELinux: Unregistering netfilter hooks
audit(1187132993.753:2): selinux=0 auid=4294967295
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 8:0:0:0: Attached scsi generic sg1 type 0
sd 8:0:0:1: Attached scsi generic sg2 type 0
sd 8:0:0:2: Attached scsi generic sg3 type 0
sd 8:0:0:3: Attached scsi generic sg4 type 0
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
Floppy drive(s): fd0 is 1.44M
iTCO_vendor_support: vendor-support=0
FDC 0 is a post-1991 82077
rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.02 (26-Jul-2007)
iTCO_wdt: failed to reset NO_REBOOT flag, reboot disabled by hardware
iTCO_wdt: No card detected
ACPI: PCI Interrupt 0000:00:1f.3[C] -> GSI 18 (level, low) -> IRQ 18
input: Power Button (FF) as /class/input/input3
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input4
ACPI: Power Button (CM) [PWRB]
r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:04:00.0 to 64
eth0: RTL8168b/8111b at 0xffffc20000340000, 00:1a:4d:47:ec:73, XID
38000000 IRQ 17
ACPI: PCI Interrupt 0000:05:06.0[A] -> GSI 18 (level, low) -> IRQ 18
firewire_ohci: Added fw-ohci device 0000:05:06.0, OHCI version 1.10
ACPI: PCI Interrupt 0000:03:00.1[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:03:00.1 to 64
scsi9 : pata_jmicron
scsi10 : pata_jmicron
ata9: PATA max UDMA/100 cmd 0x000000000001c000 ctl 0x000000000001c102
bmdma 0x000000000001c400 irq 17
ata10: PATA max UDMA/100 cmd 0x000000000001c200 ctl 0x000000000001c302
bmdma 0x000000000001c408 irq 17
nvidia: module license 'NVIDIA' taints kernel.
firewire_core: created new fw device fw0 (0 config rom retries, S400)
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:01:00.0 to 64
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 100.14.11 Wed Jun 13
16:33:22 PDT 2007
ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22
PCI: Setting latency timer of device 0000:00:1b.0 to 64
hda_codec: Unknown model for ALC882, trying auto-probe from BIOS...
loop: module loaded
lp: driver loaded but no devices found
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
No dock devices found.
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised:
dm-devel@redhat.com
device-mapper: multipath: version 1.0.5 loaded
EXT3 FS on sda6, internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda8, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda9, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda10, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
fuse init (API version 7.8)
Adding 2000052k swap on /dev/sda5. Priority:-1 extents:1 across:2000052k
ip6_tables: (C) 2000-2006 Netfilter Core Team
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
r8169: eth0: link up
r8169: eth0: link up
Bluetooth: Core ver 2.11
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.8
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
it87: Found IT8718F chip at 0x290, revision 4
it87: in3 is VCC (+5V)
coretemp coretemp.0: Using undocumented features, absolute temperature
might be wrong!
coretemp coretemp.1: Using undocumented features, absolute temperature
might be wrong!
eth0: no IPv6 routers present
Bridge firewalling registered
=============================================================================
BUG kmalloc-96 (Tainted: P ): Poison overwritten
-----------------------------------------------------------------------------
INFO: 0xffff810077d36d50-0xffff810077d36d57. First byte 0x0 instead of 0x6b
INFO: Allocated in __nf_ct_ext_add+0x50/0x1bc [nf_conntrack] age=8806
cpu=0 pid=2908
INFO: Freed in __nf_ct_ext_add+0x14b/0x1bc [nf_conntrack] age=4805 cpu=0
pid=2908
INFO: Slab 0xffff8100039f0440 used=18 fp=0xffff810077d36d20
flags=0x700800000000c3
INFO: Object 0xffff810077d36d20 @offset=3360 fp=0xffff810077d36e70
Bytes b4 0xffff810077d36d10: b6 1a fc ff 00 00 00 00 5a 5a 5a 5a 5a 5a
5a 5a ¶.üÿ....ZZZZZZZZ
Object 0xffff810077d36d20: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b kkkkkkkkkkkkkkkk
Object 0xffff810077d36d30: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b kkkkkkkkkkkkkkkk
Object 0xffff810077d36d40: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b kkkkkkkkkkkkkkkk
Object 0xffff810077d36d50: 00 00 00 00 00 00 00 00 6b 6b 6b 6b 6b 6b
6b 6b ........kkkkkkkk
Object 0xffff810077d36d60: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b kkkkkkkkkkkkkkkk
Object 0xffff810077d36d70: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b a5 kkkkkkkkkkkkkkk¥
Redzone 0xffff810077d36d80: bb bb bb bb bb bb bb
bb »»»»»»»»
Padding 0xffff810077d36dc0: 5a 5a 5a 5a 5a 5a 5a
5a ZZZZZZZZ
Call Trace:
[<ffffffff810978c4>] check_bytes_and_report+0xa3/0xc9
[<ffffffff81097b88>] check_object+0xc5/0x23a
[<ffffffff81098f62>] __slab_alloc+0x41e/0x43b
[<ffffffff88036be0>] :ext3:ext3_htree_store_dirent+0x2a/0xeb
[<ffffffff88036be0>] :ext3:ext3_htree_store_dirent+0x2a/0xeb
[<ffffffff8109a3a4>] __kmalloc+0x61/0xb5
[<ffffffff88036be0>] :ext3:ext3_htree_store_dirent+0x2a/0xeb
[<ffffffff8803e266>] :ext3:htree_dirblock_to_tree+0x103/0x13e
[<ffffffff8803e31d>] :ext3:ext3_htree_fill_tree+0x7c/0x1cb
[<ffffffff81098ec3>] __slab_alloc+0x37f/0x43b
[<ffffffff88036d2d>] :ext3:ext3_readdir+0x8c/0x513
[<ffffffff88036d2d>] :ext3:ext3_readdir+0x8c/0x513
[<ffffffff810aadc0>] filldir+0x0/0xb7
[<ffffffff88036e44>] :ext3:ext3_readdir+0x1a3/0x513
[<ffffffff8109f9f1>] file_move+0x1d/0x49
[<ffffffff810aadc0>] filldir+0x0/0xb7
[<ffffffff81262bb6>] __mutex_lock_slowpath+0x299/0x2a6
[<ffffffff810aadc0>] filldir+0x0/0xb7
[<ffffffff810aaeee>] vfs_readdir+0x77/0xa9
[<ffffffff810ab140>] sys_getdents+0x75/0xbd
[<ffffffff8100bcbe>] system_call+0x7e/0x83
FIX kmalloc-96: Restoring 0xffff810077d36d50-0xffff810077d36d57=0x6b
FIX kmalloc-96: Marking all objects used
virbr0: no IPv6 routers present
interrupts:
CPU0 CPU1
0: 112 1 IO-APIC-edge timer
1: 3310 122 IO-APIC-edge i8042
6: 5 1 IO-APIC-edge floppy
8: 0 0 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
16: 14972 17489 IO-APIC-fasteoi uhci_hcd:usb1, ahci, nvidia
17: 12 116 IO-APIC-fasteoi libata, eth0
18: 15068 438 IO-APIC-fasteoi uhci_hcd:usb3,
uhci_hcd:usb6, ehci_hcd:usb7, firewire_ohci
19: 0 0 IO-APIC-fasteoi uhci_hcd:usb5
21: 0 0 IO-APIC-fasteoi uhci_hcd:usb2
22: 100 100 IO-APIC-fasteoi HDA Intel
23: 1 1 IO-APIC-fasteoi uhci_hcd:usb4, ehci_hcd:usb8
2299: 7922 3455 PCI-MSI-edge ahci
NMI: 0 0
LOC: 57043 57922
ERR: 0
ethtool (shortly after boot):
NIC statistics:
tx_packets: 137
rx_packets: 38
tx_errors: 0
rx_errors: 0
rx_missed: 0
align_errors: 878
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 22
broadcast: 10
multicast: 16
tx_aborted: 0
tx_underrun: 0
(and after some tests):
NIC statistics:
tx_packets: 1273862
rx_packets: 605126
tx_errors: 0
rx_errors: 0
rx_missed: 0
align_errors: 878
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 604360
broadcast: 643
multicast: 766
tx_aborted: 0
tx_underrun: 0
^ 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