* [PATCH 1/2] rt2x00: Write the frame *after* padding (rt2800 usb devices)
From: Ismael Luceno @ 2010-12-20 8:31 UTC (permalink / raw)
To: linux-wireless; +Cc: Ivo Van Doorn, Gertjan van Wingerde, Ismael Luceno
Signed-off-by: Ismael Luceno <ismael.luceno@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800usb.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 3e0205d..85185de 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -378,9 +378,10 @@ static void rt2800usb_write_tx_data(struct queue_entry *entry,
* | TXINFO | TXWI | 802.11 header | L2 pad | payload | pad | USB end pad |
* |<------------- tx_pkt_len ------------->|
*/
- rt2800_write_tx_data(entry, txdesc);
- padding_len = roundup(entry->skb->len + 4, 4) - entry->skb->len;
- memset(skb_put(entry->skb, padding_len), 0, padding_len);
+ padding_len = roundup(entry->skb->len + 4, 4) - entry->skb->len;
+ memset(skb_put(entry->skb, padding_len), 0, padding_len);
+
+ rt2800_write_tx_data(entry, txdesc);
}
/*
--
1.7.3.4
^ permalink raw reply related
* smatch stuff: potential read past the end of the buffer
From: Dan Carpenter @ 2010-12-20 8:30 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linux-wireless, ath9k-devel
Hello Vasanthakumar,
Smatch complains that in linux-next 60e0c3a7 "ath9k_hw: Eeeprom changes
for AR9485" means there is a potential read past the end of the buffer
int ar9300_eeprom_restore_internal().
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c +3381
ar9300_eeprom_restore_internal(81)
error: buffer overflow 'word' 2048 <= 4099
"word" is allocated with 2048 bytes:
word = kzalloc(2048, GFP_KERNEL);
"length" can be up to 4099:
if ((!AR_SREV_9485(ah) && length >= 1024) ||
(AR_SREV_9485(ah) && length >= (4 * 1024))) {
^^^^^^^^^^^^^^^^^^^^^
so "osize" can be up to 4099 as well:
osize = length;
We're reading way past the end of the word array here:
mchecksum = word[COMP_HDR_LEN + osize] |
^^^^^^^^^^^^^^^^^^^^^^^^^^
(word[COMP_HDR_LEN + osize + 1] << 8);
I don't know how to fix this. Can you take a look?
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 1/2] ath9k: Fix warnings on card removal
From: Rajkumar Manoharan @ 2010-12-20 8:10 UTC (permalink / raw)
To: linville; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1292660258-4063-1-git-send-email-rmanoharan@atheros.com>
On Sat, Dec 18, 2010 at 01:47:37PM +0530, Rajkumar Manoharan wrote:
> There is no point in doing register read/write operations
> when is hardware is not present. This leads to unnecessary
> warnings on log. This patch resolves the following
> warnings on card removal.
>
John,
This patch does not handle module unload case. will send v2 patch.
--
Rajkumar
^ permalink raw reply
* Re: [PATCH] rndis_wlan: scanning, workaround device returning incorrect bssid-list item count.
From: Jussi Kivilinna @ 2010-12-20 7:59 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20101218145929.13559.78929.stgit@fate.lan>
Quoting Jussi Kivilinna <jussi.kivilinna@mbnet.fi>:
> Sometimes device returns wrong number of items in bssid-list.
> Appears that some specific beacons
> trigger this problem and leads to very poor scanning results.
> Workaround by ignoring num_items
> received from device and walkthrough full bssid-list buffer.
>
Please, don't take patch. It causes oops with other user, that I have to
solve first.
-Jussi
> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
> ---
> drivers/net/wireless/rndis_wlan.c | 22 ++++++++++++++--------
> 1 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/rndis_wlan.c
> b/drivers/net/wireless/rndis_wlan.c
> index 4a4f005..8db8333 100644
> --- a/drivers/net/wireless/rndis_wlan.c
> +++ b/drivers/net/wireless/rndis_wlan.c
> @@ -1967,8 +1967,8 @@ static struct cfg80211_bss
> *rndis_bss_info_update(struct usbnet *usbdev,
> int ie_len, bssid_len;
> u8 *ie;
>
> - netdev_dbg(usbdev->net, " found bssid: '%.32s' [%pM]\n",
> - bssid->ssid.essid, bssid->mac);
> + netdev_dbg(usbdev->net, " found bssid: '%.32s' [%pM], len: %d\n",
> + bssid->ssid.essid, bssid->mac, le32_to_cpu(bssid->length));
>
> /* parse bssid structure */
> bssid_len = le32_to_cpu(bssid->length);
> @@ -2008,10 +2008,10 @@ static int rndis_check_bssid_list(struct
> usbnet *usbdev, u8 *match_bssid,
> void *buf = NULL;
> struct ndis_80211_bssid_list_ex *bssid_list;
> struct ndis_80211_bssid_ex *bssid;
> - int ret = -EINVAL, len, count, bssid_len;
> + int ret = -EINVAL, len, count, bssid_len, real_count;
> bool resized = false;
>
> - netdev_dbg(usbdev->net, "check_bssid_list\n");
> + netdev_dbg(usbdev->net, "%s\n", __func__);
>
> len = CONTROL_BUFFER_SIZE;
> resize_buf:
> @@ -2035,10 +2035,13 @@ resize_buf:
> bssid = bssid_list->bssid;
> bssid_len = le32_to_cpu(bssid->length);
> count = le32_to_cpu(bssid_list->num_items);
> - netdev_dbg(usbdev->net, "check_bssid_list: %d BSSIDs found (buflen: %d)\n",
> - count, len);
> + real_count = 0;
> + netdev_dbg(usbdev->net, "%s, buflen: %d\n", __func__, len);
>
> - while (count && ((void *)bssid + bssid_len) <= (buf + len)) {
> + /* Device returns incorrect 'num_items'. Workaround by ignoring the
> + * received 'num_items' and walking through full bssid buffer instead.
> + */
> + while (bssid_len > 0 && ((void *)bssid + bssid_len) <= (buf + len)) {
> if (rndis_bss_info_update(usbdev, bssid) && match_bssid &&
> matched) {
> if (compare_ether_addr(bssid->mac, match_bssid))
> @@ -2047,9 +2050,12 @@ resize_buf:
>
> bssid = (void *)bssid + bssid_len;
> bssid_len = le32_to_cpu(bssid->length);
> - count--;
> + real_count++;
> }
>
> + netdev_dbg(usbdev->net, "%s, num_items from device: %d, really found: "
> + "%d\n", __func__, count, real_count);
> +
> out:
> kfree(buf);
> return ret;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: [linux-pm] subtle pm_runtime_put_sync race and sdio functions
From: Alan Stern @ 2010-12-20 3:37 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Ohad Ben-Cohen, linux-pm, Johannes Berg, linux-wireless,
linux-mmc, Ido Yariv, Kevin Hilman
In-Reply-To: <201012191122.09581.rjw@sisk.pl>
On Sun, 19 Dec 2010, Rafael J. Wysocki wrote:
> That said, I think we may do something different that perhaps will make your
> life somewhat easier.
>
> Namely, if your driver doesn't implement any system suspend callbacks
> (i.e. ->suspend(), ->resume(), ->freeze(), ->thaw() etc.) and it doesn't
> want the analogous subsystem callbacks to be executed for the device, it will
> make sense to flag the device as "runtime only", or something like this,
> which make the PM core skip the device in dpm_suspend() etc.
>
> In that case, if a device if flagged as "runtime only", we can avoid
> calling pm_runtime_get_noirq() for it in dpm_prepare() and, analogously,
> calling pm_runtime_put_sync() for it in dpm_complete(). However, we will have
> to fail system suspend (or hibernation) if a "runtime only" device has the
> power.runtime_auto flag unset.
Or more generally, if pm_runtime_suspended() doesn't return 'true' for
the device. But if the device gets suspended asynchronously, this may
very well happen. For example, an i2c device is originally runtime
suspended, but its device_suspend() call occurs at the same time as the
call for the RTC device, so the i2c device actually happens to be
resumed at that time in order to communicate with the RTC.
> So, I think we can add a "runtime only" flag working as described above.
> I guess it will also help in the case I've been discussing with Kevin for some
> time (i2c device using runtime PM used by an RTC in a semi-transparent
> fashion).
>
> Alan, what do you think?
I'm not sure. In this situation, should we worry more that we usually
do about the possibility of a runtime resume occurring after the device
has gone through device_suspend()? Or just depend on the driver to do
everything correctly?
Alan Stern
^ permalink raw reply
* [PATCH] ath9k_htc: Fix warning on device removal
From: Sujith @ 2010-12-20 2:32 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Luis.Rodriguez
From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
The commit "ath9k_hw: warn if we cannot change the power to the chip"
introduced a new warning to indicate chip powerup failures, but this
is not required for devices that have been removed. Handle USB device
removal properly by checking for unplugged status.
For PCI devices, this warning will still be seen when the card is pulled
out, not sure how to check for card removal.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/eeprom.h | 2 --
drivers/net/wireless/ath/ath9k/hif_usb.c | 6 +++---
drivers/net/wireless/ath/ath9k/htc.h | 5 ++---
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 5 +----
drivers/net/wireless/ath/ath9k/hw.c | 4 +++-
drivers/net/wireless/ath/ath9k/hw.h | 4 ++++
drivers/net/wireless/ath/ath9k/wmi.c | 2 +-
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h b/drivers/net/wireless/ath/ath9k/eeprom.h
index f6f09d1..58e2ddc 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/eeprom.h
@@ -23,8 +23,6 @@
#include <net/cfg80211.h>
#include "ar9003_eeprom.h"
-#define AH_USE_EEPROM 0x1
-
#ifdef __BIG_ENDIAN
#define AR5416_EEPROM_MAGIC 0x5aa5
#else
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 22b68b3..c20c8c8 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -993,16 +993,16 @@ static void ath9k_hif_usb_disconnect(struct usb_interface *interface)
{
struct usb_device *udev = interface_to_usbdev(interface);
struct hif_device_usb *hif_dev = usb_get_intfdata(interface);
+ bool unplugged = (udev->state == USB_STATE_NOTATTACHED) ? true : false;
if (hif_dev) {
- ath9k_htc_hw_deinit(hif_dev->htc_handle,
- (udev->state == USB_STATE_NOTATTACHED) ? true : false);
+ ath9k_htc_hw_deinit(hif_dev->htc_handle, unplugged);
ath9k_htc_hw_free(hif_dev->htc_handle);
ath9k_hif_usb_dev_deinit(hif_dev);
usb_set_intfdata(interface, NULL);
}
- if (hif_dev->flags & HIF_USB_START)
+ if (!unplugged && (hif_dev->flags & HIF_USB_START))
ath9k_hif_usb_reboot(udev);
kfree(hif_dev);
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index fdf9d5f..e6c2f0a 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -339,9 +339,8 @@ void ath_htc_cancel_btcoex_work(struct ath9k_htc_priv *priv);
#define OP_ASSOCIATED BIT(7)
#define OP_ENABLE_BEACON BIT(8)
#define OP_LED_DEINIT BIT(9)
-#define OP_UNPLUGGED BIT(10)
-#define OP_BT_PRIORITY_DETECTED BIT(11)
-#define OP_BT_SCAN BIT(12)
+#define OP_BT_PRIORITY_DETECTED BIT(10)
+#define OP_BT_SCAN BIT(11)
struct ath9k_htc_priv {
struct device *dev;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 0f6be35..724f545 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -851,9 +851,6 @@ int ath9k_htc_probe_device(struct htc_target *htc_handle, struct device *dev,
if (ret)
goto err_init;
- /* The device may have been unplugged earlier. */
- priv->op_flags &= ~OP_UNPLUGGED;
-
ret = ath9k_init_device(priv, devid, product, drv_info);
if (ret)
goto err_init;
@@ -873,7 +870,7 @@ void ath9k_htc_disconnect_device(struct htc_target *htc_handle, bool hotunplug)
/* Check if the device has been yanked out. */
if (hotunplug)
- htc_handle->drv_priv->op_flags |= OP_UNPLUGGED;
+ htc_handle->drv_priv->ah->ah_flags |= AH_UNPLUGGED;
ath9k_deinit_device(htc_handle->drv_priv);
ath9k_deinit_wmi(htc_handle->drv_priv);
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index ddda76f..f41c7a2 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1615,7 +1615,9 @@ bool ath9k_hw_setpower(struct ath_hw *ah, enum ath9k_power_mode mode)
* simply keep the ATH_DBG_WARN_ON_ONCE() but make
* ath9k_hw_setpower() return type void.
*/
- ATH_DBG_WARN_ON_ONCE(!status);
+
+ if (!(ah->ah_flags & AH_UNPLUGGED))
+ ATH_DBG_WARN_ON_ONCE(!status);
return status;
}
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 21e37d1..22bd3e8 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -647,6 +647,10 @@ struct ath_nf_limits {
s16 nominal;
};
+/* ah_flags */
+#define AH_USE_EEPROM 0x1
+#define AH_UNPLUGGED 0x2 /* The card has been physically removed. */
+
struct ath_hw {
struct ieee80211_hw *hw;
struct ath_common common;
diff --git a/drivers/net/wireless/ath/ath9k/wmi.c b/drivers/net/wireless/ath/ath9k/wmi.c
index 8f42ea7..573daca 100644
--- a/drivers/net/wireless/ath/ath9k/wmi.c
+++ b/drivers/net/wireless/ath/ath9k/wmi.c
@@ -250,7 +250,7 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum wmi_cmd_id cmd_id,
int time_left, ret = 0;
unsigned long flags;
- if (wmi->drv_priv->op_flags & OP_UNPLUGGED)
+ if (ah->ah_flags & AH_UNPLUGGED)
return 0;
skb = alloc_skb(headroom + cmd_len, GFP_ATOMIC);
--
1.7.3.4
^ permalink raw reply related
* vendor IEs?
From: Daniel Halperin @ 2010-12-20 0:53 UTC (permalink / raw)
To: linux-wireless
Is there a compiled list of vendor-specific IEs out there? Googling
didn't offer much help.
Thx
Dan
^ permalink raw reply
* Re: [PATCH] ath9k: Do not use legacy PCI power management
From: Rafael J. Wysocki @ 2010-12-20 0:14 UTC (permalink / raw)
To: Hauke Mehrtens
Cc: Luis R. Rodriguez, LKML, Linux-pm mailing list, linux-wireless,
ath9k-devel, John W. Linville
In-Reply-To: <4D0E9DE3.8050100@hauke-m.de>
On Monday, December 20, 2010, Hauke Mehrtens wrote:
> On 12/20/2010 12:32 AM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rjw@sisk.pl>
> >
> > The ath9k driver uses legacy PCI power management (system suspend
> > and resume) callbacks, so make it use struct dev_pm_ops callbacks and
> > let the PCI subsystem handle all of the PCI-specific details of
> > system power transitions.
> >
> > This change has been tested on Acer Ferrari One with the
> > Atheros AR928X PCI Express network adapter (rev. 01).
> >
> > Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> > ---
> >
> > Hi,
> >
> > This patch has been sent already once under a slightly different subject
> > and with a different changelog. I'm not sure what happened to it that time,
> > so here it goes again.
> >
> > I'm quite confident it doesn't break things and it simplifies the driver's
> > suspend and resume routines quite a bit, so please apply.
> >
> > Thanks,
> > Rafael
> >
> Hi Rafael,
>
> Your patch was already applied (see commit
> f0e94b479c987abef17eb18e5c8e0ed178d00cd4 in linux-next) or didn't I got
> your problem?
Oh, is it? Sorry for the noise, then.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] ath9k: Do not use legacy PCI power management
From: Hauke Mehrtens @ 2010-12-20 0:05 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Luis R. Rodriguez, LKML, Linux-pm mailing list, linux-wireless,
ath9k-devel, John W. Linville
In-Reply-To: <201012200032.21704.rjw@sisk.pl>
On 12/20/2010 12:32 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rjw@sisk.pl>
>
> The ath9k driver uses legacy PCI power management (system suspend
> and resume) callbacks, so make it use struct dev_pm_ops callbacks and
> let the PCI subsystem handle all of the PCI-specific details of
> system power transitions.
>
> This change has been tested on Acer Ferrari One with the
> Atheros AR928X PCI Express network adapter (rev. 01).
>
> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> ---
>
> Hi,
>
> This patch has been sent already once under a slightly different subject
> and with a different changelog. I'm not sure what happened to it that time,
> so here it goes again.
>
> I'm quite confident it doesn't break things and it simplifies the driver's
> suspend and resume routines quite a bit, so please apply.
>
> Thanks,
> Rafael
>
Hi Rafael,
Your patch was already applied (see commit
f0e94b479c987abef17eb18e5c8e0ed178d00cd4 in linux-next) or didn't I got
your problem?
Hauke
^ permalink raw reply
* [PATCH] ath9k: Do not use legacy PCI power management
From: Rafael J. Wysocki @ 2010-12-19 23:32 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: LKML, Linux-pm mailing list, linux-wireless, ath9k-devel,
John W. Linville
In-Reply-To: <201010160036.17653.rjw@sisk.pl>
From: Rafael J. Wysocki <rjw@sisk.pl>
The ath9k driver uses legacy PCI power management (system suspend
and resume) callbacks, so make it use struct dev_pm_ops callbacks and
let the PCI subsystem handle all of the PCI-specific details of
system power transitions.
This change has been tested on Acer Ferrari One with the
Atheros AR928X PCI Express network adapter (rev. 01).
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
Hi,
This patch has been sent already once under a slightly different subject
and with a different changelog. I'm not sure what happened to it that time,
so here it goes again.
I'm quite confident it doesn't break things and it simplifies the driver's
suspend and resume routines quite a bit, so please apply.
Thanks,
Rafael
---
drivers/net/wireless/ath/ath9k/pci.c | 32 ++++++++++++++------------------
1 file changed, 14 insertions(+), 18 deletions(-)
Index: linux-2.6/drivers/net/wireless/ath/ath9k/pci.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/ath/ath9k/pci.c
+++ linux-2.6/drivers/net/wireless/ath/ath9k/pci.c
@@ -247,34 +247,25 @@ static void ath_pci_remove(struct pci_de
#ifdef CONFIG_PM
-static int ath_pci_suspend(struct pci_dev *pdev, pm_message_t state)
+static int ath_pci_suspend(struct device *device)
{
+ struct pci_dev *pdev = to_pci_dev(device);
struct ieee80211_hw *hw = pci_get_drvdata(pdev);
struct ath_wiphy *aphy = hw->priv;
struct ath_softc *sc = aphy->sc;
ath9k_hw_set_gpio(sc->sc_ah, sc->sc_ah->led_pin, 1);
- pci_save_state(pdev);
- pci_disable_device(pdev);
- pci_set_power_state(pdev, PCI_D3hot);
-
return 0;
}
-static int ath_pci_resume(struct pci_dev *pdev)
+static int ath_pci_resume(struct device *device)
{
+ struct pci_dev *pdev = to_pci_dev(device);
struct ieee80211_hw *hw = pci_get_drvdata(pdev);
struct ath_wiphy *aphy = hw->priv;
struct ath_softc *sc = aphy->sc;
u32 val;
- int err;
-
- pci_restore_state(pdev);
-
- err = pci_enable_device(pdev);
- if (err)
- return err;
/*
* Suspend/Resume resets the PCI configuration space, so we have to
@@ -293,7 +284,15 @@ static int ath_pci_resume(struct pci_dev
return 0;
}
-#endif /* CONFIG_PM */
+static SIMPLE_DEV_PM_OPS(ath9k_pm_ops, ath_pci_suspend, ath_pci_resume);
+#define ATH9K_PM_OPS (&ath9k_pm_ops)
+
+#else /* !CONFIG_PM */
+
+#define ATH9K_PM_OPS NULL
+
+#endif /* !CONFIG_PM */
+
MODULE_DEVICE_TABLE(pci, ath_pci_id_table);
@@ -302,10 +301,7 @@ static struct pci_driver ath_pci_driver
.id_table = ath_pci_id_table,
.probe = ath_pci_probe,
.remove = ath_pci_remove,
-#ifdef CONFIG_PM
- .suspend = ath_pci_suspend,
- .resume = ath_pci_resume,
-#endif /* CONFIG_PM */
+ .driver.pm = ATH9K_PM_OPS,
};
int ath_pci_init(void)
^ permalink raw reply
* Re: Wireless channel stuck to -1 on mon0 (fix patch submission)
From: Johannes Berg @ 2010-12-19 21:36 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: CalimeroTeknik, linux-wireless
In-Reply-To: <AANLkTik5uML3gSD5aJE8CPwew8G5shp9BJgGUK608jTp@mail.gmail.com>
On Sun, 2010-12-19 at 21:58 +0100, Gábor Stefanik wrote:
> This is a known problem, that has basically been WONTFIXed a while
> ago. I highly disagree with the reasoning, but the decision ultimately
> rests on Johannes. In the meantime, check patches.aircrack-ng.org for
> a workaround.
>
> Johannes: I know that you consider reporting the actual channel of the
> PHY to be "confusing to users" when running with multiple virtual
> PHYs, but apparently this is what most users expect. Perhaps it
> *should* be implemented after all.
In which case it should be implemented properly, not half-baked like all
the patches we've seen so far.
johannes
^ permalink raw reply
* Re: Wireless channel stuck to -1 on mon0 (fix patch submission)
From: Gábor Stefanik @ 2010-12-19 20:58 UTC (permalink / raw)
To: CalimeroTeknik, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <4D0DE870.2050503@free.fr>
This is a known problem, that has basically been WONTFIXed a while
ago. I highly disagree with the reasoning, but the decision ultimately
rests on Johannes. In the meantime, check patches.aircrack-ng.org for
a workaround.
Johannes: I know that you consider reporting the actual channel of the
PHY to be "confusing to users" when running with multiple virtual
PHYs, but apparently this is what most users expect. Perhaps it
*should* be implemented after all.
On Sun, Dec 19, 2010 at 12:11 PM, CalimeroTeknik <calimeroteknik@free.fr> wrote:
> [1.] One line summary of the problem:
> I can't change the channel of mon0 which is stuck to -1
>
> [2.] Full description of the problem/report:
> iwconfig mon0 channel 10 gives no error but the channel stays to -1
>
> [3.] Keywords (i.e., modules, networking, kernel):
> Wifi modules used :
> iwlagn 336809 0
> iwlcore 89975 1 iwlagn
> mac80211 199020 2 iwlagn,iwlcore
> cfg80211 139093 3 iwlagn,iwlcore,mac80211
>
> [4.] Kernel information
> [4.1.] Kernel version (from /proc/version):
> Linux version 2.6.37-rc6-mainline (root@m50vn) (gcc version 4.5.2 (GCC)
> ) #1 SMP PREEMPT Sat Dec 18 15:50:20 CET 2010
> nota bene : compiled in *fake*root.
> [4.2.] Kernel .config file:
> attached.
>
> [5.] Most recent kernel version which did not have the bug:
> It worked on 2.6.33 and didn't work on 2.6.36
>
> [6.] Output of Oops.. message (if applicable) with symbolic information
> resolved (see Documentation/oops-tracing.txt)
> None.
>
> [7.] A small shell script or example program which triggers the
> problem (if possible)
> airmon-ng start wlan0
> airodump-ng --channel 1 mon0
>
> You'll notice that despite any attempt of changing the channel, it stays
> to -1.
> [8.] Environment
> [8.1.] Software (add the output of the ver_linux script here)
> [8.2.] Processor information (from /proc/cpuinfo):
> cpu family : 6
> model : 23
> model name : Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz
>
> [8.3.] Module information (from /proc/modules):
> iwlagn 336809 0 - Live 0xffffffffa0317000
> iwlcore 89975 1 iwlagn, Live 0xffffffffa01a2000
> mac80211 199020 2 iwlagn,iwlcore, Live 0xffffffffa02c6000
> cfg80211 139093 3 iwlagn,iwlcore,mac80211, Live 0xffffffffa01c4000
>
> [8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
> attached.
>
> [8.5.] PCI information ('lspci -vvv' as root)
> 03:00.0 Network controller: Intel Corporation Wireless WiFi Link 5100
> Subsystem: Intel Corporation PRO/Wireless 5100AGN Network Connection
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 32 bytes
> Interrupt: pin A routed to IRQ 50
> Region 0: Memory at fdffe000 (64-bit, non-prefetchable) [size=8K]
> Capabilities: [c8] Power Management version 3
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
> PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Address: 00000000fee0300c Data: 41c1
> Capabilities: [e0] Express (v1) Endpoint, MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
> <512ns, L1 unlimited
> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
> MaxPayload 128 bytes, MaxReadReq 128 bytes
> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+
> TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
> Latency L0 <128ns, L1 <32us
> ClockPM+ Surprise- LLActRep- BwNot-
> LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain-
> CommClk+
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> DLActive- BWMgmt- ABWMgmt-
> Capabilities: [100 v1] Advanced Error Reporting
> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> CESta: RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
> AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
> Capabilities: [140 v1] Device Serial Number 00-21-5d-ff-ff-9a-71-9c
> Kernel driver in use: iwlagn
> Kernel modules: iwlagn
>
> complete lspci -vvv attached.
>
> [X] : Patch proposal
> This patch is *very* small and corrects the bug, so I think it could be
> included in final 2.6.37.
> http://patches.aircrack-ng.org/channel-negative-one-maxim.patch
>
> Thanks for reading, and keep up the good work !
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Compat-wireless release for 2010-12-19 is baked
From: Compat-wireless cronjob account @ 2010-12-19 20:02 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
880bb0b..dd8c5e7 master -> origin/master
* [new tag] compat-wireless-2010-12-17 -> compat-wireless-2010-12-17
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat
3547391..64bcd1b master -> origin/master
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
compat-wireless code metrics
777009 - Total upstream lines of code being pulled
2223 - backport code changes
1946 - backport code additions
277 - backport code deletions
6669 - backport from compat module
8892 - total backport code
1.1444 - % of code consists of backport work
1532 - Crap changes not yet posted
1489 - Crap additions not yet posted
43 - Crap deletions not yet posted
0.1972 - % of crap code
Base tree: linux-next.git
Base tree version: next-20101217
compat-wireless release: compat-wireless-2010-12-17-pc
^ permalink raw reply
* Re: [PATCH] orinoco_cs: fix too early irq request
From: Meelis Roos @ 2010-12-19 14:43 UTC (permalink / raw)
To: Dave Kilroy; +Cc: linux-wireless
In-Reply-To: <AANLkTikmtWhSXn6-rFH6ABhSh3soO8jDfomAg9SGe3xX@mail.gmail.com>
> Thanks Meelis. An equivalent patch has already been merged in Linus'
> v2.6.37-rc6 (229bd792b), and wireless-next.
Oops, I tested with 2.6.37-rc4-something when I thought I was testing
the lastest git.
> Does that version also work for you?
Yes, tested with 2.6.37-rc6-00093 and it works fine.
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Recent suspend/resume fix for which devices?
From: Jonas H. @ 2010-12-19 14:42 UTC (permalink / raw)
To: linux-wireless
Hello!
My AR9285 wireless card, used with the ath9k driver, stops working after
supsend/resume - I have to reboot to make it work again.
Trying to figure out whether this is fixed for 2.6.37 I noticed commit
f933ebed (in Linus' tree) "ath9k_htc: Fix suspend/resume.
The HW has to be set to FULLSLEEP mode during suspend, ...".
My question is: Does that fix also apply to my card? I realize the patch
only applies to ath9k_htc but I couldn't figure what "htc" stands for in
this context.
If it doesn't, does this mailing list also function as a bug tracker?
Thanks!
Jonas
^ permalink raw reply
* 2.6.37-rc6-git4: Reported regressions 2.6.35 -> 2.6.36
From: Rafael J. Wysocki @ 2010-12-19 12:41 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some post-2.6.35 regressions introduced before
2.6.36, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.35 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-12-19 98 28 23
2010-12-05 95 34 31
2010-11-19 92 38 34
2010-10-17 70 27 27
2010-10-10 56 16 15
2010-10-03 52 16 14
2010-09-26 46 15 13
2010-09-20 38 15 15
2010-09-12 28 14 13
2010-08-30 21 16 15
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24752
Subject : Random crashes easily reproducible with make -j5 - intel i915 - kernel 2.6.36 on intel/nvidia hybrid graphics machine
Submitter : Giacomo <delleceste@gmail.com>
Date : 2010-12-10 8:57 (10 days old)
Message-ID : <AANLkTimkQM94u9iz7FVVjehB0mwDwfkNwKhF2F2tYq-r@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=129197146619176&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24392
Subject : AGP aperture disabled, worked in 2.6.35
Submitter : Stephen Kitt <steve@sk2.org>
Date : 2010-12-06 06:31 (14 days old)
First-Bad-Commit: http://git.kernel.org/linus/96576a9e1a0cdb8a43d3af5846be0948f52b4460
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24202
Subject : [830] drm:intel_prepare_page_flip, *ERROR* Prepared flip multiple times
Submitter : mkkot <marcin2006@gmail.com>
Date : 2010-12-02 14:10 (18 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24022
Subject : wireless no longer works after 1st update of 10.10 [rtl819xE:ERR in init_firmware()]
Submitter : njin <marconifabio@ubuntu-it.org>
Date : 2010-11-29 19:49 (21 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23812
Subject : HAL does not provide battery information on RHEL5 and CentOS-5
Submitter : Dag Wieers <dag@wieers.com>
Date : 2010-11-26 18:08 (24 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23302
Subject : alsa stops working after one or more hibernate or suspend cycles
Submitter : Werner Lemberg <wl@gnu.org>
Date : 2010-11-19 16:21 (31 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22842
Subject : iwl3945 suddenly stops working
Submitter : Felipe Contreras <felipe.contreras@gmail.com>
Date : 2010-11-14 11:14 (36 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22782
Subject : 2.6.36: general protection fault during lockfs lockspace removal
Submitter : nik@linuxbox.cz <nik@linuxbox.cz>
Date : 2010-11-12 12:05 (38 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22172
Subject : alsa-util.c: snd_pcm_avail_delay() returned strange values: delay 0 is less than avail 32
Submitter : Tobias <devnull@plzk.org>
Date : 2010-11-06 09:33 (44 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22092
Subject : Kernel v2.6.36 trouble on USB disconnect
Submitter : Ketil Froyn <ketil@froyn.name>
Date : 2010-10-29 8:05 (52 days old)
Message-ID : <AANLkTik5qVxkEGVAA1PSOGk2KTW+ekHpSwttsQEWzWj+@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128833956503607&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21662
Subject : 2.6.35->2.6.36 regression, vanilla kernel panic, ppp or hrtimers crashing
Submitter : Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Date : 2010-10-25 9:22 (56 days old)
Message-ID : <201010251222.37191.nuclearcat@nuclearcat.com>
References : http://marc.info/?l=linux-kernel&m=128799855826011&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21652
Subject : several problems with intel graphics since 2.6.36
Submitter : Norbert Preining <preining@logic.at>
Date : 2010-10-27 14:32 (54 days old)
Message-ID : <20101027143252.GA8676@gamma.logic.tuwien.ac.at>
References : http://marc.info/?l=linux-kernel&m=128818998630241&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21402
Subject : [KVM] Noacpi Windows guest can not boot up on 32bit KVM host
Submitter : xudong <xudong.hao@intel.com>
Date : 2010-10-29 03:01 (52 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20332
Subject : [LogFS] [2.6.36-rc7] Kernel BUG at lib/btree.c:465!
Submitter : Prasad Joshi <prasadjoshi124@gmail.com>
Date : 2010-10-12 18:56 (69 days old)
Message-ID : <AANLkTimAbCZNhLQ5nADUiAC+7JpAeJBEmjFwdxyZ-FxO@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128690910501830&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20322
Subject : 2.6.36-rc7: inconsistent lock state: inconsistent {IN-RECLAIM_FS-R} -> {RECLAIM_FS-ON-W} usage.
Submitter : Dave Jones <davej@redhat.com>
Date : 2010-10-11 20:10 (70 days old)
Message-ID : <20101011201007.GA29707@redhat.com>
References : http://marc.info/?l=linux-kernel&m=128682782828453&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20232
Subject : kworker consumes ~100% CPU on HP Elitebook 8540w running 2.6.36_rc6-git4
Submitter : Ozan Caglayan <ozan@pardus.org.tr>
Date : 2010-10-13 06:13 (68 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19632
Subject : 2.6.36-rc6: modprobe Not tainted warning
Submitter : Heinz Diehl <htd@fritha.org>
Date : 2010-09-30 18:25 (81 days old)
Message-ID : <20100930182516.GA15089@fritha.org>
References : http://marc.info/?l=linux-kernel&m=128587114004680&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19392
Subject : WARNING: at drivers/net/wireless/ath/ath5k/base.c:3475 ath5k_bss_info_changed+0x44/0x168 [ath5k]()
Submitter : Justin Mattock <justinmattock@gmail.com>
Date : 2010-09-28 22:30 (83 days old)
Message-ID : <<AANLkTim5WCGKPvEkOkO_YnMF9pg8mvLfQoFBNUFpfa_k@mail.gmail.com>>
References : http://marc.info/?l=linux-kernel&m=128571307018635&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19372
Subject : 2.6.36-rc6: WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0x35a/0x3c0
Submitter : Alexey Dobriyan <adobriyan@gmail.com>
Date : 2010-09-29 21:29 (82 days old)
Message-ID : <20100929212923.GA5578@core2.telecom.by>
References : http://marc.info/?l=linux-kernel&m=128579579400315&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19052
Subject : 2.6.36-rc5-git1 -- [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2010-09-22 23:47 (89 days old)
Message-ID : <AANLkTikWQjUQjFJU9MO1+XbSLAEE-GARz+S+Dz2Fgu4h@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128519926626322&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17121
Subject : Two blank rectangles more than 10 cm long when booting
Submitter : Eric Valette <eric.valette@free.fr>
Date : 2010-08-26 17:24 (116 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17061
Subject : 2.6.36-rc1 on zaurus: bluetooth regression
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2010-08-21 15:24 (121 days old)
Message-ID : <20100821152445.GA1536@ucw.cz>
References : http://marc.info/?l=linux-kernel&m=128240433828087&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16951
Subject : hackbench regression with 2.6.36-rc1
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2010-08-18 6:18 (124 days old)
Message-ID : <1282112318.21202.8.camel@ymzhang.sh.intel.com>
References : http://marc.info/?l=linux-kernel&m=128211235904910&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21092
Subject : Kernel 2.6.36 Bug during quotaon on reiserfs
Submitter : <markus.gapp@gmx.net>
Date : 2010-10-24 16:57 (57 days old)
Handled-By : Jan Kara <jack@suse.cz>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=35292
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20462
Subject : 2.6.36-rc7-git2 - panic/GPF: e1000e/vlans?
Submitter : Nikola Ciprich <extmaillist@linuxbox.cz>
Date : 2010-10-15 7:10 (66 days old)
Message-ID : <20101015071008.GA8714@pcnci.linuxbox.cz>
References : http://marc.info/?l=linux-kernel&m=128712984831303&w=2
Handled-By : Jesse Gross <jesse@nicira.com>
Patch : http://www.spinics.net/lists/netdev/msg146227.html
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20342
Subject : [LogFS] [2.6.36-rc7] Deadlock in logfs_get_wblocks, hold and wait on same lock super->s_write_mutex
Submitter : Prasad Joshi <prasadjoshi124@gmail.com>
Date : 2010-10-13 9:49 (68 days old)
Message-ID : <AANLkTinvsMxTxEbDEFmb5M-6fYjdRvErU==Zs7+qANkV@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128696335024718&w=2
Patch : https://patchwork.kernel.org/patch/328682/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20162
Subject : [LogFS][2.6.36.rc7+] Kernel BUG at readwrite.c:1193
Submitter : Prasad Joshi <prasadjoshi124@gmail.com>
Date : 2010-10-10 17:44 (71 days old)
Message-ID : <AANLkTi=JkcuWBPo+X-i+9o-BJFVqjea1J3e=Mr=HvAWF@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128673196203340&w=2
Handled-By : Prasad Gajanan Joshi <prasadjoshi124@gmail.com>
Patch : https://bugzilla.kernel.org/show_bug.cgi?id=20162#c1
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16971
Subject : qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq
Submitter : Meelis Roos <mroos@linux.ee>
Date : 2010-08-19 21:03 (123 days old)
Message-ID : <<<alpine.SOC.1.00.1008192359310.19654@math.ut.ee>>>
References : http://marc.info/?l=linux-kernel&m=128225184900892&w=2
Patch : http://marc.info/?l=linux-scsi&m=128590267608876&w=2
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.35 and 2.6.36, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=16444
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* 2.6.37-rc6-git4: Reported regressions from 2.6.36
From: Rafael J. Wysocki @ 2010-12-19 12:28 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.36,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 2.6.36, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-12-19 73 28 24
2010-12-03 55 25 19
2010-11-19 39 29 25
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25012
Subject : BUG: i915 causes NULL pointer dereference in 2.6.37-rc5-git4
Submitter : Tõnu Raitviir <jussuf@linux.ee>
Date : 2010-12-15 12:48 (5 days old)
Message-ID : <alpine.DEB.2.00.1012151238570.4797@jbbyvx.ohzcpyho.rr>
References : http://www.spinics.net/lists/dri-devel/msg06282.html
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24892
Subject : Wireless warning, system locks up
Submitter : Heinz Diehl <htd@fancy-poultry.org>
Date : 2010-12-14 15:16 (6 days old)
Handled-By : John W. Linville <linville@tuxdriver.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24882
Subject : PM/Hibernate: Memory corruption patch introduces regression (2.6.36.2)
Submitter : <akwatts@ymail.com>
Date : 2010-12-14 04:00 (6 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24822
Subject : Embedded DisplayPort is detected wrongly on HP ProBook 5320m
Submitter : Takashi Iwai <tiwai@suse.de>
Date : 2010-12-13 11:09 (7 days old)
Handled-By : Chris Wilson <chris@chris-wilson.co.uk>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24772
Subject : Crash with btrfs rootfs on dm-crypt [ kernel BUG at fs/btrfs/inode.c:806! ] on linux 2.6.37-rc5
Submitter : Fabio Comolli <fabio.comolli@gmail.com>
Date : 2010-12-10 20:30 (10 days old)
Message-ID : <AANLkTi=j9zsaYNcu=NgGV=HfE-3rNHzVswov8VrgwjQp@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=129201308706568&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24762
Subject : BUG at perf_ctx_adjust_freq (kernel/perf_event.c:1582)
Submitter : Chris Wilson <chris@chris-wilson.co.uk>
Date : 2010-12-10 12:00 (10 days old)
Message-ID : <c6d829$pqibha@fmsmga001.fm.intel.com>
References : http://marc.info/?l=linux-kernel&m=129198247531612&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24722
Subject : Disconnecting my USB mouse hangs the machine and issues kernel warning
Submitter : Heinz Diehl <htd@fancy-poultry.org>
Date : 2010-12-12 12:42 (8 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24592
Subject : 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect
Submitter : Jeremy Fitzhardinge <jeremy@goop.org>
Date : 2010-12-08 21:09 (12 days old)
Message-ID : <4CFFF3F3.90100@goop.org>
References : http://marc.info/?l=linux-kernel&m=129184256629712&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24582
Subject : Kernel Oops at tty_buffer_request_room when using pppd program (2.6.37-rc4)
Submitter : baoyb <baoyb@avit.org.cn>
Date : 2010-12-08 13:55 (12 days old)
Message-ID : <EF6DDE218DB34702B1FA84D6CD7EA771@baoyb>
References : http://marc.info/?l=linux-kernel&m=129181763525738&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24372
Subject : kdump broken on 2.6.37-rc4
Submitter : Stanislaw Gruszka <sgruszka@redhat.com>
Date : 2010-12-03 11:16 (17 days old)
Message-ID : <20101203111623.GA2741@redhat.com>
References : http://marc.info/?l=linux-kernel&m=129137502323003&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24362
Subject : perf hw in kexeced kernel broken in tip
Submitter : Yinghai Lu <yinghai@kernel.org>
Date : 2010-12-01 8:00 (19 days old)
First-Bad-Commit: http://git.kernel.org/linus/33c6d6a7ad0ffab9b1b15f8e4107a2af072a05a0
Message-ID : <4CF60095.1020900@kernel.org>
References : http://marc.info/?l=linux-kernel&m=129119055922065&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24272
Subject : iotop reports insane per-process disk read/write statistics
Submitter : Brian Rogers <brian@xyzw.org>
Date : 2010-12-03 12:00 (17 days old)
First-Bad-Commit: http://git.kernel.org/linus/85893120699f8bae8caa12a8ee18ab5fceac978e
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24142
Subject : Crash at boot in udev while accessing bt848 device in 2.6.37-rc*
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2010-11-30 20:50 (20 days old)
References : https://bugzilla.kernel.org/show_bug.cgi?id=24602
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23902
Subject : [BUG] 2.6.37-rc3 massive interactivity regression on ARM
Submitter : Mikael Pettersson <mikpe@it.uu.se>
Date : 2010-11-27 15:16 (23 days old)
First-Bad-Commit: http://git.kernel.org/linus/305e6835e05513406fa12820e40e4a8ecb63743c
Message-ID : <<19697.8378.717761.236202@pilspetsen.it.uu.se>>
References : http://marc.info/?l=linux-kernel&m=129087098911837&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23472
Subject : 2.6.37-rc2 vs. 2.6.36 laptop backlight changes?
Submitter : Patrick Schaaf <netdev@bof.de>
Date : 2010-11-17 13:41 (33 days old)
Message-ID : <1290001262.5727.2.camel@lat1>
References : http://marc.info/?l=linux-kernel&m=129000127920912&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23102
Subject : [bisected] i915 regression in post 2.6.36 kernels
Submitter : Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
Date : 2010-11-10 7:02 (40 days old)
Message-ID : <201011100802.20332.johannes.hirte@fem.tu-ilmenau.de>
References : http://marc.info/?l=linux-kernel&m=128937310017057&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22942
Subject : [2.6.37-rc1, OOM] virtblk: OOM in do_virtblk_request()
Submitter : Dave Chinner <david@fromorbit.com>
Date : 2010-11-05 1:30 (45 days old)
Message-ID : <20101105013003.GE13830@dastard>
References : http://marc.info/?l=linux-kernel&m=128892062917641&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22912
Subject : spi_lm70llp module crash on unload (2.6.37-rc1)
Submitter : Randy Dunlap <randy.dunlap@oracle.com>
Date : 2010-11-05 0:16 (45 days old)
Message-ID : <20101104171620.00d8c95d.randy.dunlap@oracle.com>
References : http://marc.info/?l=linux-kernel&m=128891627913647&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22882
Subject : (2.6.37-rc1) amd64-agp module crashed on second load
Submitter : Randy Dunlap <randy.dunlap@oracle.com>
Date : 2010-11-05 0:13 (45 days old)
Message-ID : <20101104171333.fea1f498.randy.dunlap@oracle.com>
References : http://marc.info/?l=linux-kernel&m=128891605213447&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22812
Subject : kernel oops on 2.6.37-rc1
Submitter : Andrew <atswartz@gmail.com>
Date : 2010-11-12 16:05 (38 days old)
First-Bad-Commit: http://git.kernel.org/linus/a68c439b1966c91f0ef474e2bf275d6792312726
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22642
Subject : 2.6.37-rc1: Disk takes 10 seconds to resume - MacBook2,1
Submitter : Tobias <devnull@plzk.org>
Date : 2010-11-10 19:33 (40 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22562
Subject : Regression in 2.6.37-rc1 - logs spammed with "unable to enumerate USB port" - bisected to commit 3df7169e
Submitter : Larry Finger <Larry.Finger@lwfinger.net>
Date : 2010-11-02 22:32 (48 days old)
First-Bad-Commit: http://git.kernel.org/linus/3df7169e73fc1d71a39cffeacc969f6840cdf52b
Message-ID : <4CD09166.4060202@lwfinger.net>
References : http://marc.info/?l=linux-kernel&m=128873713207906&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22542
Subject : [2.6.37-rc1] drm:i195 errors
Submitter : Paul Rolland <rol@witbe.net>
Date : 2010-11-02 14:58 (48 days old)
Message-ID : <20101102155813.09cb2c6e@tux.DEF.witbe.net>
References : http://marc.info/?l=linux-kernel&m=128870991628970&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22472
Subject : vga_switcheroo fails to switch from intel to ati
Submitter : Radu Andries <admiral0@tuxfamily.org>
Date : 2010-11-08 16:46 (42 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24602
Subject : modprobe bttv crashes system
Submitter : Sergej Pupykin <pupykin.s@gmail.com>
Date : 2010-12-09 21:48 (11 days old)
References : https://bugzilla.kernel.org/show_bug.cgi?id=24142
Patch : https://patchwork.kernel.org/patch/414671/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24462
Subject : r600: spread spectrum: flickering screen (bisected)
Submitter : Luca Tettamanti <kronos.it@gmail.com>
Date : 2010-12-08 16:18 (12 days old)
First-Bad-Commit: http://git.kernel.org/linus/ba032a58d1f320039e7850fb6e8651695c1aa571
Handled-By : Alex Deucher <alexdeucher@gmail.com>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=39372
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22672
Subject : Regression in 2.6.37-rc1 for Intel 945 Graphics Adapter - bisected to commit e9e331a
Submitter : Larry Finger <Larry.Finger@lwfinger.net>
Date : 2010-11-11 01:56 (39 days old)
References : https://bugs.freedesktop.org/show_bug.cgi?id=31803
http://marc.info/?l=linux-kernel&m=128944001311444&w=2
http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg02235.html
Patch : https://patchwork.kernel.org/patch/359472/
https://patchwork.kernel.org/patch/359502/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22662
Subject : divide error in select_task_rq_fair()
Submitter : Myron Stowe <myron.stowe@hp.com>
Date : 2010-11-10 23:58 (40 days old)
Patch : http://lkml.org/lkml/2010/11/13/176
http://lkml.org/lkml/2010/11/13/181
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.36,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=21782
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* Wireless channel stuck to -1 on mon0 (fix patch submission)
From: CalimeroTeknik @ 2010-12-19 11:11 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 4465 bytes --]
[1.] One line summary of the problem:
I can't change the channel of mon0 which is stuck to -1
[2.] Full description of the problem/report:
iwconfig mon0 channel 10 gives no error but the channel stays to -1
[3.] Keywords (i.e., modules, networking, kernel):
Wifi modules used :
iwlagn 336809 0
iwlcore 89975 1 iwlagn
mac80211 199020 2 iwlagn,iwlcore
cfg80211 139093 3 iwlagn,iwlcore,mac80211
[4.] Kernel information
[4.1.] Kernel version (from /proc/version):
Linux version 2.6.37-rc6-mainline (root@m50vn) (gcc version 4.5.2 (GCC)
) #1 SMP PREEMPT Sat Dec 18 15:50:20 CET 2010
nota bene : compiled in *fake*root.
[4.2.] Kernel .config file:
attached.
[5.] Most recent kernel version which did not have the bug:
It worked on 2.6.33 and didn't work on 2.6.36
[6.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
None.
[7.] A small shell script or example program which triggers the
problem (if possible)
airmon-ng start wlan0
airodump-ng --channel 1 mon0
You'll notice that despite any attempt of changing the channel, it stays
to -1.
[8.] Environment
[8.1.] Software (add the output of the ver_linux script here)
[8.2.] Processor information (from /proc/cpuinfo):
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz
[8.3.] Module information (from /proc/modules):
iwlagn 336809 0 - Live 0xffffffffa0317000
iwlcore 89975 1 iwlagn, Live 0xffffffffa01a2000
mac80211 199020 2 iwlagn,iwlcore, Live 0xffffffffa02c6000
cfg80211 139093 3 iwlagn,iwlcore,mac80211, Live 0xffffffffa01c4000
[8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
attached.
[8.5.] PCI information ('lspci -vvv' as root)
03:00.0 Network controller: Intel Corporation Wireless WiFi Link 5100
Subsystem: Intel Corporation PRO/Wireless 5100AGN Network Connection
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 50
Region 0: Memory at fdffe000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 41c1
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
<512ns, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+
TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
Latency L0 <128ns, L1 <32us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain-
CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 00-21-5d-ff-ff-9a-71-9c
Kernel driver in use: iwlagn
Kernel modules: iwlagn
complete lspci -vvv attached.
[X] : Patch proposal
This patch is *very* small and corrects the bug, so I think it could be
included in final 2.6.37.
http://patches.aircrack-ng.org/channel-negative-one-maxim.patch
Thanks for reading, and keep up the good work !
[-- Attachment #2: cpuinfo --]
[-- Type: text/plain, Size: 1534 bytes --]
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz
stepping : 6
cpu MHz : 2394.094
cache size : 3072 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm dts tpr_shadow vnmi flexpriority
bogomips : 4790.69
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz
stepping : 6
cpu MHz : 2394.094
cache size : 3072 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm dts tpr_shadow vnmi flexpriority
bogomips : 4790.10
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
[-- Attachment #3: iomem --]
[-- Type: text/plain, Size: 2719 bytes --]
00000000-0000ffff : reserved
00010000-0009ebff : System RAM
0009ec00-0009ffff : reserved
000a0000-000bffff : PCI Bus 0000:00
000c0000-000cffff : pnp 00:0f
000d0000-000dffff : PCI Bus 0000:00
000e1000-000fffff : reserved
00100000-bff7ffff : System RAM
01000000-013a9e5e : Kernel code
013a9e5f-01594837 : Kernel data
0161b000-017c39c7 : Kernel bss
bff80000-bff8efff : ACPI Tables
bff8f000-bffdffff : ACPI Non-volatile Storage
bffe0000-bfffffff : reserved
c0000000-ffffffff : PCI Bus 0000:00
d0000000-dfffffff : PCI Bus 0000:01
d0000000-dfffffff : 0000:01:00.0
e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
e0000000-efffffff : pnp 00:0e
f6000000-f8efffff : PCI Bus 0000:04
f8f00000-f8ffffff : PCI Bus 0000:08
f8fe0000-f8feffff : 0000:08:00.0
f8fe0000-f8feffff : r8169
f8fff000-f8ffffff : 0000:08:00.0
f8fff000-f8ffffff : r8169
f9ff8000-f9ffbfff : 0000:00:1b.0
f9ff8000-f9ffbfff : ICH HD audio
f9ffec00-f9ffecff : pnp 00:08
f9fff000-f9fff7ff : 0000:00:1f.2
f9fff000-f9fff7ff : ahci
f9fff800-f9fffbff : 0000:00:1d.7
f9fff800-f9fffbff : ehci_hcd
f9fffc00-f9ffffff : 0000:00:1a.7
f9fffc00-f9ffffff : ehci_hcd
fa000000-fdefffff : PCI Bus 0000:01
fa000000-fbffffff : 0000:01:00.0
fb000000-fbdfffff : vesafb
fc000000-fcffffff : 0000:01:00.0
fc000000-fcffffff : nvidia
fde80000-fdefffff : 0000:01:00.0
fdf00000-fdffffff : PCI Bus 0000:03
fdffe000-fdffffff : 0000:03:00.0
fdffe000-fdffffff : iwlagn
fe000000-fe9fffff : PCI Bus 0000:04
fea00000-feafffff : PCI Bus 0000:08
feaf0000-feafffff : 0000:08:00.0
feb00000-febfffff : PCI Bus 0000:09
febfe800-febfe8ff : 0000:09:01.3
febfec00-febfecff : 0000:09:01.2
febff400-febff4ff : 0000:09:01.1
febff400-febff4ff : mmc0
febff800-febfffff : 0000:09:01.0
febff800-febfffff : firewire_ohci
fec00000-fec003ff : IOAPIC 0
fec10000-fec17fff : pnp 00:0c
fec18000-fec1ffff : pnp 00:0c
fec20000-fec27fff : pnp 00:0c
fec28000-fec2ffff : pnp 00:0c
fec30000-fec37fff : pnp 00:0c
fec38000-fec3ffff : pnp 00:0c
fed00000-fed003ff : HPET 0
fed10000-fed19fff : pnp 00:01
fed1c000-fed1ffff : pnp 00:08
fed20000-fed3ffff : pnp 00:08
fed45000-fed89fff : pnp 00:08
fed90000-fed90fff : pnp 00:08
fed91000-fed91fff : pnp 00:08
fed92000-fed92fff : pnp 00:08
fed93000-fed93fff : pnp 00:08
fee00000-fee00fff : Local APIC
fee00000-fee00fff : reserved
fee00000-fee00fff : pnp 00:0c
ff700000-ff8fffff : PCI Bus 0000:06
ff900000-ffafffff : PCI Bus 0000:06
ffb00000-ffffffff : reserved
ffb00000-ffbfffff : pnp 00:08
ffc00000-ffdfffff : pnp 00:0b
fff00000-ffffffff : pnp 00:08
100000000-13fffffff : System RAM
[-- Attachment #4: ioports --]
[-- Type: text/plain, Size: 1511 bytes --]
0000-0cf7 : PCI Bus 0000:00
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0062-0062 : EC data
0064-0064 : keyboard
0066-0066 : EC cmd
0070-0071 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0250-0253 : pnp 00:0c
0256-025f : pnp 00:0c
03c0-03df : vesafb
0400-041f : pnp 00:08
04d0-04d1 : pnp 00:08
0500-057f : pnp 00:08
0800-087f : pnp 00:08
0800-0803 : ACPI PM1a_EVT_BLK
0804-0805 : ACPI PM1a_CNT_BLK
0808-080b : ACPI PM_TMR
0810-0815 : ACPI CPU throttle
0820-082f : ACPI GPE0_BLK
0830-0833 : iTCO_wdt
0850-0850 : ACPI PM2_CNT_BLK
0860-087f : iTCO_wdt
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
a480-a49f : 0000:00:1f.2
a480-a49f : ahci
a800-a803 : 0000:00:1f.2
a800-a803 : ahci
a880-a887 : 0000:00:1f.2
a880-a887 : ahci
ac00-ac03 : 0000:00:1f.2
ac00-ac03 : ahci
b000-b007 : 0000:00:1f.2
b000-b007 : ahci
b080-b09f : 0000:00:1d.2
b080-b09f : uhci_hcd
b400-b41f : 0000:00:1d.1
b400-b41f : uhci_hcd
b480-b49f : 0000:00:1d.0
b480-b49f : uhci_hcd
b800-b81f : 0000:00:1a.2
b800-b81f : uhci_hcd
b880-b89f : 0000:00:1a.1
b880-b89f : uhci_hcd
bc00-bc1f : 0000:00:1a.0
bc00-bc1f : uhci_hcd
c000-cfff : PCI Bus 0000:01
cc00-cc7f : 0000:01:00.0
d000-dfff : PCI Bus 0000:04
e000-efff : PCI Bus 0000:08
e800-e8ff : 0000:08:00.0
e800-e8ff : r8169
f000-ffff : PCI Bus 0000:06
[-- Attachment #5: lspcivvv --]
[-- Type: text/plain, Size: 40498 bytes --]
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
Subsystem: ASUSTeK Computer Inc. Device 1897
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0a <?>
Kernel modules: intel-agp
00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port (rev 07) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: fa000000-fdefffff
Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [88] Subsystem: ASUSTeK Computer Inc. Device 1897
Capabilities: [80] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 4159
Capabilities: [a0] Express (v1) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #2, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <256ns, L1 <4us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise-
Slot #16, PowerLimit 75.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Off, PwrInd On, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet+ LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [140 v1] Root Complex Link
Desc: PortNumber=02 ComponentID=01 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=01 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed19000
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. Device 1897
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 4: I/O ports at bc00 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. Device 1897
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 21
Region 4: I/O ports at b880 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. Device 1897
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin D routed to IRQ 19
Region 4: I/O ports at b800 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. Device 1897
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin C routed to IRQ 18
Region 0: Memory at f9fffc00 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
Subsystem: ASUSTeK Computer Inc. Device 1893
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 49
Region 0: Memory at f9ff8000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 41b9
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE- FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=1 ArbSelect=Fixed TC/VC=80
Status: NegoPending- InProgress-
Capabilities: [130 v1] Root Complex Link
Desc: PortNumber=0f ComponentID=00 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) (prog-if 00 [Normal decode])
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v1) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 4161
Capabilities: [90] Subsystem: ASUSTeK Computer Inc. Device 1897
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc: PortNumber=01 ComponentID=00 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03) (prog-if 00 [Normal decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fdf00000-fdffffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v1) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #2, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 4169
Capabilities: [90] Subsystem: ASUSTeK Computer Inc. Device 1897
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc: PortNumber=02 ComponentID=00 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=04, subordinate=05, sec-latency=0
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: fe000000-fe9fffff
Prefetchable memory behind bridge: 00000000f6000000-00000000f8efffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v1) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #3, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
Slot #0, PowerLimit 10.000W; Interlock- NoCompl-
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 4171
Capabilities: [90] Subsystem: ASUSTeK Computer Inc. Device 1897
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc: PortNumber=03 ComponentID=00 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=06, subordinate=06, sec-latency=0
I/O behind bridge: 0000f000-0000ffff
Memory behind bridge: ff900000-ffafffff
Prefetchable memory behind bridge: 00000000ff700000-00000000ff8fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v1) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #4, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
Slot #0, PowerLimit 10.000W; Interlock- NoCompl-
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 4179
Capabilities: [90] Subsystem: ASUSTeK Computer Inc. Device 1897
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc: PortNumber=04 ComponentID=00 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03) (prog-if 00 [Normal decode])
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=07, subordinate=07, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v1) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #5, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 4181
Capabilities: [90] Subsystem: ASUSTeK Computer Inc. Device 1897
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc: PortNumber=05 ComponentID=00 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=08, subordinate=08, sec-latency=0
I/O behind bridge: 0000e000-0000efff
Memory behind bridge: fea00000-feafffff
Prefetchable memory behind bridge: 00000000f8f00000-00000000f8ffffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v1) Root Port (Slot-), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
ExtTag- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #6, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
LnkCtl: ASPM L0s Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 4189
Capabilities: [90] Subsystem: ASUSTeK Computer Inc. Device 1897
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed+ WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [180 v1] Root Complex Link
Desc: PortNumber=06 ComponentID=00 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. Device 1897
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 4: I/O ports at b480 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. Device 1897
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 4: I/O ports at b400 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. Device 1897
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin C routed to IRQ 18
Region 4: I/O ports at b080 [size=32]
Capabilities: [50] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. Device 1897
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 0: Memory at f9fff800 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) (prog-if 01 [Subtractive decode])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Bus: primary=00, secondary=09, subordinate=09, sec-latency=32
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: feb00000-febfffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Subsystem: ASUSTeK Computer Inc. Device 1897
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
Subsystem: ASUSTeK Computer Inc. Device 1897
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
Kernel modules: iTCO_wdt
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03) (prog-if 01 [AHCI 1.0])
Subsystem: ASUSTeK Computer Inc. Device 1897
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 47
Region 0: I/O ports at b000 [size=8]
Region 1: I/O ports at ac00 [size=4]
Region 2: I/O ports at a880 [size=8]
Region 3: I/O ports at a800 [size=4]
Region 4: I/O ports at a480 [size=32]
Region 5: Memory at f9fff000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] MSI: Enable+ Count=1/16 Maskable- 64bit-
Address: fee0300c Data: 4191
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004
Capabilities: [b0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ahci
Kernel modules: ahci
01:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9650M GT] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device 1912
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at d0000000 (64-bit, prefetchable) [size=256M]
Region 3: Memory at fa000000 (64-bit, non-prefetchable) [size=32M]
Region 5: I/O ports at cc00 [size=128]
[virtual] Expansion ROM at fde80000 [disabled] [size=512K]
Capabilities: [60] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [78] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <4us
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 <256ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 128 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [b4] Vendor Specific Information: Len=14 <?>
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [128 v1] Power Budgeting <?>
Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
Kernel driver in use: nvidia
Kernel modules: nvidia, nouveau, nvidiafb
03:00.0 Network controller: Intel Corporation Wireless WiFi Link 5100
Subsystem: Intel Corporation PRO/Wireless 5100AGN Network Connection
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 50
Region 0: Memory at fdffe000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 41c1
Capabilities: [e0] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <128ns, L1 <32us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140 v1] Device Serial Number 00-21-5d-ff-ff-9a-71-9c
Kernel driver in use: iwlagn
Kernel modules: iwlagn
08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
Subsystem: ASUSTeK Computer Inc. U6V laptop
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 48
Region 0: I/O ports at e800 [size=256]
Region 2: Memory at f8fff000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at f8fe0000 (64-bit, prefetchable) [size=64K]
Expansion ROM at feaf0000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/2 Maskable- 64bit+
Address: 00000000fee0300c Data: 4199
Capabilities: [70] Express (v1) Endpoint, MSI 01
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <8us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM L0s Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [b0] MSI-X: Enable- Count=2 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data
Unknown small resource type 00, will not decode more.
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr+ BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 12-00-59-14-68-4c-e0-00
Kernel driver in use: r8169
Kernel modules: r8169
09:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. Device 1897
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (500ns min, 1000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at febff800 (32-bit, non-prefetchable) [size=2K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME+
Kernel driver in use: firewire_ohci
Kernel modules: firewire-ohci
09:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22)
Subsystem: ASUSTeK Computer Inc. Device 1897
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 32 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory at febff400 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-
Kernel driver in use: sdhci-pci
Kernel modules: sdhci-pci
09:01.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12)
Subsystem: ASUSTeK Computer Inc. Device 1897
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 32 bytes
Interrupt: pin B routed to IRQ 5
Region 0: Memory at febfec00 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-
09:01.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12)
Subsystem: ASUSTeK Computer Inc. Device 1897
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64, Cache Line Size: 32 bytes
Interrupt: pin B routed to IRQ 5
Region 0: Memory at febfe800 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=2 PME-
[-- Attachment #6: modules --]
[-- Type: text/plain, Size: 4272 bytes --]
fuse 64800 3 - Live 0xffffffffa03e0000
nvidia 10081598 40 - Live 0xffffffffa04db000 (P)
ipv6 279934 10 - Live 0xffffffffa0494000
pktgen 37433 0 - Live 0xffffffffa0484000
rfcomm 34042 4 - Live 0xffffffffa0473000
sco 8860 2 - Live 0xffffffffa046a000
bnep 8886 2 - Live 0xffffffffa0461000
l2cap 43033 16 rfcomm,bnep, Live 0xffffffffa044f000
crc16 1297 1 l2cap, Live 0xffffffffa0449000
btusb 11609 2 - Live 0xffffffffa0425000
bluetooth 53586 9 rfcomm,sco,bnep,l2cap,btusb, Live 0xffffffffa03d0000
snd_seq_dummy 1431 0 - Live 0xffffffffa0298000
arc4 1378 2 - Live 0xffffffffa01c1000
snd_seq_oss 29080 0 - Live 0xffffffffa03c6000
snd_seq_midi_event 5468 1 snd_seq_oss, Live 0xffffffffa0176000
snd_seq 50370 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event, Live 0xffffffffa03b7000
snd_seq_device 5329 3 snd_seq_dummy,snd_seq_oss,snd_seq, Live 0xffffffffa0107000
ecb 2041 2 - Live 0xffffffffa00f2000
snd_pcm_oss 39477 0 - Live 0xffffffffa0252000
snd_mixer_oss 17650 1 snd_pcm_oss, Live 0xffffffffa017d000
snd_hda_codec_hdmi 22545 1 - Live 0xffffffffa0168000
snd_hda_codec_realtek 295349 1 - Live 0xffffffffa036c000
iwlagn 336809 0 - Live 0xffffffffa0317000
snd_hda_intel 21997 4 - Live 0xffffffffa030a000
uvcvideo 61269 0 - Live 0xffffffffa02f9000
snd_hda_codec 74336 3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel, Live 0xffffffffa02ab000
videodev 65182 1 uvcvideo, Live 0xffffffffa0286000
joydev 10151 0 - Live 0xffffffffa0231000
snd_hwdep 6142 1 snd_hda_codec, Live 0xffffffffa01f6000
v4l1_compat 15898 2 uvcvideo,videodev, Live 0xffffffffa0204000
snd_pcm 72305 4 snd_pcm_oss,snd_hda_intel,snd_hda_codec, Live 0xffffffffa020d000
v4l2_compat_ioctl32 10212 1 videodev, Live 0xffffffffa01ef000
snd_timer 19425 3 snd_seq,snd_pcm, Live 0xffffffffa01e8000
i2c_core 18950 2 nvidia,videodev, Live 0xffffffffa01ba000
iwlcore 89975 1 iwlagn, Live 0xffffffffa01a2000
asus_laptop 15260 0 - Live 0xffffffffa0170000
snd 58330 18 snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer, Live 0xffffffffa0157000
sr_mod 15338 0 - Live 0xffffffffa011f000
mac80211 199020 2 iwlagn,iwlcore, Live 0xffffffffa02c6000
cdrom 36107 1 sr_mod, Live 0xffffffffa012a000
soundcore 6033 1 snd, Live 0xffffffffa00bd000
snd_page_alloc 7281 2 snd_hda_intel,snd_pcm, Live 0xffffffffa00ae000
sdhci_pci 7310 0 - Live 0xffffffffa029d000
psmouse 53125 0 - Live 0xffffffffa0235000
mmc_block 10038 0 - Live 0xffffffffa022c000
sdhci 17094 1 sdhci_pci, Live 0xffffffffa0221000
serio_raw 4582 0 - Live 0xffffffffa0209000
pcspkr 1819 0 - Live 0xffffffffa01f9000
sparse_keymap 2872 1 asus_laptop, Live 0xffffffffa01f3000
cfg80211 139093 3 iwlagn,iwlcore,mac80211, Live 0xffffffffa01c4000
mmc_core 62154 2 mmc_block,sdhci, Live 0xffffffffa0190000
video 11843 0 - Live 0xffffffffa0187000
button 4834 0 - Live 0xffffffffa0179000
uhci_hcd 22214 0 - Live 0xffffffffa0142000
intel_agp 10488 0 - Live 0xffffffffa00fa000
evdev 9033 7 - Live 0xffffffffa00eb000
rfkill 16042 4 bluetooth,asus_laptop,cfg80211, Live 0xffffffffa00d8000
ehci_hcd 37523 0 - Live 0xffffffffa0136000
r8169 36174 0 - Live 0xffffffffa00c8000
sg 25908 0 - Live 0xffffffffa0071000
firewire_ohci 26873 0 - Live 0xffffffffa02a2000
mii 3826 1 r8169, Live 0xffffffffa0046000
usbcore 138568 5 btusb,uvcvideo,uhci_hcd,ehci_hcd, Live 0xffffffffa0262000
intel_gtt 15151 1 intel_agp, Live 0xffffffffa00de000
processor 25185 2 - Live 0xffffffffa00a5000
thermal 7842 0 - Live 0xffffffffa0069000
iTCO_wdt 10893 0 - Live 0xffffffffa0125000
firewire_core 49846 1 firewire_ohci, Live 0xffffffffa0110000
iTCO_vendor_support 1801 1 iTCO_wdt, Live 0xffffffffa010a000
output 1972 1 video, Live 0xffffffffa0104000
crc_itu_t 1297 1 firewire_core, Live 0xffffffffa00fe000
battery 10263 0 - Live 0xffffffffa00f5000
ac 3169 0 - Live 0xffffffffa00ef000
tpm_tis 8056 0 - Live 0xffffffffa00e7000
tpm 11245 1 tpm_tis, Live 0xffffffffa00d3000
tpm_bios 5729 1 tpm, Live 0xffffffffa006d000
sd_mod 26992 2 - Live 0xffffffffa003d000
ahci 20353 1 - Live 0xffffffffa00c1000
libahci 17936 1 ahci, Live 0xffffffffa00b6000
libata 168820 2 ahci,libahci, Live 0xffffffffa0079000
scsi_mod 125462 4 sr_mod,sg,sd_mod,libata, Live 0xffffffffa0048000
reiserfs 237988 1 - Live 0xffffffffa0000000
[-- Attachment #7: config.gz --]
[-- Type: application/gzip, Size: 29394 bytes --]
^ permalink raw reply
* Re: [linux-pm] subtle pm_runtime_put_sync race and sdio functions
From: Rafael J. Wysocki @ 2010-12-19 10:22 UTC (permalink / raw)
To: Ohad Ben-Cohen, Alan Stern
Cc: linux-pm, Johannes Berg, linux-wireless, linux-mmc, Ido Yariv,
Kevin Hilman
In-Reply-To: <201012182347.08635.rjw@sisk.pl>
On Saturday, December 18, 2010, Rafael J. Wysocki wrote:
> On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
> > On Sat, Dec 18, 2010 at 5:07 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > > On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
> > >> On Sat, Dec 11, 2010 at 4:50 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> > >> >> Think of a device which you have no way to reset other than powering
> > >> >> it down and up again.
> > >> >>
> > >> >> If that device is managed by runtime PM, the only way to do that is by
> > >> >> using put_sync() followed by a get_sync(). Sure, if someone else
> > >> >> increased the usage_count of that device this won't work, but then of
> > >> >> course it means that the driver is not using runtime PM correctly.
> > >> >
> > >> > Not so. Even if a driver uses runtime PM correctly, there will still
> > >> > be times when someone else has increased the usage_count. This happens
> > >> > during probing and during system resume, for example.
> > >>
> > >> I'm aware of these two examples; normally we're good with them since
> > >> during probing we're not toggling the power, and during suspend/resume
> > >> the SDIO core is responsible for manipulating the power (and it does
> > >> so directly). Are there (or do you think there will be) additional
> > >> examples where this can happen ?
> > >>
> > >> But this leads me to a real problem which we have encountered.
> > >>
> > >> During system suspend, our driver is asked (by mac80211's suspend
> > >> handler) to power off its device. When this happens, the driver has no
> > >> idea that the system is suspending - regular driver code (responsible
> > >> to remove the wlan interface and stop the device) is being called.
> > >
> > > That's where the problem is. If there's a difference, from the driver's
> > > point of view, between suspend and some other operation, there should be a
> > > way to tell the driver what case it actually is dealing with.
> >
> > Yes, the problem will be solved if the driver would bypass the runtime
> > PM framework on system suspend. mac80211 obviously has this
> > information, and technically it's very easy to let the driver know
> > about it.
> >
> > But the difference between suspend and normal operation is really
> > artificial: in both cases mac80211 just asks the driver to power its
> > device down, and the end result is exactly the same (a GPIO line of
> > the device is de-asserted in our case). The difference between these
> > two scenarios
> > exist only because runtime PM is effectively disabled during system
> > suspend, and therefore the driver has to look for an alternative way
> > to power down the device.
>
> That's not correct, sorry.
>
> There is a bug and the bug is that you use the runtime PM to power down
> the device in every situation, although you obviously shouldn't do that
> (e.g. because it may be disabled by user space or it _is_ disabled by
> the PM core during system suspend).
>
> > > BTW, what would you do in that case if the runtime PM of the device were
> > > disabled by user space by writing "on" to the device's
> > > /sys/devices/.../power/control file?
> >
> > That's a good point.
> >
> > Blocking runtime PM for this device is fatal since this particular
> > device has functionality tied up with its power control (no other way
> > to reset it).
> >
> > It might call for a device-specific dev_pm_info bit flag to prohibit this...
>
> No way.
That said, I think we may do something different that perhaps will make your
life somewhat easier.
Namely, if your driver doesn't implement any system suspend callbacks
(i.e. ->suspend(), ->resume(), ->freeze(), ->thaw() etc.) and it doesn't
want the analogous subsystem callbacks to be executed for the device, it will
make sense to flag the device as "runtime only", or something like this,
which make the PM core skip the device in dpm_suspend() etc.
In that case, if a device if flagged as "runtime only", we can avoid
calling pm_runtime_get_noirq() for it in dpm_prepare() and, analogously,
calling pm_runtime_put_sync() for it in dpm_complete(). However, we will have
to fail system suspend (or hibernation) if a "runtime only" device has the
power.runtime_auto flag unset.
So, I think we can add a "runtime only" flag working as described above.
I guess it will also help in the case I've been discussing with Kevin for some
time (i2c device using runtime PM used by an RTC in a semi-transparent
fashion).
Alan, what do you think?
Rafael
^ permalink raw reply
* Re: [PATCH 1/3] mac80211: fix initialization of skb->cb in ieee80211_subif_start_xmit
From: Helmut Schaa @ 2010-12-19 10:09 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville, johannes
In-Reply-To: <1292697050-25741-1-git-send-email-nbd@openwrt.org>
Am Samstag, 18. Dezember 2010 schrieb Felix Fietkau:
> The change 'mac80211: Fix BUG in pskb_expand_head when transmitting shared skbs'
> added a check for copying the skb if it's shared, however the tx info variable
> still points at the cb of the old skb
>
> Cc: Helmut Schaa <helmut.schaa@googlemail.com>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Ah, missed that. Thanks Felix.
Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
> ---
> net/mac80211/tx.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 898e864..7d78aca 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -1742,7 +1742,7 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
> {
> struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> struct ieee80211_local *local = sdata->local;
> - struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
> + struct ieee80211_tx_info *info;
> int ret = NETDEV_TX_BUSY, head_need;
> u16 ethertype, hdrlen, meshhdrlen = 0;
> __le16 fc;
> @@ -2033,6 +2033,7 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
> skb_set_network_header(skb, nh_pos);
> skb_set_transport_header(skb, h_pos);
>
> + info = IEEE80211_SKB_CB(skb);
> memset(info, 0, sizeof(*info));
>
> dev->trans_start = jiffies;
>
^ permalink raw reply
* Re: BUG: while bridging Ethernet and wireless device:
From: Tomas Winkler @ 2010-12-19 9:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-netdev, linux-wireless
In-Reply-To: <1292501797.3612.12.camel@jlt3.sipsolutions.net>
On Thu, Dec 16, 2010 at 2:16 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2010-12-16 at 14:11 +0200, Tomas Winkler wrote:
>
>> Dec 15 14:36:41 User-PC kernel: [175576.120452] kernel BUG at include/linux/skbuff.h:1178!
>
>> Dec 15 14:36:41 User-PC kernel: [175576.123193] EIP is at br_multicast_rcv+0xc95/0xe1c [bridge]
>
> So as I said to Tomas in private before -- it kinda looks like something
> here is not handling paged SKBs correctly? But I would imaging that
> causing more issues, unless there was a bug here that made bridging
> require more data in the skb header than we put in there right now -- it
> can end up being empty I believe.
>
> Thing is, I looked at the code and it seemed fine.
>
> johannes
>
opened bug https://bugzilla.kernel.org/show_bug.cgi?id=25202
>
^ permalink raw reply
* Re: [linux-pm] subtle pm_runtime_put_sync race and sdio functions
From: Ohad Ben-Cohen @ 2010-12-19 7:48 UTC (permalink / raw)
To: Rafael J. Wysocki, Alan Stern
Cc: linux-mmc, Linux-pm mailing list, Ido Yariv, linux-wireless,
Johannes Berg
In-Reply-To: <201012182347.08635.rjw@sisk.pl>
On Sun, Dec 19, 2010 at 12:47 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
>> On Sat, Dec 18, 2010 at 5:07 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> > On Saturday, December 18, 2010, Ohad Ben-Cohen wrote:
>> >> On Sat, Dec 11, 2010 at 4:50 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> >> >> Think of a device which you have no way to reset other than powering
>> >> >> it down and up again.
>> >> >>
>> >> >> If that device is managed by runtime PM, the only way to do that is by
>> >> >> using put_sync() followed by a get_sync(). Sure, if someone else
>> >> >> increased the usage_count of that device this won't work, but then of
>> >> >> course it means that the driver is not using runtime PM correctly.
>> >> >
>> >> > Not so. Even if a driver uses runtime PM correctly, there will still
>> >> > be times when someone else has increased the usage_count. This happens
>> >> > during probing and during system resume, for example.
>> >>
>> >> I'm aware of these two examples; normally we're good with them since
>> >> during probing we're not toggling the power, and during suspend/resume
>> >> the SDIO core is responsible for manipulating the power (and it does
>> >> so directly). Are there (or do you think there will be) additional
>> >> examples where this can happen ?
>> >>
>> >> But this leads me to a real problem which we have encountered.
>> >>
>> >> During system suspend, our driver is asked (by mac80211's suspend
>> >> handler) to power off its device. When this happens, the driver has no
>> >> idea that the system is suspending - regular driver code (responsible
>> >> to remove the wlan interface and stop the device) is being called.
>> >
>> > That's where the problem is. If there's a difference, from the driver's
>> > point of view, between suspend and some other operation, there should be a
>> > way to tell the driver what case it actually is dealing with.
>>
>> Yes, the problem will be solved if the driver would bypass the runtime
>> PM framework on system suspend. mac80211 obviously has this
>> information, and technically it's very easy to let the driver know
>> about it.
>>
>> But the difference between suspend and normal operation is really
>> artificial: in both cases mac80211 just asks the driver to power its
>> device down, and the end result is exactly the same (a GPIO line of
>> the device is de-asserted in our case). The difference between these
>> two scenarios
>> exist only because runtime PM is effectively disabled during system
>> suspend, and therefore the driver has to look for an alternative way
>> to power down the device.
>
> That's not correct, sorry.
>
> There is a bug and the bug is that you use the runtime PM to power down
> the device in every situation, although you obviously shouldn't do that
> (e.g. because it may be disabled by user space or it _is_ disabled by
> the PM core during system suspend).
That completely makes sense, and helps to precisely define the problem
and justify the solution.
We will continue to use runtime PM within the SDIO core, in order to
opportunistically power down the device (e.g. when a driver is not
loaded). In this case, it is perfectly OK if runtime PM is disabled,
since there is no functional difference if power is taken down or not
- it's purely about minimizing power consumption.
OTOH, within the wl12xx driver, where powering down the device is tied
to functionality (e.g. error recovery or just hard reset), and must be
carried out unconditionally, we will bypass runtime PM.
Rafael, Alan, thank you for your time and attention, it really helped.
Thanks,
Ohad.
^ permalink raw reply
* [PATCH 2/2] ath9k_htc: Fix unnecessary warnings on card removal
From: Sujith @ 2010-12-19 3:14 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: linville, linux-wireless, m.sujith
In-Reply-To: <1292664547-5474-1-git-send-email-rmanoharan@atheros.com>
Rajkumar Manoharan wrote:
> diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
> index fdf9d5f..d90838a 100644
> --- a/drivers/net/wireless/ath/ath9k/htc.h
> +++ b/drivers/net/wireless/ath/ath9k/htc.h
> @@ -339,7 +339,6 @@ void ath_htc_cancel_btcoex_work(struct ath9k_htc_priv *priv);
> #define OP_ASSOCIATED BIT(7)
> #define OP_ENABLE_BEACON BIT(8)
> #define OP_LED_DEINIT BIT(9)
> -#define OP_UNPLUGGED BIT(10)
> #define OP_BT_PRIORITY_DETECTED BIT(11)
> #define OP_BT_SCAN BIT(12)
You are leaving a hole here.
> @@ -1231,6 +1236,12 @@ static void ath9k_htc_stop(struct ieee80211_hw *hw)
> cancel_delayed_work_sync(&priv->ath9k_led_blink_work);
> ath9k_led_stop_brightness(priv);
>
> + if (ah->ah_flags & AH_UNPLUGGED) {
> + ath_dbg(common, ATH_DBG_ANY, "Device not present\n");
> + mutex_unlock(&priv->mutex);
> + return;
> + }
> +
This doesn't take of purging the TX queues in both the driver layer and HIF.
Also, in case of BT combo devices, the workqueue instances aren't canceled.
Instead of adding such checks throughout the driver and increasing code size,
we can just fix the warning to handle the unplugged case. It doesn't matter
if a few extra hardware calls are made, the device is no longer present anyway. :)
Sujith
^ permalink raw reply
* [PATCH 1/2] ath9k_hw: fix PA predistortion HT40 mask
From: Felix Fietkau @ 2010-12-18 23:31 UTC (permalink / raw)
To: linux-wireless
Cc: linville, lrodriguez, Felix Fietkau, Vasanthakumar Thiagarajan
The commit 'ath9k_hw: Disable PAPRD for rates with low Tx power' changed
the code that sets the PAPRD rate masks to use only either the HT20 mask
or the HT40 mask. This is wrong, as the hardware can still use HT20 rates
even when configured for HT40, and the operating channel mode does not
affect PAPRD operation.
The register for the HT40 rate mask is applied as a mask on top of the
other registers to selectively disable PAPRD for specific rates on HT40
packets only.
This patch changes the code back to the old behavior which matches the
intended use of these registers. While with current cards this should not
make any practical difference (according to Atheros, the HT20 and HT40
mask should always be equal), it is more correct that way, and maybe
the HT40 mask will be used for some rare corner cases in the future.
Cc: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 19 +++++++++++--------
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 2 +-
drivers/net/wireless/ath/ath9k/hw.h | 1 +
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index f80ec74..d7deae8 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -4762,6 +4762,7 @@ static void ath9k_hw_ar9300_set_txpower(struct ath_hw *ah,
struct ath_regulatory *regulatory = ath9k_hw_regulatory(ah);
struct ath_common *common = ath9k_hw_common(ah);
struct ar9300_eeprom *eep = &ah->eeprom.ar9300_eep;
+ struct ar9300_modal_eep_header *modal_hdr;
u8 targetPowerValT2[ar9300RateSize];
u8 target_power_val_t2_eep[ar9300RateSize];
unsigned int i = 0, paprd_scale_factor = 0;
@@ -4771,15 +4772,17 @@ static void ath9k_hw_ar9300_set_txpower(struct ath_hw *ah,
if (ah->eep_ops->get_eeprom(ah, EEP_PAPRD)) {
if (IS_CHAN_2GHZ(chan))
- ah->paprd_ratemask = (IS_CHAN_HT40(chan) ?
- le32_to_cpu(eep->modalHeader2G.papdRateMaskHt40) :
- le32_to_cpu(eep->modalHeader2G.papdRateMaskHt20))
- & AR9300_PAPRD_RATE_MASK;
+ modal_hdr = &eep->modalHeader2G;
else
- ah->paprd_ratemask = (IS_CHAN_HT40(chan) ?
- le32_to_cpu(eep->modalHeader5G.papdRateMaskHt40) :
- le32_to_cpu(eep->modalHeader5G.papdRateMaskHt20))
- & AR9300_PAPRD_RATE_MASK;
+ modal_hdr = &eep->modalHeader5G;
+
+ ah->paprd_ratemask =
+ le32_to_cpu(modal_hdr->papdRateMaskHt20) &
+ AR9300_PAPRD_RATE_MASK;
+
+ ah->paprd_ratemask_ht40 =
+ le32_to_cpu(modal_hdr->papdRateMaskHt40) &
+ AR9300_PAPRD_RATE_MASK;
paprd_scale_factor = ar9003_get_paprd_scale_factor(ah, chan);
min_pwridx = IS_CHAN_HT40(chan) ? ALL_TARGET_HT40_0_8_16 :
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_paprd.c b/drivers/net/wireless/ath/ath9k/ar9003_paprd.c
index 79554c5..356d2fd7 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_paprd.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_paprd.c
@@ -134,7 +134,7 @@ static int ar9003_paprd_setup_single_table(struct ath_hw *ah)
REG_RMW_FIELD(ah, AR_PHY_PAPRD_AM2PM, AR_PHY_PAPRD_AM2PM_MASK,
ah->paprd_ratemask);
REG_RMW_FIELD(ah, AR_PHY_PAPRD_HT40, AR_PHY_PAPRD_HT40_MASK,
- AR_PHY_PAPRD_HT40_MASK);
+ ah->paprd_ratemask_ht40);
for (i = 0; i < ah->caps.max_txchains; i++) {
REG_RMW_FIELD(ah, ctrl0[i],
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index b98053f..b8ffaa5 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -835,6 +835,7 @@ struct ath_hw {
unsigned int paprd_target_power;
unsigned int paprd_training_power;
unsigned int paprd_ratemask;
+ unsigned int paprd_ratemask_ht40;
bool paprd_table_write_done;
u32 paprd_gain_table_entries[PAPRD_GAIN_TABLE_ENTRIES];
u8 paprd_gain_table_index[PAPRD_GAIN_TABLE_ENTRIES];
--
1.7.3.2
^ permalink raw reply related
* [PATCH 2/2] ath9k: do not limit the chainmask to 1 for legacy mode
From: Felix Fietkau @ 2010-12-18 23:31 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez, Felix Fietkau
In-Reply-To: <1292715115-36506-1-git-send-email-nbd@openwrt.org>
Restricting the chainmask to 1 for legacy mode disables useful features
such as MRC, and it reduces the available transmit power.
I can't think of a good reason to do this in legacy mode, so let's just
get rid of that code.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 1 -
drivers/net/wireless/ath/ath9k/main.c | 32 ------------------------------
drivers/net/wireless/ath/ath9k/virtual.c | 1 -
3 files changed, 0 insertions(+), 34 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 9fd9519..2c31f51 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -675,7 +675,6 @@ void ath9k_deinit_device(struct ath_softc *sc);
void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw);
void ath9k_update_ichannel(struct ath_softc *sc, struct ieee80211_hw *hw,
struct ath9k_channel *ichan);
-void ath_update_chainmask(struct ath_softc *sc, int is_ht);
int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
struct ath9k_channel *hchan);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index cb53fbb..8a1691d 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -538,32 +538,6 @@ set_timer:
}
}
-/*
- * Update tx/rx chainmask. For legacy association,
- * hard code chainmask to 1x1, for 11n association, use
- * the chainmask configuration, for bt coexistence, use
- * the chainmask configuration even in legacy mode.
- */
-void ath_update_chainmask(struct ath_softc *sc, int is_ht)
-{
- struct ath_hw *ah = sc->sc_ah;
- struct ath_common *common = ath9k_hw_common(ah);
-
- if ((sc->sc_flags & SC_OP_OFFCHANNEL) || is_ht ||
- (ah->btcoex_hw.scheme != ATH_BTCOEX_CFG_NONE)) {
- common->tx_chainmask = ah->caps.tx_chainmask;
- common->rx_chainmask = ah->caps.rx_chainmask;
- } else {
- common->tx_chainmask = 1;
- common->rx_chainmask = 1;
- }
-
- ath_dbg(common, ATH_DBG_CONFIG,
- "tx chmask: %d, rx chmask: %d\n",
- common->tx_chainmask,
- common->rx_chainmask);
-}
-
static void ath_node_attach(struct ath_softc *sc, struct ieee80211_sta *sta)
{
struct ath_node *an;
@@ -1679,8 +1653,6 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
/* XXX: remove me eventualy */
ath9k_update_ichannel(sc, hw, &sc->sc_ah->channels[pos]);
- ath_update_chainmask(sc, conf_is_ht(conf));
-
/* update survey stats for the old channel before switching */
spin_lock_irqsave(&common->cc_lock, flags);
ath_update_survey_stats(sc);
@@ -1912,10 +1884,6 @@ static void ath9k_bss_info_changed(struct ieee80211_hw *hw,
/* Set aggregation protection mode parameters */
sc->config.ath_aggr_prot = 0;
- /* Only legacy IBSS for now */
- if (vif->type == NL80211_IFTYPE_ADHOC)
- ath_update_chainmask(sc, 0);
-
ath_dbg(common, ATH_DBG_CONFIG, "BSSID: %pM aid: 0x%x\n",
common->curbssid, common->curaid);
diff --git a/drivers/net/wireless/ath/ath9k/virtual.c b/drivers/net/wireless/ath/ath9k/virtual.c
index fbfbc82..2dc7095 100644
--- a/drivers/net/wireless/ath/ath9k/virtual.c
+++ b/drivers/net/wireless/ath/ath9k/virtual.c
@@ -288,7 +288,6 @@ void ath9k_wiphy_chan_work(struct work_struct *work)
/* sync hw configuration for hw code */
common->hw = aphy->hw;
- ath_update_chainmask(sc, sc->chan_is_ht);
if (ath_set_channel(sc, aphy->hw,
&sc->sc_ah->channels[sc->chan_idx]) < 0) {
printk(KERN_DEBUG "ath9k: Failed to set channel for new "
--
1.7.3.2
^ permalink raw reply related
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