* [PATCH] cfg80211: fix a wrong ifdef
From: Johannes Berg @ 2009-10-02 8:38 UTC (permalink / raw)
To: John Linville; +Cc: Holger Schurig, linux-wireless
The wext refactoring replaced all
#ifdef CONFIG_WIRELESS_EXT
in cfg80211 with
#ifdef CONFIG_CFG80211_WEXT
but one -- that one needs fixing now.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
Might be worth rolling it into the refactor patch.
net/wireless/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- wireless-testing.orig/net/wireless/core.c 2009-10-02 10:34:13.000000000 +0200
+++ wireless-testing/net/wireless/core.c 2009-10-02 10:34:24.000000000 +0200
@@ -669,7 +669,7 @@ static int cfg80211_netdev_notifier_call
wdev->netdev = dev;
wdev->sme_state = CFG80211_SME_IDLE;
mutex_unlock(&rdev->devlist_mtx);
-#ifdef CONFIG_WIRELESS_EXT
+#ifdef CONFIG_CFG80211_WEXT
wdev->wext.default_key = -1;
wdev->wext.default_mgmt_key = -1;
wdev->wext.connect.auth_type = NL80211_AUTHTYPE_AUTOMATIC;
^ permalink raw reply
* Re: 2.6.32-rc1-git2: Reported regressions from 2.6.31
From: Jaswinder Singh Rajput @ 2009-10-02 7:38 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Linus Torvalds, Natalie Protasevich, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <9UCePxij8cB.A.VCG.-3SxKB@chimera>
Hello Rafael,
On Thu, 2009-10-01 at 21:26 +0200, Rafael J. Wysocki wrote:
> [Notes:
>
> * Here's the first summary report of known regressions from 2.6.31. There's
> not too many of them at the moment, which is nice.
>
> * We're still getting quite a number of reports of regressions from 2.6.30 and
> it's been that way since 2.6.31 was released. For details please see the
> summary report of regressions 2.6.30 -> 2.6.31 that will follow shortly.]
>
> This message contains a list of some regressions from 2.6.31, for which there
> are no fixes in the mainline I know of. If any of them have been fixed already,
> please let me know.
>
> If you know of any other unresolved regressions from 2.6.31, please let me know
> either and I'll add them to the list. Also, please let me 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
> ----------------------------------------
> 2009-10-02 22 15 9
>
>
> Unresolved regressions
> ----------------------
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14299
> Subject : oops in wireless, iwl3945 related?
> Submitter : Pavel Machek <pavel@ucw.cz>
> Date : 2009-09-29 17:12 (3 days old)
> References : http://marc.info/?l=linux-kernel&m=125424439725743&w=4
>
If you add one more entry say "Suspected commit :" then it will be great
and will solve regressions much faster. You can request submitter to
submit 'suspected commit' by git bisect and also specify git bisect
links like : (for more information about git bisect check
http://kerneltrap.org/node/11753)
Thanks,
--
JSR
^ permalink raw reply
* Re: Linux-2.6.32-rc1/2] wext refactor needs wpasupplicant 0.7.0+?
From: Holger Schurig @ 2009-10-02 7:10 UTC (permalink / raw)
To: Sedat Dilek; +Cc: Johannes Berg, wireless
In-Reply-To: <2d0a357f0910011344u4306ecf6ha11410b0f5ed62e3@mail.gmail.com>
In both logs you have
1254429476.088527: ctrl_iface bind(PF_UNIX) failed: Address already in use
1254429476.088543: ctrl_iface exists and seems to be in use - cannot override it
1254429476.088548: Delete '/var/run/wpa_supplicant/wlan0' manually if it is not used anymore
are you sure that no other wpa_supplicant did
run when you made the logs?
If yes, then just remove the file and re-run wpa_supplicant.
Be sure to run it as "root".
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: BUG: "wext: refactor" broke compilation
From: Holger Schurig @ 2009-10-02 7:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1254431687.3959.43.camel@johannes.local>
> Did you send a patch to change that to CONFIG_CFG80211_WEXT, or do I
> need to?
No, I had to go to a customer (I'm "jack-in-all-trades"), so
I didn't have time.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH] ar9170usb: LEDs are confused
From: Malte Gell @ 2009-10-02 6:52 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Luis R. Rodriguez, linville
In-Reply-To: <200910011654.10963.chunkeey@googlemail.com>
Christian Lamparter <chunkeey@googlemail.com> wrote
> On 2009-10-01 06:32 AM, Malte Gell wrote:
> >I first noticed the LEDs are confused,
>
> no, the LED colors is not _confused_ at all.
> This is simply different on.... well, you know: on a per-device base!
Yeah, I guessed it. But, guess... i am not a real hacker so my dirty little
patch just is a trial by combat solution for my own boy ;-)
> For example: The Netgear uses a single bi-color LED for their WNDA3100
> stick. It glows blue or/and orange depending on the selected band and
> current operation mode and state...
The Netgear (WN?) 111 even only has one blue LED as far as I know. And
Neatgear sticks look ugly.
> FYI: you can assign the LEDs under "/sys/class/leds/" with a different
> tigger without messing with the kernel source... An up-to-date README can
> be found in the kernel's documentation directory:
> Documentation/leds-class.txt , or you can look it up online as well:
> http://www.mjmwired.net/kernel/Documentation/leds-class.txt (from 2.6.31)
Very good to know. This needs a udev rule, right?
But, what about a USB ID based decission in the driver how to handle the LED?
I have a Fritz WLAN N, USB ID: 057c:8401
Regards
Malte
^ permalink raw reply
* [135/136] iwlwifi: traverse linklist to find the valid OTP block
From: Greg KH @ 2009-10-02 1:18 UTC (permalink / raw)
To: linux-kernel, stable, Greg KH
Cc: stable-review, torvalds, akpm, alan,
linux-wireless@vger.kernel.org, Wey-Yi Guy, Reinette Chatre,
John W. Linville
In-Reply-To: <20091002012911.GA18542@kroah.com>
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
commit 415e49936b4b29b34c2fb561eeab867d41fc43a6 upstream.
For devices using OTP memory, EEPROM image can start from
any one of the OTP blocks. If shadow RAM is disabled, we need to
traverse link list to find the last valid block, then start the EEPROM
image reading.
If OTP is not full, the valid block is the block _before_ the last block
on the link list; the last block on the link list is the empty block
ready for next OTP refresh/update.
If OTP is full, then the last block is the valid block to be used for
configure the device.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/wireless/iwlwifi/iwl-1000.c | 4
drivers/net/wireless/iwlwifi/iwl-6000.c | 20 ++-
drivers/net/wireless/iwlwifi/iwl-core.h | 4
drivers/net/wireless/iwlwifi/iwl-dev.h | 12 +
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 185 ++++++++++++++++++++++++------
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 10 +
6 files changed, 192 insertions(+), 43 deletions(-)
--- a/drivers/net/wireless/iwlwifi/iwl-1000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-1000.c
@@ -62,12 +62,14 @@ struct iwl_cfg iwl1000_bgn_cfg = {
.ucode_api_min = IWL1000_UCODE_API_MIN,
.sku = IWL_SKU_G|IWL_SKU_N,
.ops = &iwl5000_ops,
- .eeprom_size = IWL_5000_EEPROM_IMG_SIZE,
+ .eeprom_size = OTP_LOW_IMAGE_SIZE,
.eeprom_ver = EEPROM_5000_EEPROM_VERSION,
.eeprom_calib_ver = EEPROM_5000_TX_POWER_VERSION,
.mod_params = &iwl50_mod_params,
.valid_tx_ant = ANT_A,
.valid_rx_ant = ANT_AB,
.need_pll_cfg = true,
+ .max_ll_items = OTP_MAX_LL_ITEMS_1000,
+ .shadow_ram_support = false,
};
--- a/drivers/net/wireless/iwlwifi/iwl-6000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-6000.c
@@ -82,13 +82,15 @@ struct iwl_cfg iwl6000_2ag_cfg = {
.ucode_api_min = IWL6000_UCODE_API_MIN,
.sku = IWL_SKU_A|IWL_SKU_G,
.ops = &iwl6000_ops,
- .eeprom_size = IWL_5000_EEPROM_IMG_SIZE,
+ .eeprom_size = OTP_LOW_IMAGE_SIZE,
.eeprom_ver = EEPROM_5000_EEPROM_VERSION,
.eeprom_calib_ver = EEPROM_5000_TX_POWER_VERSION,
.mod_params = &iwl50_mod_params,
.valid_tx_ant = ANT_BC,
.valid_rx_ant = ANT_BC,
.need_pll_cfg = false,
+ .max_ll_items = OTP_MAX_LL_ITEMS_6x00,
+ .shadow_ram_support = true,
};
struct iwl_cfg iwl6000_2agn_cfg = {
@@ -98,13 +100,15 @@ struct iwl_cfg iwl6000_2agn_cfg = {
.ucode_api_min = IWL6000_UCODE_API_MIN,
.sku = IWL_SKU_A|IWL_SKU_G|IWL_SKU_N,
.ops = &iwl6000_ops,
- .eeprom_size = IWL_5000_EEPROM_IMG_SIZE,
+ .eeprom_size = OTP_LOW_IMAGE_SIZE,
.eeprom_ver = EEPROM_5000_EEPROM_VERSION,
.eeprom_calib_ver = EEPROM_5000_TX_POWER_VERSION,
.mod_params = &iwl50_mod_params,
.valid_tx_ant = ANT_AB,
.valid_rx_ant = ANT_AB,
.need_pll_cfg = false,
+ .max_ll_items = OTP_MAX_LL_ITEMS_6x00,
+ .shadow_ram_support = true,
};
struct iwl_cfg iwl6050_2agn_cfg = {
@@ -114,13 +118,15 @@ struct iwl_cfg iwl6050_2agn_cfg = {
.ucode_api_min = IWL6050_UCODE_API_MIN,
.sku = IWL_SKU_A|IWL_SKU_G|IWL_SKU_N,
.ops = &iwl6000_ops,
- .eeprom_size = IWL_5000_EEPROM_IMG_SIZE,
+ .eeprom_size = OTP_LOW_IMAGE_SIZE,
.eeprom_ver = EEPROM_5000_EEPROM_VERSION,
.eeprom_calib_ver = EEPROM_5000_TX_POWER_VERSION,
.mod_params = &iwl50_mod_params,
.valid_tx_ant = ANT_AB,
.valid_rx_ant = ANT_AB,
.need_pll_cfg = false,
+ .max_ll_items = OTP_MAX_LL_ITEMS_6x00,
+ .shadow_ram_support = true,
};
struct iwl_cfg iwl6000_3agn_cfg = {
@@ -130,13 +136,15 @@ struct iwl_cfg iwl6000_3agn_cfg = {
.ucode_api_min = IWL6000_UCODE_API_MIN,
.sku = IWL_SKU_A|IWL_SKU_G|IWL_SKU_N,
.ops = &iwl6000_ops,
- .eeprom_size = IWL_5000_EEPROM_IMG_SIZE,
+ .eeprom_size = OTP_LOW_IMAGE_SIZE,
.eeprom_ver = EEPROM_5000_EEPROM_VERSION,
.eeprom_calib_ver = EEPROM_5000_TX_POWER_VERSION,
.mod_params = &iwl50_mod_params,
.valid_tx_ant = ANT_ABC,
.valid_rx_ant = ANT_ABC,
.need_pll_cfg = false,
+ .max_ll_items = OTP_MAX_LL_ITEMS_6x00,
+ .shadow_ram_support = true,
};
struct iwl_cfg iwl6050_3agn_cfg = {
@@ -146,13 +154,15 @@ struct iwl_cfg iwl6050_3agn_cfg = {
.ucode_api_min = IWL6050_UCODE_API_MIN,
.sku = IWL_SKU_A|IWL_SKU_G|IWL_SKU_N,
.ops = &iwl6000_ops,
- .eeprom_size = IWL_5000_EEPROM_IMG_SIZE,
+ .eeprom_size = OTP_LOW_IMAGE_SIZE,
.eeprom_ver = EEPROM_5000_EEPROM_VERSION,
.eeprom_calib_ver = EEPROM_5000_TX_POWER_VERSION,
.mod_params = &iwl50_mod_params,
.valid_tx_ant = ANT_ABC,
.valid_rx_ant = ANT_ABC,
.need_pll_cfg = false,
+ .max_ll_items = OTP_MAX_LL_ITEMS_6x00,
+ .shadow_ram_support = true,
};
MODULE_FIRMWARE(IWL6000_MODULE_FIRMWARE(IWL6000_UCODE_API_MAX));
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -207,6 +207,8 @@ struct iwl_mod_params {
* filename is constructed as fw_name_pre<api>.ucode.
* @ucode_api_max: Highest version of uCode API supported by driver.
* @ucode_api_min: Lowest version of uCode API supported by driver.
+ * @max_ll_items: max number of OTP blocks
+ * @shadow_ram_support: shadow support for OTP memory
*
* We enable the driver to be backward compatible wrt API version. The
* driver specifies which APIs it supports (with @ucode_api_max being the
@@ -243,6 +245,8 @@ struct iwl_cfg {
u8 valid_rx_ant;
bool need_pll_cfg;
bool use_isr_legacy;
+ const u16 max_ll_items;
+ const bool shadow_ram_support;
};
/***************************
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -835,6 +835,18 @@ enum iwl_nvm_type {
NVM_DEVICE_TYPE_OTP,
};
+/*
+ * Two types of OTP memory access modes
+ * IWL_OTP_ACCESS_ABSOLUTE - absolute address mode,
+ * based on physical memory addressing
+ * IWL_OTP_ACCESS_RELATIVE - relative address mode,
+ * based on logical memory addressing
+ */
+enum iwl_access_mode {
+ IWL_OTP_ACCESS_ABSOLUTE,
+ IWL_OTP_ACCESS_RELATIVE,
+};
+
/* interrupt statistics */
struct isr_statistics {
u32 hw;
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.c
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.c
@@ -152,6 +152,19 @@ int iwlcore_eeprom_verify_signature(stru
}
EXPORT_SYMBOL(iwlcore_eeprom_verify_signature);
+static void iwl_set_otp_access(struct iwl_priv *priv, enum iwl_access_mode mode)
+{
+ u32 otpgp;
+
+ otpgp = iwl_read32(priv, CSR_OTP_GP_REG);
+ if (mode == IWL_OTP_ACCESS_ABSOLUTE)
+ iwl_clear_bit(priv, CSR_OTP_GP_REG,
+ CSR_OTP_GP_REG_OTP_ACCESS_MODE);
+ else
+ iwl_set_bit(priv, CSR_OTP_GP_REG,
+ CSR_OTP_GP_REG_OTP_ACCESS_MODE);
+}
+
static int iwlcore_get_nvm_type(struct iwl_priv *priv)
{
u32 otpgp;
@@ -249,6 +262,124 @@ static int iwl_init_otp_access(struct iw
return ret;
}
+static int iwl_read_otp_word(struct iwl_priv *priv, u16 addr, u16 *eeprom_data)
+{
+ int ret = 0;
+ u32 r;
+ u32 otpgp;
+
+ _iwl_write32(priv, CSR_EEPROM_REG,
+ CSR_EEPROM_REG_MSK_ADDR & (addr << 1));
+ ret = iwl_poll_direct_bit(priv, CSR_EEPROM_REG,
+ CSR_EEPROM_REG_READ_VALID_MSK,
+ IWL_EEPROM_ACCESS_TIMEOUT);
+ if (ret < 0) {
+ IWL_ERR(priv, "Time out reading OTP[%d]\n", addr);
+ return ret;
+ }
+ r = _iwl_read_direct32(priv, CSR_EEPROM_REG);
+ /* check for ECC errors: */
+ otpgp = iwl_read32(priv, CSR_OTP_GP_REG);
+ if (otpgp & CSR_OTP_GP_REG_ECC_UNCORR_STATUS_MSK) {
+ /* stop in this case */
+ /* set the uncorrectable OTP ECC bit for acknowledgement */
+ iwl_set_bit(priv, CSR_OTP_GP_REG,
+ CSR_OTP_GP_REG_ECC_UNCORR_STATUS_MSK);
+ IWL_ERR(priv, "Uncorrectable OTP ECC error, abort OTP read\n");
+ return -EINVAL;
+ }
+ if (otpgp & CSR_OTP_GP_REG_ECC_CORR_STATUS_MSK) {
+ /* continue in this case */
+ /* set the correctable OTP ECC bit for acknowledgement */
+ iwl_set_bit(priv, CSR_OTP_GP_REG,
+ CSR_OTP_GP_REG_ECC_CORR_STATUS_MSK);
+ IWL_ERR(priv, "Correctable OTP ECC error, continue read\n");
+ }
+ *eeprom_data = le16_to_cpu((__force __le16)(r >> 16));
+ return 0;
+}
+
+/*
+ * iwl_is_otp_empty: check for empty OTP
+ */
+static bool iwl_is_otp_empty(struct iwl_priv *priv)
+{
+ u16 next_link_addr = 0, link_value;
+ bool is_empty = false;
+
+ /* locate the beginning of OTP link list */
+ if (!iwl_read_otp_word(priv, next_link_addr, &link_value)) {
+ if (!link_value) {
+ IWL_ERR(priv, "OTP is empty\n");
+ is_empty = true;
+ }
+ } else {
+ IWL_ERR(priv, "Unable to read first block of OTP list.\n");
+ is_empty = true;
+ }
+
+ return is_empty;
+}
+
+
+/*
+ * iwl_find_otp_image: find EEPROM image in OTP
+ * finding the OTP block that contains the EEPROM image.
+ * the last valid block on the link list (the block _before_ the last block)
+ * is the block we should read and used to configure the device.
+ * If all the available OTP blocks are full, the last block will be the block
+ * we should read and used to configure the device.
+ * only perform this operation if shadow RAM is disabled
+ */
+static int iwl_find_otp_image(struct iwl_priv *priv,
+ u16 *validblockaddr)
+{
+ u16 next_link_addr = 0, link_value = 0, valid_addr;
+ int ret = 0;
+ int usedblocks = 0;
+
+ /* set addressing mode to absolute to traverse the link list */
+ iwl_set_otp_access(priv, IWL_OTP_ACCESS_ABSOLUTE);
+
+ /* checking for empty OTP or error */
+ if (iwl_is_otp_empty(priv))
+ return -EINVAL;
+
+ /*
+ * start traverse link list
+ * until reach the max number of OTP blocks
+ * different devices have different number of OTP blocks
+ */
+ do {
+ /* save current valid block address
+ * check for more block on the link list
+ */
+ valid_addr = next_link_addr;
+ next_link_addr = link_value;
+ IWL_DEBUG_INFO(priv, "OTP blocks %d addr 0x%x\n",
+ usedblocks, next_link_addr);
+ if (iwl_read_otp_word(priv, next_link_addr, &link_value))
+ return -EINVAL;
+ if (!link_value) {
+ /*
+ * reach the end of link list,
+ * set address point to the starting address
+ * of the image
+ */
+ goto done;
+ }
+ /* more in the link list, continue */
+ usedblocks++;
+ } while (usedblocks < priv->cfg->max_ll_items);
+ /* OTP full, use last block */
+ IWL_DEBUG_INFO(priv, "OTP is full, use last block\n");
+done:
+ *validblockaddr = valid_addr;
+ /* skip first 2 bytes (link list pointer) */
+ *validblockaddr += 2;
+ return ret;
+}
+
/**
* iwl_eeprom_init - read EEPROM contents
*
@@ -263,14 +394,13 @@ int iwl_eeprom_init(struct iwl_priv *pri
int sz;
int ret;
u16 addr;
- u32 otpgp;
+ u16 validblockaddr = 0;
+ u16 cache_addr = 0;
priv->nvm_device_type = iwlcore_get_nvm_type(priv);
/* allocate eeprom */
- if (priv->nvm_device_type == NVM_DEVICE_TYPE_OTP)
- priv->cfg->eeprom_size =
- OTP_BLOCK_SIZE * OTP_LOWER_BLOCKS_TOTAL;
+ IWL_DEBUG_INFO(priv, "NVM size = %d\n", priv->cfg->eeprom_size);
sz = priv->cfg->eeprom_size;
priv->eeprom = kzalloc(sz, GFP_KERNEL);
if (!priv->eeprom) {
@@ -298,46 +428,31 @@ int iwl_eeprom_init(struct iwl_priv *pri
if (ret) {
IWL_ERR(priv, "Failed to initialize OTP access.\n");
ret = -ENOENT;
- goto err;
+ goto done;
}
_iwl_write32(priv, CSR_EEPROM_GP,
iwl_read32(priv, CSR_EEPROM_GP) &
~CSR_EEPROM_GP_IF_OWNER_MSK);
- /* clear */
- _iwl_write32(priv, CSR_OTP_GP_REG,
- iwl_read32(priv, CSR_OTP_GP_REG) |
+
+ iwl_set_bit(priv, CSR_OTP_GP_REG,
CSR_OTP_GP_REG_ECC_CORR_STATUS_MSK |
CSR_OTP_GP_REG_ECC_UNCORR_STATUS_MSK);
-
- for (addr = 0; addr < sz; addr += sizeof(u16)) {
- u32 r;
-
- _iwl_write32(priv, CSR_EEPROM_REG,
- CSR_EEPROM_REG_MSK_ADDR & (addr << 1));
-
- ret = iwl_poll_direct_bit(priv, CSR_EEPROM_REG,
- CSR_EEPROM_REG_READ_VALID_MSK,
- IWL_EEPROM_ACCESS_TIMEOUT);
- if (ret < 0) {
- IWL_ERR(priv, "Time out reading OTP[%d]\n", addr);
+ /* traversing the linked list if no shadow ram supported */
+ if (!priv->cfg->shadow_ram_support) {
+ if (iwl_find_otp_image(priv, &validblockaddr)) {
+ ret = -ENOENT;
goto done;
}
- r = _iwl_read_direct32(priv, CSR_EEPROM_REG);
- /* check for ECC errors: */
- otpgp = iwl_read32(priv, CSR_OTP_GP_REG);
- if (otpgp & CSR_OTP_GP_REG_ECC_UNCORR_STATUS_MSK) {
- /* stop in this case */
- IWL_ERR(priv, "Uncorrectable OTP ECC error, Abort OTP read\n");
+ }
+ for (addr = validblockaddr; addr < validblockaddr + sz;
+ addr += sizeof(u16)) {
+ u16 eeprom_data;
+
+ ret = iwl_read_otp_word(priv, addr, &eeprom_data);
+ if (ret)
goto done;
- }
- if (otpgp & CSR_OTP_GP_REG_ECC_CORR_STATUS_MSK) {
- /* continue in this case */
- _iwl_write32(priv, CSR_OTP_GP_REG,
- iwl_read32(priv, CSR_OTP_GP_REG) |
- CSR_OTP_GP_REG_ECC_CORR_STATUS_MSK);
- IWL_ERR(priv, "Correctable OTP ECC error, continue read\n");
- }
- e[addr / 2] = le16_to_cpu((__force __le16)(r >> 16));
+ e[cache_addr / 2] = eeprom_data;
+ cache_addr += sizeof(u16);
}
} else {
/* eeprom is an array of 16bit values */
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.h
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
@@ -180,8 +180,14 @@ struct iwl_eeprom_channel {
#define EEPROM_5050_EEPROM_VERSION (0x21E)
/* OTP */
-#define OTP_LOWER_BLOCKS_TOTAL (3)
-#define OTP_BLOCK_SIZE (0x400)
+/* lower blocks contain EEPROM image and calibration data */
+#define OTP_LOW_IMAGE_SIZE (2 * 512 * sizeof(u16)) /* 2 KB */
+/* high blocks contain PAPD data */
+#define OTP_HIGH_IMAGE_SIZE_6x00 (6 * 512 * sizeof(u16)) /* 6 KB */
+#define OTP_HIGH_IMAGE_SIZE_1000 (0x200 * sizeof(u16)) /* 1024 bytes */
+#define OTP_MAX_LL_ITEMS_1000 (3) /* OTP blocks for 1000 */
+#define OTP_MAX_LL_ITEMS_6x00 (4) /* OTP blocks for 6x00 */
+#define OTP_MAX_LL_ITEMS_6x50 (7) /* OTP blocks for 6x50 */
/* 2.4 GHz */
extern const u8 iwl_eeprom_band_1[14];
^ permalink raw reply
* [PATCH] compat-wireless: Fix the bleeding-edge version to build on 2.6.27
From: Larry Finger @ 2009-10-02 1:23 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless
When building the bleeding-edge compat-wireless for kernel 2.6.27,
several compilation errors were detected.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
Luis,
I checked these patches on 2.6.27 and 2.6.31, but not for the intermediate
releases.
Larry
---
Index: compat-wireless-2009-09-05/include/net/compat-2.6.28.h
===================================================================
--- compat-wireless-2009-09-05.orig/include/net/compat-2.6.28.h
+++ compat-wireless-2009-09-05/include/net/compat-2.6.28.h
@@ -149,6 +149,7 @@ static inline void skb_queue_splice_tail
struct module;
struct tracepoint;
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28))
struct tracepoint {
const char *name; /* Tracepoint name */
int state; /* State. */
@@ -159,6 +160,7 @@ struct tracepoint {
* align these on the structure size.
* Keep in sync with vmlinux.lds.h.
*/
+#endif
#ifndef DECLARE_TRACE
@@ -179,13 +181,17 @@ struct tracepoint {
return -ENOSYS; \
}
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28))
#define DEFINE_TRACE(name)
+#endif
#define EXPORT_TRACEPOINT_SYMBOL_GPL(name)
#define EXPORT_TRACEPOINT_SYMBOL(name)
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28))
static inline void tracepoint_update_probe_range(struct tracepoint *begin,
struct tracepoint *end)
{ }
+#endif
#endif
Index: compat-wireless-2009-09-05/net/wireless/compat-2.6.28.c
===================================================================
--- compat-wireless-2009-09-05.orig/net/wireless/compat-2.6.28.c
+++ compat-wireless-2009-09-05/net/wireless/compat-2.6.28.c
@@ -260,6 +260,7 @@ static unsigned long round_jiffies_commo
return j;
}
+#if 0
/**
* round_jiffies_up - function to round jiffies up to a full second
* @j: the time in (absolute) jiffies that should be rounded
@@ -274,5 +275,6 @@ unsigned long round_jiffies_up(unsigned
return round_jiffies_common(j, raw_smp_processor_id(), true);
}
EXPORT_SYMBOL_GPL(round_jiffies_up);
+#endif
#endif /* LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28) */
Index: compat-wireless-2009-09-05/net/wireless/scan.c
===================================================================
--- compat-wireless-2009-09-05.orig/net/wireless/scan.c
+++ compat-wireless-2009-09-05/net/wireless/scan.c
@@ -499,8 +499,10 @@ cfg80211_inform_bss(struct wiphy *wiphy,
kref_init(&res->ref);
+#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,30))
/* cfg80211_bss_update() eats up res - we ensure we free it there */
kmemleak_ignore(res);
+#endif
res = cfg80211_bss_update(wiphy_to_dev(wiphy), res, 0);
if (!res)
^ permalink raw reply
* Re: [PATCH] ar9170usb: LEDs are confused
From: Christian Lamparter @ 2009-10-01 23:18 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Malte Gell, linux-wireless, Luis R. Rodriguez, linville
In-Reply-To: <3ace41890910011424g3711ffbap2d4057776f10b6d8@mail.gmail.com>
On Thursday 01 October 2009 23:24:59 Hin-Tak Leung wrote:
> On Thu, Oct 1, 2009 at 9:34 PM, Christian Lamparter
> <chunkeey@googlemail.com> wrote:
> > On Thursday 01 October 2009 20:06:35 Hin-Tak Leung wrote:
> >> On Thu, Oct 1, 2009 at 3:54 PM, Christian Lamparter
> >> <chunkeey@googlemail.com> wrote:
> >> > On 2009-10-01 06:32 AM, Malte Gell wrote:
> >> >>I first noticed the LEDs are confused,
> >> > no, the LED colors are not _confused_ at all.
> >> > This is simply different on.... well, you know: on a per-device base!
> >> >
> >> > For example: The Netgear uses a single bi-color LED for their WNDA3100 stick.
> >> > It glows blue or/and orange depending on the selected band and current
> >> > operation mode and state...
> >> >
> >> > No idea why they didn't stick to the usual red/green mix.
> >> > Maybe because someone told the hw-devs about the existence of
> >> > red/green colorblind people??!
> >> >
> >> > The original vendor driver (located: drivers/staging/otus/80211core/ledmgr.c)
> >> > goes to great lengths to describe what's behind the variety of
> >> > blinking signals. Which is nice, if you like expensive light shows...
> >>
> >> This is just based on my brief look at the relevant code itself - I
> >> think the driver actually enumerates how many LEDs the device has, so
> >> the ONLY_ONE_LED construct is a bit bogus. Also I think the
> >> 0x0846:0x9001 is Malte's with swapped LEDs, not ONLY_ONE?
> > ?
> >
> > 0x0846:0x9001 is a Netgear WN111 v2.
> > (one LED reference: otus' ledmgr.c ~line 547)
> >
> > and AFAIK: Malte uses an AVM FRITZ!WLAN Stick N (2.4?).
>
> I just remember the ID from Malte's ndiswrapper-list posting.
indeed, he must have bought a WN111 v2 as well?!
but just in case he's trying to use the WN111 driver:
This may not work, AVM FRITZ!WLAN is not 100% compatible with
most other AR9170 variants and could refuse to work properly with
other 3rd party drivers.
> It is not unthinkable of a rebranded device, or even vendor abusing the
> system a bit and put out a device which is subtly different with the
> same ids.
yes, I've heard of such cases.
But in all of them a reseller simply _borrowed_ the usb VID of
the hardware manufacture (e.g Ralink/Atheros) and not from
other resellers.
I hope you agree with me on this occasion that we don't have
to be paranoid about pid/vid collisions, unless someone
can prove that he got a genuine ar9170 with a bi-color LED/two LEDs
which identifies itself as WN111 v2.
> >> I had a look when Malte first wrote about the swap - the code
> >> basically just do assoc/data-tx in enumeration order (first LED found
> >> is assoc, 2nd is tx, which make sense if some variant only have a
> >> LED).
> > Depends. I think it's more important to have some sort of an "an activity LED"
> > than a connection indicator, because most desktops-guis nowadays have lots
> > of fancy applets which are constantly monitoring your connection status and
> > start to bark as soon as it changes...
> >
> > BTW: my laptop (with an IWL 5300) only has one LED assigned for wlan as well.
> > But, someone had the genius idea to put the activity LED into _inverted_
> > mode when the connection is established. It stays on after association
> > and flashes under TX activity... This is nice, but it has a downside:
> > two trigger _drive_ one LED => no real exclusive access anymore.
> > If you want to reassign the LEDs the clueless user has to be aware about
> > this trigger dependency, or he see some _blinking interference_.
> >
> >> As for the color - it is probably just a matter of commercial
> >> interests (if they can get a particular color from a source cheaper)
> > unlikely, the bi-color LED is a super bright one.
> >
> >> or simply variety to catch some customers - as you say, some *do* like
> >> expensive light shows, and there is a market for it and money to be
> >> made that way.
> > :-D
> >
> > well to be fair, I think they tried to implement some sort of
> > complex blinking language code. You can tell apart if
> > the device is idling/scanning/connected/sending in the 5GHz or 2GHz
> > band just by looking at the blue and orange rhythms...
> > (maybe this visual feedback is indeed easier to comprehend for the generic
> > customer than any hard and honest numbers)
> >
> > But back to the topic:
> > This elaborate morse code is clearly way beyond the scope and
> > abilities of ledclass. I think we should really stick to the
> > simple rule: one trigger corresponds to only one physical LED.
> >
> >> Anyway, I am just writing regarding the ONLY_ONE_LED construct and its
> >> association with 0x0846:0x9001 ...
> > hmm, not sure what I should do here...
> > Do you think the driver should simply ignore the lack of a second LED (color)?
> > Or is it just that the ONLY_ONE_LED construct sounds really lame
> > and needs a more cunning name?
>
> Hmm, I mean the ONLY_ONE_LED config should not be a compiled in config
> associated with an vid/pid, but dynamically determined from the
> enumeration.
dynamically determined? how?
Neither the EEPROM, nor any hw/fw register contain any information about
the number of available LEDs on the platform. The only feasible clue
comes from the devices' usb descriptors (=> VID and PID).
> In the case of only one LED, the it sounds quite neat to represent
> both assciation status and transmission status by blinking pattern
> :-).
It is... but the logic which programs the GPIOs is nowhere to be found
inside the driver... I think the vendor implemented it somewhere
deep inside the embedded controller (firmware).
And the card, driver, ledclass and userspace is unaware of this and
treats it as two independent things => this is BAD.
Let me explain (why this is BAD), just take this topic as a example:
Malte (our eagle-eyed user) discovered that his LEDs don't flash the
same way as with a customized vendor driver.
In his attempt to fix is issue, he could inadvertently break the
configuration of others...
And there's no denying here, at some point, we all had to
suffer from similar situations which are knows as the
fallout of -rc1 kernels. :-D
> But one of them should take priority in case of conflict, and in this
> regard it seems that you and I disagree on which should be.
hmm, when I think about it: the only (proper) way to accomplish this feat
would be to extend the LED(class), so it can have several different triggers
at the same time...
(or as an alternative: implement trigger filters. So some LEDs can only
be used with a specific trigger event.
however, there is a possibility that this might to more harm than good.)
Regards,
Chr
^ permalink raw reply
* Re: [stable] Making Intel WiFi Link 1000 usable in 2.6.31
From: reinette chatre @ 2009-10-01 23:16 UTC (permalink / raw)
To: Greg KH; +Cc: stable@kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <20091001224430.GH28208@kroah.com>
On Thu, 2009-10-01 at 15:44 -0700, Greg KH wrote:
> Ok, I've taken all of these, but wow, those are big patches, much larger
> than we normally take for the -stable tree.
>
> I don't want to have to do this again please.
ack.
Thank you very much
Reinette
^ permalink raw reply
* 2.6.32-rc1-git2: Reported regressions 2.6.30 -> 2.6.31
From: Rafael J. Wysocki @ 2009-10-01 19:53 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
[Notes:
* Quite a number of new regressions from 2.6.30 has been reported during
the last three weeks.
* The number of unresolved regressions 2.6.30 -> 2.6.31 is now the second
highest ever.]
This message contains a list of some regressions introduced between 2.6.30 and
2.6.31, for which there are no fixes in the mainline I know of. If any of them
have been fixed already, please let me know.
If you know of any other unresolved regressions introduced between 2.6.30
and 2.6.31, please let me know either and I'll add them to the list.
Also, please let me 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
----------------------------------------
2009-10-02 151 49 42
2009-09-06 123 34 27
2009-08-26 108 33 26
2009-08-20 102 32 29
2009-08-10 89 27 24
2009-08-02 76 36 28
2009-07-27 70 51 43
2009-07-07 35 25 21
2009-06-29 22 22 15
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14301
Subject : WARNING: at net/ipv4/af_inet.c:154
Submitter : Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>
Date : 2009-09-30 12:24 (2 days old)
References : http://marc.info/?l=linux-kernel&m=125431350218137&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14294
Subject : kernel BUG at drivers/ide/ide-disk.c:187
Submitter : Santiago Garcia Mantinan <manty@manty.net>
Date : 2009-09-30 11:05 (2 days old)
References : http://marc.info/?l=linux-kernel&m=125430926311466&w=4
Handled-By : David Miller <davem@davemloft.net>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14270
Subject : Cannot boot on a PIII Celeron
Submitter : Michael Tokarev <mjt@tls.msk.ru>
Date : 2009-09-28 15:26 (4 days old)
References : http://marc.info/?l=linux-kernel&m=125415160524110&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14267
Subject : Disassociating atheros wlan
Submitter : Kristoffer Ericson <kristoffer.ericson@gmail.com>
Date : 2009-09-24 10:16 (8 days old)
References : http://marc.info/?l=linux-kernel&m=125378723723384&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14266
Subject : regression in page writeback
Submitter : Shaohua Li <shaohua.li@intel.com>
Date : 2009-09-22 5:49 (10 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d7831a0bdf06b9f722b947bb0c205ff7d77cebd8
References : http://marc.info/?l=linux-kernel&m=125359858117176&w=4
Handled-By : Wu Fengguang <fengguang.wu@intel.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14265
Subject : ifconfig: page allocation failure. order:5, mode:0x8020 w/ e100
Submitter : Karol Lewandowski <karol.k.lewandowski@gmail.com>
Date : 2009-09-15 12:05 (17 days old)
References : http://marc.info/?l=linux-kernel&m=125301636509517&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14264
Subject : ehci problem - mouse dead on scroll
Submitter : Volker Armin Hemmann <volkerarmin@googlemail.com>
Date : 2009-09-12 7:46 (20 days old)
References : http://marc.info/?l=linux-kernel&m=125274202707893&w=4
Handled-By : Alan Stern <stern@rowland.harvard.edu>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14257
Subject : Not able to boot on 32 bit System
Submitter : Rishikesh <risrajak@linux.vnet.ibm.com>
Date : 2009-09-21 15:25 (11 days old)
References : http://marc.info/?l=linux-kernel&m=125354604314412&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14256
Subject : kernel BUG at fs/ext3/super.c:435
Submitter : Mikael Pettersson <mikpe@it.uu.se>
Date : 2009-09-21 7:29 (11 days old)
References : http://marc.info/?l=linux-kernel&m=125351816109264&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14255
Subject : WARNING: at drivers/char/tty_io.c:1267
Submitter : Heinz Diehl <htd@fancy-poultry.org>
Date : 2009-09-20 11:37 (12 days old)
References : http://marc.info/?l=linux-kernel&m=125344629506309&w=4
http://lkml.org/lkml/2009/9/8/393
Handled-By : Linus Torvalds <torvalds@linux-foundation.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14254
Subject : Hibernation broken by clocksource: Save mult_orig in clocksource_disable()
Submitter : Ondrej Zary <linux@rainbow-software.org>
Date : 2009-09-19 19:55 (13 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c7121843685de2bf7f3afd3ae1d6a146010bf1fc
References : http://marc.info/?l=linux-kernel&m=125339012527719&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14252
Subject : WARNING: at include/linux/skbuff.h:1382 w/ e1000
Submitter : Stephan von Krawczynski <skraw@ithnet.com>
Date : 2009-09-20 11:26 (12 days old)
References : http://marc.info/?l=linux-kernel&m=125344599006033&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14251
Subject : 2.6.31: no login prompt
Submitter : Frédéric L. W. Meunier <fredlwm@gmail.com>
Date : 2009-09-19 22:43 (13 days old)
References : http://marc.info/?l=linux-kernel&m=125340020804711&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14249
Subject : BUG: oops in gss_validate on 2.6.31
Submitter : Bastian Blank <bastian@waldi.eu.org>
Date : 2009-09-16 10:29 (16 days old)
References : http://marc.info/?l=linux-kernel&m=125309700417283&w=4
Handled-By : Trond Myklebust <trond.myklebust@fys.uio.no>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14248
Subject : 2.6.31 wireless: WARNING: at net/wireless/ibss.c:34
Submitter : Jurriaan <thunder8@xs4all.nl>
Date : 2009-09-13 7:32 (19 days old)
References : http://marc.info/?l=linux-kernel&m=125282721113553&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14222
Subject : Hibernation oopses for the 2nd time with 2.6.31 (won't fit the screen)
Submitter : Ondrej Zary <linux@rainbow-software.org>
Date : 2009-09-24 14:07 (8 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c7121843685de2bf7f3afd3ae1d6a146010bf1fc
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14205
Subject : Intel DX58SO mainboard - powering off takes really long
Submitter : Tomasz Chmielewski <tch@wpkg.org>
Date : 2009-09-22 10:14 (10 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14204
Subject : MCE prevent booting on my computer(pentium iii @500Mhz)
Submitter : GNUtoo <GNUtoo@no-log.org>
Date : 2009-09-21 20:36 (11 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14185
Subject : Oops in driversbasefirmware_class
Submitter : <lars_ericsson@telia.com>
Date : 2009-09-17 05:09 (15 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6e03a201bbe8137487f340d26aa662110e324b20
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14181
Subject : b43 causes panic at system shutdown
Submitter : Jeremy Huddleston <jeremyhu@freedesktop.org>
Date : 2009-09-15 18:34 (17 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14157
Subject : end_request: I/O error, dev cciss/cXdX, sector 0
Submitter : <jiri.harcarik@gmail.com>
Date : 2009-09-11 07:42 (21 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14143
Subject : OOPS when setting nr_requests for md devices
Submitter : aCaB <acab@clamav.net>
Date : 2009-09-08 08:48 (24 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14141
Subject : order 2 page allocation failures in iwlagn
Submitter : Frans Pop <elendil@planet.nl>
Date : 2009-09-06 7:40 (26 days old)
References : http://marc.info/?l=linux-kernel&m=125222287419691&w=4
Handled-By : Pekka Enberg <penberg@cs.helsinki.fi>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14133
Subject : WARNING: at arch/x86/kernel/smp.c:117 native_smp_send_reschedule
Submitter : Jens Axboe <jens.axboe@oracle.com>
Date : 2009-08-31 20:43 (32 days old)
References : http://marc.info/?l=linux-kernel&m=125175143918050&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14114
Subject : Tuning a saa7134 based card is broken in kernel 2.6.31-rc7
Submitter : Tsvety Petrov <Tsvetoslav.Petrov@itron.com>
Date : 2009-09-03 21:06 (29 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14090
Subject : WARNING: at fs/notify/inotify/inotify_user.c:394
Submitter : Joerg Platte <bugzilla@jako.ping.de>
Date : 2009-08-30 15:21 (33 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14070
Subject : lockdep warning triggered by dup_fd
Submitter : Bart Van Assche <bart.vanassche@gmail.com>
Date : 2009-08-23 09:36 (40 days old)
References : http://lkml.org/lkml/2009/8/23/8
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14058
Subject : Oops in fsnotify
Submitter : Grant Wilson <grant.wilson@zen.co.uk>
Date : 2009-08-20 15:48 (43 days old)
References : http://marc.info/?l=linux-kernel&m=125078450923133&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14013
Subject : hd don't show up
Submitter : Tim Blechmann <tim@klingt.org>
Date : 2009-08-14 8:26 (49 days old)
References : http://marc.info/?l=linux-kernel&m=125023842514480&w=4
Handled-By : Tejun Heo <tj@kernel.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13987
Subject : Received NMI interrupt at resume
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2009-08-15 07:55 (48 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13950
Subject : Oops when USB Serial disconnected while in use
Submitter : Bruno Prémont <bonbons@linux-vserver.org>
Date : 2009-08-08 17:47 (55 days old)
References : http://marc.info/?l=linux-kernel&m=124975432900466&w=4
Handled-By : Alan Stern <stern@rowland.harvard.edu>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13943
Subject : WARNING: at net/mac80211/mlme.c:2292 with ath5k
Submitter : Fabio Comolli <fabio.comolli@gmail.com>
Date : 2009-08-06 20:15 (57 days old)
References : http://marc.info/?l=linux-kernel&m=124958978600600&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13942
Subject : Troubles with AoE and uninitialized object
Submitter : Bruno Prémont <bonbons@linux-vserver.org>
Date : 2009-08-04 10:12 (59 days old)
References : http://marc.info/?l=linux-kernel&m=124938117104811&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13941
Subject : x86 Geode issue
Submitter : Martin-Éric Racine <q-funk@iki.fi>
Date : 2009-08-03 12:58 (60 days old)
References : http://marc.info/?l=linux-kernel&m=124930434732481&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13940
Subject : iwlagn and sky2 stopped working, ACPI-related
Submitter : Ricardo Jorge da Fonseca Marques Ferreira <storm@sys49152.net>
Date : 2009-08-07 22:33 (56 days old)
References : http://marc.info/?l=linux-kernel&m=124968457731107&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13935
Subject : 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)
Submitter : Adrian Ulrich <kernel@blinkenlights.ch>
Date : 2009-08-08 22:08 (55 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa047e4f6fa63a6e9d0ae4d7749538830d14a343
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13906
Subject : Huawei E169 GPRS connection causes Ooops
Submitter : Clemens Eisserer <linuxhippy@gmail.com>
Date : 2009-08-04 09:02 (59 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13869
Subject : Radeon framebuffer (w/o KMS) corruption at boot.
Submitter : Duncan <1i5t5.duncan@cox.net>
Date : 2009-07-29 16:44 (65 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13836
Subject : suspend script fails, related to stdout?
Submitter : Tomas M. <tmezzadra@gmail.com>
Date : 2009-07-17 21:24 (77 days old)
References : http://marc.info/?l=linux-kernel&m=124785853811667&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13809
Subject : oprofile: possible circular locking dependency detected
Submitter : Jerome Marchand <jmarchan@redhat.com>
Date : 2009-07-22 13:35 (72 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13733
Subject : 2.6.31-rc2: irq 16: nobody cared
Submitter : Niel Lambrechts <niel.lambrechts@gmail.com>
Date : 2009-07-06 18:32 (88 days old)
References : http://marc.info/?l=linux-kernel&m=124690524027166&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13645
Subject : NULL pointer dereference at (null) (level2_spare_pgt)
Submitter : poornima nayak <mpnayak@linux.vnet.ibm.com>
Date : 2009-06-17 17:56 (107 days old)
References : http://lkml.org/lkml/2009/6/17/194
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14275
Subject : kernel>=2.6.31: ahci.c: do not force unconditionally sb600 to 32bit dma any more?
Submitter : gabriele balducci <balducci@units.it>
Date : 2009-09-30 15:02 (2 days old)
Patch : http://bugzilla.kernel.org/show_bug.cgi?id=14275#c0
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14261
Subject : e1000e jumbo frames no longer work: 'Unsupported MTU setting'
Submitter : Nix <nix@esperi.org.uk>
Date : 2009-09-26 11:16 (6 days old)
References : http://marc.info/?l=linux-kernel&m=125396433321342&w=4
Handled-By : Alexander Duyck <alexander.duyck@gmail.com>
Patch : http://patchwork.kernel.org/patch/50277/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14258
Subject : Memory leak in SCSI initialization
Submitter : Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date : 2009-09-22 4:18 (10 days old)
References : http://marc.info/?l=linux-kernel&m=125359311312243&w=4
Handled-By : Michael Ellerman <michael@ellerman.id.au>
Patch : http://patchwork.kernel.org/patch/49258/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14253
Subject : Oops in driversbasefirmware_class
Submitter : Lars Ericsson <Lars_Ericsson@telia.com>
Date : 2009-09-16 20:44 (16 days old)
References : http://lkml.org/lkml/2009/9/16/461
Handled-By : Frederik Deweerdt <frederik.deweerdt@xprog.eu>
Patch : http://patchwork.kernel.org/patch/49914/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14137
Subject : usb console regressions
Submitter : Jason Wessel <jason.wessel@windriver.com>
Date : 2009-09-05 21:08 (27 days old)
References : http://marc.info/?l=linux-kernel&m=125218501310512&w=4
Handled-By : Jason Wessel <jason.wessel@windriver.com>
Patch : http://patchwork.kernel.org/patch/45953/
http://patchwork.kernel.org/patch/45952/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14017
Subject : _end symbol missing from Symbol.map
Submitter : Hannes Reinecke <hare@suse.de>
Date : 2009-08-13 6:45 (50 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=091e52c3551d3031343df24b573b770b4c6c72b6
References : http://marc.info/?l=linux-kernel&m=125014649102253&w=4
Handled-By : Hannes Reinecke <hare@suse.de>
Patch : http://marc.info/?l=linux-kernel&m=125014649102253&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13948
Subject : ath5k broken after suspend-to-ram
Submitter : Johannes Stezenbach <js@sig21.net>
Date : 2009-08-07 21:51 (56 days old)
References : http://marc.info/?l=linux-kernel&m=124968192727854&w=4
Handled-By : Nick Kossifidis <mickflemm@gmail.com>
Patch : http://patchwork.kernel.org/patch/38550/
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.30 and 2.6.31, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=13615
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply
* patch iwlwifi-traverse-linklist-to-find-the-valid-otp-block.patch added to 2.6.31-stable tree
From: gregkh @ 2009-10-01 22:46 UTC (permalink / raw)
To: wey-yi.w.guy, gregkh, greg, linux-wireless, linville,
reinette.chatre, stable
Cc: stable, stable-commits
In-Reply-To: <1254350175.26521.1662.camel@rc-desk>
This is a note to let you know that we have just queued up the patch titled
Subject: iwlwifi: traverse linklist to find the valid OTP block
to the 2.6.31-stable tree. Its filename is
iwlwifi-traverse-linklist-to-find-the-valid-otp-block.patch
A git repo of this tree can be found at
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>From reinette.chatre@intel.com Thu Oct 1 15:42:57 2009
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Wed, 30 Sep 2009 15:36:15 -0700
Subject: iwlwifi: traverse linklist to find the valid OTP block
To: Greg KH <greg@kroah.com>
Cc: "stable@kernel.org" <stable@kernel.org>, "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Message-ID: <1254350175.26521.1662.camel@rc-desk>
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
commit 415e49936b4b29b34c2fb561eeab867d41fc43a6 upstream.
For devices using OTP memory, EEPROM image can start from
any one of the OTP blocks. If shadow RAM is disabled, we need to
traverse link list to find the last valid block, then start the EEPROM
image reading.
If OTP is not full, the valid block is the block _before_ the last block
on the link list; the last block on the link list is the empty block
ready for next OTP refresh/update.
If OTP is full, then the last block is the valid block to be used for
configure the device.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/wireless/iwlwifi/iwl-1000.c | 4
drivers/net/wireless/iwlwifi/iwl-6000.c | 20 ++-
drivers/net/wireless/iwlwifi/iwl-core.h | 4
drivers/net/wireless/iwlwifi/iwl-dev.h | 12 +
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 185 ++++++++++++++++++++++++------
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 10 +
6 files changed, 192 insertions(+), 43 deletions(-)
--- a/drivers/net/wireless/iwlwifi/iwl-1000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-1000.c
@@ -62,12 +62,14 @@ struct iwl_cfg iwl1000_bgn_cfg = {
.ucode_api_min = IWL1000_UCODE_API_MIN,
.sku = IWL_SKU_G|IWL_SKU_N,
.ops = &iwl5000_ops,
- .eeprom_size = IWL_5000_EEPROM_IMG_SIZE,
+ .eeprom_size = OTP_LOW_IMAGE_SIZE,
.eeprom_ver = EEPROM_5000_EEPROM_VERSION,
.eeprom_calib_ver = EEPROM_5000_TX_POWER_VERSION,
.mod_params = &iwl50_mod_params,
.valid_tx_ant = ANT_A,
.valid_rx_ant = ANT_AB,
.need_pll_cfg = true,
+ .max_ll_items = OTP_MAX_LL_ITEMS_1000,
+ .shadow_ram_support = false,
};
--- a/drivers/net/wireless/iwlwifi/iwl-6000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-6000.c
@@ -82,13 +82,15 @@ struct iwl_cfg iwl6000_2ag_cfg = {
.ucode_api_min = IWL6000_UCODE_API_MIN,
.sku = IWL_SKU_A|IWL_SKU_G,
.ops = &iwl6000_ops,
- .eeprom_size = IWL_5000_EEPROM_IMG_SIZE,
+ .eeprom_size = OTP_LOW_IMAGE_SIZE,
.eeprom_ver = EEPROM_5000_EEPROM_VERSION,
.eeprom_calib_ver = EEPROM_5000_TX_POWER_VERSION,
.mod_params = &iwl50_mod_params,
.valid_tx_ant = ANT_BC,
.valid_rx_ant = ANT_BC,
.need_pll_cfg = false,
+ .max_ll_items = OTP_MAX_LL_ITEMS_6x00,
+ .shadow_ram_support = true,
};
struct iwl_cfg iwl6000_2agn_cfg = {
@@ -98,13 +100,15 @@ struct iwl_cfg iwl6000_2agn_cfg = {
.ucode_api_min = IWL6000_UCODE_API_MIN,
.sku = IWL_SKU_A|IWL_SKU_G|IWL_SKU_N,
.ops = &iwl6000_ops,
- .eeprom_size = IWL_5000_EEPROM_IMG_SIZE,
+ .eeprom_size = OTP_LOW_IMAGE_SIZE,
.eeprom_ver = EEPROM_5000_EEPROM_VERSION,
.eeprom_calib_ver = EEPROM_5000_TX_POWER_VERSION,
.mod_params = &iwl50_mod_params,
.valid_tx_ant = ANT_AB,
.valid_rx_ant = ANT_AB,
.need_pll_cfg = false,
+ .max_ll_items = OTP_MAX_LL_ITEMS_6x00,
+ .shadow_ram_support = true,
};
struct iwl_cfg iwl6050_2agn_cfg = {
@@ -114,13 +118,15 @@ struct iwl_cfg iwl6050_2agn_cfg = {
.ucode_api_min = IWL6050_UCODE_API_MIN,
.sku = IWL_SKU_A|IWL_SKU_G|IWL_SKU_N,
.ops = &iwl6000_ops,
- .eeprom_size = IWL_5000_EEPROM_IMG_SIZE,
+ .eeprom_size = OTP_LOW_IMAGE_SIZE,
.eeprom_ver = EEPROM_5000_EEPROM_VERSION,
.eeprom_calib_ver = EEPROM_5000_TX_POWER_VERSION,
.mod_params = &iwl50_mod_params,
.valid_tx_ant = ANT_AB,
.valid_rx_ant = ANT_AB,
.need_pll_cfg = false,
+ .max_ll_items = OTP_MAX_LL_ITEMS_6x00,
+ .shadow_ram_support = true,
};
struct iwl_cfg iwl6000_3agn_cfg = {
@@ -130,13 +136,15 @@ struct iwl_cfg iwl6000_3agn_cfg = {
.ucode_api_min = IWL6000_UCODE_API_MIN,
.sku = IWL_SKU_A|IWL_SKU_G|IWL_SKU_N,
.ops = &iwl6000_ops,
- .eeprom_size = IWL_5000_EEPROM_IMG_SIZE,
+ .eeprom_size = OTP_LOW_IMAGE_SIZE,
.eeprom_ver = EEPROM_5000_EEPROM_VERSION,
.eeprom_calib_ver = EEPROM_5000_TX_POWER_VERSION,
.mod_params = &iwl50_mod_params,
.valid_tx_ant = ANT_ABC,
.valid_rx_ant = ANT_ABC,
.need_pll_cfg = false,
+ .max_ll_items = OTP_MAX_LL_ITEMS_6x00,
+ .shadow_ram_support = true,
};
struct iwl_cfg iwl6050_3agn_cfg = {
@@ -146,13 +154,15 @@ struct iwl_cfg iwl6050_3agn_cfg = {
.ucode_api_min = IWL6050_UCODE_API_MIN,
.sku = IWL_SKU_A|IWL_SKU_G|IWL_SKU_N,
.ops = &iwl6000_ops,
- .eeprom_size = IWL_5000_EEPROM_IMG_SIZE,
+ .eeprom_size = OTP_LOW_IMAGE_SIZE,
.eeprom_ver = EEPROM_5000_EEPROM_VERSION,
.eeprom_calib_ver = EEPROM_5000_TX_POWER_VERSION,
.mod_params = &iwl50_mod_params,
.valid_tx_ant = ANT_ABC,
.valid_rx_ant = ANT_ABC,
.need_pll_cfg = false,
+ .max_ll_items = OTP_MAX_LL_ITEMS_6x00,
+ .shadow_ram_support = true,
};
MODULE_FIRMWARE(IWL6000_MODULE_FIRMWARE(IWL6000_UCODE_API_MAX));
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -207,6 +207,8 @@ struct iwl_mod_params {
* filename is constructed as fw_name_pre<api>.ucode.
* @ucode_api_max: Highest version of uCode API supported by driver.
* @ucode_api_min: Lowest version of uCode API supported by driver.
+ * @max_ll_items: max number of OTP blocks
+ * @shadow_ram_support: shadow support for OTP memory
*
* We enable the driver to be backward compatible wrt API version. The
* driver specifies which APIs it supports (with @ucode_api_max being the
@@ -243,6 +245,8 @@ struct iwl_cfg {
u8 valid_rx_ant;
bool need_pll_cfg;
bool use_isr_legacy;
+ const u16 max_ll_items;
+ const bool shadow_ram_support;
};
/***************************
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -835,6 +835,18 @@ enum iwl_nvm_type {
NVM_DEVICE_TYPE_OTP,
};
+/*
+ * Two types of OTP memory access modes
+ * IWL_OTP_ACCESS_ABSOLUTE - absolute address mode,
+ * based on physical memory addressing
+ * IWL_OTP_ACCESS_RELATIVE - relative address mode,
+ * based on logical memory addressing
+ */
+enum iwl_access_mode {
+ IWL_OTP_ACCESS_ABSOLUTE,
+ IWL_OTP_ACCESS_RELATIVE,
+};
+
/* interrupt statistics */
struct isr_statistics {
u32 hw;
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.c
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.c
@@ -152,6 +152,19 @@ int iwlcore_eeprom_verify_signature(stru
}
EXPORT_SYMBOL(iwlcore_eeprom_verify_signature);
+static void iwl_set_otp_access(struct iwl_priv *priv, enum iwl_access_mode mode)
+{
+ u32 otpgp;
+
+ otpgp = iwl_read32(priv, CSR_OTP_GP_REG);
+ if (mode == IWL_OTP_ACCESS_ABSOLUTE)
+ iwl_clear_bit(priv, CSR_OTP_GP_REG,
+ CSR_OTP_GP_REG_OTP_ACCESS_MODE);
+ else
+ iwl_set_bit(priv, CSR_OTP_GP_REG,
+ CSR_OTP_GP_REG_OTP_ACCESS_MODE);
+}
+
static int iwlcore_get_nvm_type(struct iwl_priv *priv)
{
u32 otpgp;
@@ -249,6 +262,124 @@ static int iwl_init_otp_access(struct iw
return ret;
}
+static int iwl_read_otp_word(struct iwl_priv *priv, u16 addr, u16 *eeprom_data)
+{
+ int ret = 0;
+ u32 r;
+ u32 otpgp;
+
+ _iwl_write32(priv, CSR_EEPROM_REG,
+ CSR_EEPROM_REG_MSK_ADDR & (addr << 1));
+ ret = iwl_poll_direct_bit(priv, CSR_EEPROM_REG,
+ CSR_EEPROM_REG_READ_VALID_MSK,
+ IWL_EEPROM_ACCESS_TIMEOUT);
+ if (ret < 0) {
+ IWL_ERR(priv, "Time out reading OTP[%d]\n", addr);
+ return ret;
+ }
+ r = _iwl_read_direct32(priv, CSR_EEPROM_REG);
+ /* check for ECC errors: */
+ otpgp = iwl_read32(priv, CSR_OTP_GP_REG);
+ if (otpgp & CSR_OTP_GP_REG_ECC_UNCORR_STATUS_MSK) {
+ /* stop in this case */
+ /* set the uncorrectable OTP ECC bit for acknowledgement */
+ iwl_set_bit(priv, CSR_OTP_GP_REG,
+ CSR_OTP_GP_REG_ECC_UNCORR_STATUS_MSK);
+ IWL_ERR(priv, "Uncorrectable OTP ECC error, abort OTP read\n");
+ return -EINVAL;
+ }
+ if (otpgp & CSR_OTP_GP_REG_ECC_CORR_STATUS_MSK) {
+ /* continue in this case */
+ /* set the correctable OTP ECC bit for acknowledgement */
+ iwl_set_bit(priv, CSR_OTP_GP_REG,
+ CSR_OTP_GP_REG_ECC_CORR_STATUS_MSK);
+ IWL_ERR(priv, "Correctable OTP ECC error, continue read\n");
+ }
+ *eeprom_data = le16_to_cpu((__force __le16)(r >> 16));
+ return 0;
+}
+
+/*
+ * iwl_is_otp_empty: check for empty OTP
+ */
+static bool iwl_is_otp_empty(struct iwl_priv *priv)
+{
+ u16 next_link_addr = 0, link_value;
+ bool is_empty = false;
+
+ /* locate the beginning of OTP link list */
+ if (!iwl_read_otp_word(priv, next_link_addr, &link_value)) {
+ if (!link_value) {
+ IWL_ERR(priv, "OTP is empty\n");
+ is_empty = true;
+ }
+ } else {
+ IWL_ERR(priv, "Unable to read first block of OTP list.\n");
+ is_empty = true;
+ }
+
+ return is_empty;
+}
+
+
+/*
+ * iwl_find_otp_image: find EEPROM image in OTP
+ * finding the OTP block that contains the EEPROM image.
+ * the last valid block on the link list (the block _before_ the last block)
+ * is the block we should read and used to configure the device.
+ * If all the available OTP blocks are full, the last block will be the block
+ * we should read and used to configure the device.
+ * only perform this operation if shadow RAM is disabled
+ */
+static int iwl_find_otp_image(struct iwl_priv *priv,
+ u16 *validblockaddr)
+{
+ u16 next_link_addr = 0, link_value = 0, valid_addr;
+ int ret = 0;
+ int usedblocks = 0;
+
+ /* set addressing mode to absolute to traverse the link list */
+ iwl_set_otp_access(priv, IWL_OTP_ACCESS_ABSOLUTE);
+
+ /* checking for empty OTP or error */
+ if (iwl_is_otp_empty(priv))
+ return -EINVAL;
+
+ /*
+ * start traverse link list
+ * until reach the max number of OTP blocks
+ * different devices have different number of OTP blocks
+ */
+ do {
+ /* save current valid block address
+ * check for more block on the link list
+ */
+ valid_addr = next_link_addr;
+ next_link_addr = link_value;
+ IWL_DEBUG_INFO(priv, "OTP blocks %d addr 0x%x\n",
+ usedblocks, next_link_addr);
+ if (iwl_read_otp_word(priv, next_link_addr, &link_value))
+ return -EINVAL;
+ if (!link_value) {
+ /*
+ * reach the end of link list,
+ * set address point to the starting address
+ * of the image
+ */
+ goto done;
+ }
+ /* more in the link list, continue */
+ usedblocks++;
+ } while (usedblocks < priv->cfg->max_ll_items);
+ /* OTP full, use last block */
+ IWL_DEBUG_INFO(priv, "OTP is full, use last block\n");
+done:
+ *validblockaddr = valid_addr;
+ /* skip first 2 bytes (link list pointer) */
+ *validblockaddr += 2;
+ return ret;
+}
+
/**
* iwl_eeprom_init - read EEPROM contents
*
@@ -263,14 +394,13 @@ int iwl_eeprom_init(struct iwl_priv *pri
int sz;
int ret;
u16 addr;
- u32 otpgp;
+ u16 validblockaddr = 0;
+ u16 cache_addr = 0;
priv->nvm_device_type = iwlcore_get_nvm_type(priv);
/* allocate eeprom */
- if (priv->nvm_device_type == NVM_DEVICE_TYPE_OTP)
- priv->cfg->eeprom_size =
- OTP_BLOCK_SIZE * OTP_LOWER_BLOCKS_TOTAL;
+ IWL_DEBUG_INFO(priv, "NVM size = %d\n", priv->cfg->eeprom_size);
sz = priv->cfg->eeprom_size;
priv->eeprom = kzalloc(sz, GFP_KERNEL);
if (!priv->eeprom) {
@@ -298,46 +428,31 @@ int iwl_eeprom_init(struct iwl_priv *pri
if (ret) {
IWL_ERR(priv, "Failed to initialize OTP access.\n");
ret = -ENOENT;
- goto err;
+ goto done;
}
_iwl_write32(priv, CSR_EEPROM_GP,
iwl_read32(priv, CSR_EEPROM_GP) &
~CSR_EEPROM_GP_IF_OWNER_MSK);
- /* clear */
- _iwl_write32(priv, CSR_OTP_GP_REG,
- iwl_read32(priv, CSR_OTP_GP_REG) |
+
+ iwl_set_bit(priv, CSR_OTP_GP_REG,
CSR_OTP_GP_REG_ECC_CORR_STATUS_MSK |
CSR_OTP_GP_REG_ECC_UNCORR_STATUS_MSK);
-
- for (addr = 0; addr < sz; addr += sizeof(u16)) {
- u32 r;
-
- _iwl_write32(priv, CSR_EEPROM_REG,
- CSR_EEPROM_REG_MSK_ADDR & (addr << 1));
-
- ret = iwl_poll_direct_bit(priv, CSR_EEPROM_REG,
- CSR_EEPROM_REG_READ_VALID_MSK,
- IWL_EEPROM_ACCESS_TIMEOUT);
- if (ret < 0) {
- IWL_ERR(priv, "Time out reading OTP[%d]\n", addr);
+ /* traversing the linked list if no shadow ram supported */
+ if (!priv->cfg->shadow_ram_support) {
+ if (iwl_find_otp_image(priv, &validblockaddr)) {
+ ret = -ENOENT;
goto done;
}
- r = _iwl_read_direct32(priv, CSR_EEPROM_REG);
- /* check for ECC errors: */
- otpgp = iwl_read32(priv, CSR_OTP_GP_REG);
- if (otpgp & CSR_OTP_GP_REG_ECC_UNCORR_STATUS_MSK) {
- /* stop in this case */
- IWL_ERR(priv, "Uncorrectable OTP ECC error, Abort OTP read\n");
+ }
+ for (addr = validblockaddr; addr < validblockaddr + sz;
+ addr += sizeof(u16)) {
+ u16 eeprom_data;
+
+ ret = iwl_read_otp_word(priv, addr, &eeprom_data);
+ if (ret)
goto done;
- }
- if (otpgp & CSR_OTP_GP_REG_ECC_CORR_STATUS_MSK) {
- /* continue in this case */
- _iwl_write32(priv, CSR_OTP_GP_REG,
- iwl_read32(priv, CSR_OTP_GP_REG) |
- CSR_OTP_GP_REG_ECC_CORR_STATUS_MSK);
- IWL_ERR(priv, "Correctable OTP ECC error, continue read\n");
- }
- e[addr / 2] = le16_to_cpu((__force __le16)(r >> 16));
+ e[cache_addr / 2] = eeprom_data;
+ cache_addr += sizeof(u16);
}
} else {
/* eeprom is an array of 16bit values */
--- a/drivers/net/wireless/iwlwifi/iwl-eeprom.h
+++ b/drivers/net/wireless/iwlwifi/iwl-eeprom.h
@@ -180,8 +180,14 @@ struct iwl_eeprom_channel {
#define EEPROM_5050_EEPROM_VERSION (0x21E)
/* OTP */
-#define OTP_LOWER_BLOCKS_TOTAL (3)
-#define OTP_BLOCK_SIZE (0x400)
+/* lower blocks contain EEPROM image and calibration data */
+#define OTP_LOW_IMAGE_SIZE (2 * 512 * sizeof(u16)) /* 2 KB */
+/* high blocks contain PAPD data */
+#define OTP_HIGH_IMAGE_SIZE_6x00 (6 * 512 * sizeof(u16)) /* 6 KB */
+#define OTP_HIGH_IMAGE_SIZE_1000 (0x200 * sizeof(u16)) /* 1024 bytes */
+#define OTP_MAX_LL_ITEMS_1000 (3) /* OTP blocks for 1000 */
+#define OTP_MAX_LL_ITEMS_6x00 (4) /* OTP blocks for 6x00 */
+#define OTP_MAX_LL_ITEMS_6x50 (7) /* OTP blocks for 6x50 */
/* 2.4 GHz */
extern const u8 iwl_eeprom_band_1[14];
Patches currently in stable-queue which might be from wey-yi.w.guy@intel.com are
queue-2.6.31/iwlagn-modify-digital-svr-for-1000.patch
queue-2.6.31/iwlwifi-traverse-linklist-to-find-the-valid-otp-block.patch
queue-2.6.31/iwlwifi-fix-unloading-driver-while-scanning.patch
^ permalink raw reply
* Re: [stable] Making Intel WiFi Link 1000 usable in 2.6.31
From: Greg KH @ 2009-10-01 22:44 UTC (permalink / raw)
To: reinette chatre; +Cc: stable@kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <1254350175.26521.1662.camel@rc-desk>
On Wed, Sep 30, 2009 at 03:36:15PM -0700, reinette chatre wrote:
> On Wed, 2009-09-30 at 14:24 -0700, Greg KH wrote:
> > On Wed, Sep 30, 2009 at 12:34:19PM -0700, reinette chatre wrote:
> > > commit cc0f555d511a5fe9d4519334c8f674a1dbab9e3a
> > > Author: Jay Sternberg <jay.e.sternberg@intel.com>
> > > Date: Fri Jul 17 09:30:16 2009 -0700
> > >
> > > iwlwifi: Handle new firmware file with ucode build number in header
> > >
> > > commit cce53aa347c1e023d967b1cb1aa393c725aedba5
> > > Author: Jay Sternberg <jay.e.sternberg@intel.com>
> > > Date: Fri Jul 17 09:30:22 2009 -0700
> > >
> > > iwlwifi: update 1000 series API version to match firmware
> > >
> > > commit 02c06e4abc0680afd31bf481a803541556757fb6
> > > Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> > > Date: Fri Jul 17 09:30:14 2009 -0700
> > >
> > > iwlagn: modify digital SVR for 1000
> > >
> > > commit 415e49936b4b29b34c2fb561eeab867d41fc43a6
> > > Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> > > Date: Thu Aug 13 13:30:54 2009 -0700
> > >
> > > iwlwifi: traverse linklist to find the valid OTP block
> > >
> > > commit f7ea097d9b4e61a816c041c92548aad7c7ed7915
> > > Author: Reinette Chatre <reinette.chatre@intel.com>
> > > Date: Fri Jul 24 11:13:12 2009 -0700
> > >
> > > iwlagn: fix null pointer access during ucode load on 1000
> > >
> > > Thank you very much
> >
> > Is this the order in which they should be applied?
>
> The first three patches from this list can be applied directly from
> linux-2.6 in the order they appear here. That is:
>
> commit cc0f555d511a5fe9d4519334c8f674a1dbab9e3a
> Author: Jay Sternberg <jay.e.sternberg@intel.com>
> Date: Fri Jul 17 09:30:16 2009 -0700
>
> iwlwifi: Handle new firmware file with ucode build number in header
>
> commit cce53aa347c1e023d967b1cb1aa393c725aedba5
> Author: Jay Sternberg <jay.e.sternberg@intel.com>
> Date: Fri Jul 17 09:30:22 2009 -0700
>
> iwlwifi: update 1000 series API version to match firmware
>
> commit 02c06e4abc0680afd31bf481a803541556757fb6
> Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> Date: Fri Jul 17 09:30:14 2009 -0700
>
> iwlagn: modify digital SVR for 1000
>
>
> The fourth patch needed backporting and is attached.
>
> After doing the backporting I determined that the fifth patch is not
> needed.
>
> Thank you very much for taking these patches
Ok, I've taken all of these, but wow, those are big patches, much larger
than we normally take for the -stable tree.
I don't want to have to do this again please.
thanks,
greg k-h
^ permalink raw reply
* Re: 2.6.32-rc1-git2: Reported regressions from 2.6.31
From: James Bottomley @ 2009-10-01 22:48 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Linus Torvalds, Natalie Protasevich, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <9UCePxij8cB.A.VCG.-3SxKB@chimera>
On Thu, 2009-10-01 at 21:26 +0200, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14214
> Subject : BUG at drivers/scsi/scsi_lib.c:1108!
> Submitter : Plamen Petrov <pvp-lsts@fs.ru.acad.bg>
> Date : 2009-09-23 11:13 (9 days old)
This one is fixed (as confirmed by the bug report).
James
^ permalink raw reply
* 2.6.32-rc1-git2: Reported regressions from 2.6.31
From: Rafael J. Wysocki @ 2009-10-01 19:26 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
[Notes:
* Here's the first summary report of known regressions from 2.6.31. There's
not too many of them at the moment, which is nice.
* We're still getting quite a number of reports of regressions from 2.6.30 and
it's been that way since 2.6.31 was released. For details please see the
summary report of regressions 2.6.30 -> 2.6.31 that will follow shortly.]
This message contains a list of some regressions from 2.6.31, for which there
are no fixes in the mainline I know of. If any of them have been fixed already,
please let me know.
If you know of any other unresolved regressions from 2.6.31, please let me know
either and I'll add them to the list. Also, please let me 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
----------------------------------------
2009-10-02 22 15 9
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14299
Subject : oops in wireless, iwl3945 related?
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2009-09-29 17:12 (3 days old)
References : http://marc.info/?l=linux-kernel&m=125424439725743&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14298
Subject : warning at manage.c:361 (set_irq_wake), matrix-keypad related?
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2009-09-30 20:07 (2 days old)
References : http://marc.info/?l=linux-kernel&m=125434130703538&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14297
Subject : console resume broken since ba15ab0e8d
Submitter : Sascha Hauer <s.hauer@pengutronix.de>
Date : 2009-09-30 15:11 (2 days old)
References : http://marc.info/?l=linux-kernel&m=125432349404060&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14296
Subject : spitz boots but suspend/resume is broken
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2009-09-30 12:06 (2 days old)
References : http://marc.info/?l=linux-kernel&m=125431244516449&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14279
Subject : Suspend to RAM freeze totally since 2.6.32-rc1
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2009-09-30 18:14 (2 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14277
Subject : Caught 8-bit read from freed memory in b43 driver at association
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2009-09-30 18:06 (2 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14276
Subject : nfsroot will not remount rw and claims illegal options
Submitter : Hans de Bruin <bruinjm@xs4all.nl>
Date : 2009-09-30 15:08 (2 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14260
Subject : T400 suspend/resume regression
Submitter : Theodore Tso <tytso@mit.edu>
Date : 2009-09-26 6:57 (6 days old)
References : http://marc.info/?l=linux-kernel&m=125394827806011&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14214
Subject : BUG at drivers/scsi/scsi_lib.c:1108!
Submitter : Plamen Petrov <pvp-lsts@fs.ru.acad.bg>
Date : 2009-09-23 11:13 (9 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14302
Subject : Kernel panic on i386 machine when booting with profile=2
Submitter : Shi, Alex <alex.shi@intel.com>
Date : 2009-10-01 3:23 (1 days old)
References : http://marc.info/?l=linux-kernel&m=125436749607199&w=4
Handled-By : Alex Shi <alex.shi@intel.com>
Patch : http://patchwork.kernel.org/patch/50813/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14300
Subject : BUG_ON crash w/ ext4
Submitter : Markus Trippelsdorf <markus@trippelsdorf.de>
Date : 2009-10-01 1:41 (1 days old)
References : http://marc.info/?l=linux-kernel&m=125436130800340&w=4
http://marc.info/?l=linux-kernel&m=125436568504914&w=4
Handled-By : Theodore Tso <tytso@mit.edu>
Patch : http://patchwork.kernel.org/patch/50810/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14278
Subject : New message "NOHZ: local_softirq_pending 08" at each ping request
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2009-09-30 18:12 (2 days old)
Handled-By : Michael Buesch <mb@bu3sch.de>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=23220
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14271
Subject : ACPI boot memory leaks
Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date : 2009-09-29 9:18 (3 days old)
References : http://marc.info/?l=linux-kernel&m=125421594111690&w=4
Handled-By : Bjorn Helgaas <bjorn.helgaas@hp.com>
Patch : http://patchwork.kernel.org/patch/50565/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14259
Subject : NFS problem with past 2.6.31 git tree
Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date : 2009-09-25 15:12 (7 days old)
References : http://marc.info/?l=linux-kernel&m=125389156504570&w=4
Handled-By : Trond Myklebust <Trond.Myklebust@netapp.com>
Patch : http://patchwork.kernel.org/patch/50428/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14247
Subject : ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] flooding logs
Submitter : Thomas Backlund <tmb@mandriva.org>
Date : 2009-09-25 15:08 (7 days old)
References : http://lkml.org/lkml/2009/9/25/121
Handled-By : Alexey Starikovskiy <astarikovskiy@suse.de>
Patch : http://patchwork.kernel.org/patch/50516/
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.31,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=14230
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply
* Re: 2.6.32-rc0-git: oops in wireless, iwl3945 related?
From: Johannes Berg @ 2009-10-01 22:28 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-kernel, yi.zhu, reinette.chatre, linux-wireless
In-Reply-To: <20091001222413.GB10893@elf.ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]
On Fri, 2009-10-02 at 00:24 +0200, Pavel Machek wrote:
> Not sure. I was trying to setup adhoc network, randomly running
> scripts and pushing interfaces up and down. But I do have timestamps:
>
> Drat. What is going on? I guess this is from another instance; looks
> like I did not even notice it. text: address is same so that should be
> same version...?
> Sep 28 22:09:02 amd kernel: Registered led device: iwl-phy0::radio
> Sep 28 22:09:02 amd kernel: Registered led device: iwl-phy0::assoc
> Sep 28 22:09:02 amd kernel: Registered led device: iwl-phy0::RX
> Sep 28 22:09:02 amd kernel: Registered led device: iwl-phy0::TX
> Sep 28 22:09:02 amd wpa_supplicant[1984]: No network configuration
> found for the current AP
> Sep 28 22:09:11 amd wpa_supplicant[1984]: CTRL-EVENT-SCAN-RESULTS
> Sep 28 22:09:11 amd wpa_supplicant[1984]: No network configuration
> found for the current AP
> Sep 28 22:09:11 amd kernel: skb_over_panic: text:c07b4113 len:130
> put:36 head:e4c3edf0 data:e4c3edf0 tail:0xe4c3ee72 end:0xe4c3ee70
> dev:<NULL>
oddly, this one doesn't even have any of the other messages that we had
before the problem in the other instance.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: 2.6.32-rc0-git: oops in wireless, iwl3945 related?
From: Pavel Machek @ 2009-10-01 22:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-kernel, yi.zhu, reinette.chatre, linux-wireless
In-Reply-To: <1254431783.3959.45.camel@johannes.local>
On Thu 2009-10-01 23:16:23, Johannes Berg wrote:
> On Tue, 2009-09-29 at 19:12 +0200, Pavel Machek wrote:
> >
> > Happened while playing with wireless.
> >
> > Kernel is:
> >
> > Linux version 2.6.31 (pavel@amd) (gcc version 4.3.3 (Debian 4.3.3-10)
> > ) #72 SMP Thu Sep 10 21:56:19 CEST 2009
> > KERNEL supported cpus:
> >
> > (Could we get kernels between release and -rc1 mark themselves
> > somehow?)
>
> CONFIG_LOCALVERSION_AUTO?
Well, I'd really like Linus to change extraversion as to -rc0 as first
commit after release...
> > Registered led device: iwl-phy0::radio
> > Registered led device: iwl-phy0::assoc
> > Registered led device: iwl-phy0::RX
> > Registered led device: iwl-phy0::TX
> > wlan0: Selected IBSS BSSID 02:18:41:de:3f:02 based on configured SSID
> > wlan0: Trigger new scan to find an IBSS to join
> > wlan0: Trigger new scan to find an IBSS to join
> > wlan0: Creating new IBSS network, BSSID f2:d3:80:82:ed:6a
> > wlan0: Creating new IBSS network, BSSID 52:17:bf:45:d6:9d
> > skb_over_panic: text:c07b4113 len:130 put:36 head:e4c3edf0
>
> This entire log is very odd ... can you reproduce this easily? printk
> timestamps would be useful.
Not sure. I was trying to setup adhoc network, randomly running
scripts and pushing interfaces up and down. But I do have timestamps:
Drat. What is going on? I guess this is from another instance; looks
like I did not even notice it. text: address is same so that should be
same version...?
Pavel
Sep 28 22:08:34 amd wpa_supplicant[1984]: Failed to initiate AP scan.
Sep 28 22:08:34 amd wpa_supplicant[1984]: No network configuration
found for the current AP
Sep 28 22:08:44 amd wpa_supplicant[1984]: No network configuration
found for the current AP
Sep 28 22:08:44 amd wpa_supplicant[1984]: CTRL-EVENT-SCAN-RESULTS
Sep 28 22:08:44 amd wpa_supplicant[1984]: WPS-AP-AVAILABLE
Sep 28 22:08:49 amd wpa_supplicant[1984]: Failed to initiate AP scan.
Sep 28 22:08:51 amd dhclient: DHCPREQUEST on wlan0 to 192.168.1.1 port
67
Sep 28 22:08:51 amd dhclient: send_packet: Network is unreachable
Sep 28 22:08:51 amd dhclient: send_packet: please consult README file
regarding broadcast address.
Sep 28 22:08:52 amd dhclient: receive_packet failed on wlan0: Network
is down
Sep 28 22:08:52 amd modprobe: FATAL: Could not load
/lib/modules/2.6.31/modules.dep: No such file or directory
Sep 28 22:08:58 amd dhclient: DHCPREQUEST on wlan0 to 192.168.1.1 port
67
Sep 28 22:08:58 amd dhclient: send_packet: Network is unreachable
Sep 28 22:08:58 amd dhclient: send_packet: please consult README file
regarding broadcast address.
Sep 28 22:08:59 amd wpa_supplicant[1984]: Failed to initiate AP scan.
Sep 28 22:09:02 amd kernel: Registered led device: iwl-phy0::radio
Sep 28 22:09:02 amd kernel: Registered led device: iwl-phy0::assoc
Sep 28 22:09:02 amd kernel: Registered led device: iwl-phy0::RX
Sep 28 22:09:02 amd kernel: Registered led device: iwl-phy0::TX
Sep 28 22:09:02 amd wpa_supplicant[1984]: No network configuration
found for the current AP
Sep 28 22:09:11 amd wpa_supplicant[1984]: CTRL-EVENT-SCAN-RESULTS
Sep 28 22:09:11 amd wpa_supplicant[1984]: No network configuration
found for the current AP
Sep 28 22:09:11 amd kernel: skb_over_panic: text:c07b4113 len:130
put:36 head:e4c3edf0 data:e4c3edf0 tail:0xe4c3ee72 end:0xe4c3ee70
dev:<NULL>
Sep 28 22:09:11 amd kernel: ------------[ cut here ]------------
Sep 28 22:09:11 amd kernel: kernel BUG at net/core/skbuff.c:127!
Sep 28 22:09:11 amd kernel: invalid opcode: 0000 [#1] SMP
DEBUG_PAGEALLOC
Sep 28 22:09:11 amd kernel: last sysfs file:
/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:01/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/status
Sep 28 22:09:11 amd kernel: Modules linked in:
Sep 28 22:09:11 amd kernel:
Sep 28 22:09:11 amd kernel: Pid: 1353, comm: iwl3945 Not tainted
(2.6.31 #72) 17097HU
Sep 28 22:09:11 amd kernel: EIP: 0060:[<c06d7189>] EFLAGS: 00010286
CPU: 0
Sep 28 22:09:11 amd kernel: EIP is at skb_put+0x89/0x90
Sep 28 22:09:11 amd kernel: EAX: 00000079 EBX: e4c3ee72 ECX: c0230881
EDX: 01eef000
Sep 28 22:09:11 amd kernel: ESI: 00000024 EDI: f5e20fc0 EBP: f5dcde04
ESP: f5dcddd8
Sep 28 22:09:11 amd kernel: DS: 007b ES: 007b FS: 00d8 GS: 0000 SS:
0068
Sep 28 22:09:11 amd kernel: Process iwl3945 (pid: 1353, ti=f5dcc000
task=f72e4698 task.ti=f5dcc000)
Sep 28 22:09:11 amd kernel: Stack:
Sep 28 22:09:11 amd kernel: c0a28c24 c07b4113 00000082 00000024
e4c3edf0 e4c3edf0 e4c3ee72 e4c3ee70
Sep 28 22:09:11 amd kernel: <0> c09ac8b9 0000009c 66666667 f5dcde74
c07b4113 00000037 00000007 00000282
Sep 28 22:09:11 amd kernel: <0> 00000002 00000000 00000040 00000006
00000064 f5e1bbc0 f5e1be23 c03e82b1
Sep 28 22:09:11 amd kernel: Call Trace:
Sep 28 22:09:11 amd kernel: [<c07b4113>] ?
__ieee80211_sta_join_ibss+0x143/0x3d0
Sep 28 22:09:11 amd kernel: [<c07b4113>] ?
__ieee80211_sta_join_ibss+0x143/0x3d0
Sep 28 22:09:11 amd kernel: [<c03e82b1>] ? extract_entropy+0x51/0xa0
Sep 28 22:09:11 amd kernel: [<c07b4677>] ?
ieee80211_sta_find_ibss+0x227/0x450
Sep 28 22:09:11 amd kernel: [<c07fcdc2>] ?
mutex_lock_nested+0x1c2/0x230
Sep 28 22:09:11 amd kernel: [<c07b48b7>] ?
ieee80211_ibss_notify_scan_completed+0x17//var/log/syslog
Sep 28 22:09:11 amd kernel: [<c07b4909>] ?
ieee80211_ibss_notify_scan_completed+0x69/0x80
Sep 28 22:09:11 amd kernel: [<c07b1b85>] ?
ieee80211_scan_completed+0xc5/0x450
Sep 28 22:09:11 amd kernel: [<c0239e29>] ? del_timer_sync+0x59/0x70
Sep 28 22:09:11 amd kernel: [<c0239dd0>] ? del_timer_sync+0x0/0x70
Sep 28 22:09:11 amd kernel: [<c052a4df>] ?
iwl_bg_scan_completed+0x3f/0x80
Sep 28 22:09:11 amd kernel: [<c024089d>] ? worker_thread+0x16d/0x280
Sep 28 22:09:11 amd kernel: [<c024083a>] ? worker_thread+0x10a/0x280
Sep 28 22:09:11 amd kernel: [<c052a4a0>] ?
iwl_bg_scan_completed+0x0/0x80
Sep 28 22:09:11 amd kernel: [<c02449d0>] ?
autoremove_wake_function+0x0/0x50
Sep 28 22:09:11 amd kernel: [<c0240730>] ? worker_thread+0x0/0x280
Sep 28 22:09:11 amd kernel: [<c02446dc>] ? kthread+0x7c/0x90
Sep 28 22:09:11 amd kernel: [<c0244660>] ? kthread+0x0/0x90
Sep 28 22:09:11 amd kernel: [<c020385f>] ?
kernel_thread_helper+0x7/0x18
Sep 28 22:09:11 amd kernel: Code: 44 24 14 8b 81 a0 00 00 00 89 74 24
0c 89 44 24 10 8b 41 50 c7 04 24 24 8c a2 c0 89 44 24 08 8b 45 04 89
44 24 04 e8 a7 40 12 00 <0f> 0b eb fe 8d 76 00 55 89 e5 57 56 53 83 ec
18 89 45 e4 89 55
Sep 28 22:09:11 amd kernel: EIP: [<c06d7189>] skb_put+0x89/0x90 SS:ESP
0068:f5dcddd8
Sep 28 22:09:11 amd kernel: ---[ end trace 5d5762000564cd5a ]---
Sep 28 22:09:12 amd dhclient: DHCPREQUEST on wlan0 to 192.168.1.1 port
67
Sep 28 22:09:12 amd dhclient: send_packet: Network is unreachable
Sep 28 22:09:12 amd dhclient: send_packet: please consult README file
regarding broadcast address.
Sep 28 22:09:29 amd dhclient: DHCPREQUEST on wlan0 to 192.168.1.1 port
67
Sep 28 22:09:29 amd dhclient: send_packet: Network is unreachable
Sep 28 22:09:29 amd dhclient: send_packet: please consult README file
regarding broadcast address.
Sep 28 22:09:44 amd dhclient: DHCPREQUEST on wlan0 to 192.168.1.1 port
67
Sep 28 22:09:44 amd dhclient: send_packet: Network is unreachable
Sep 28 22:09:44 amd dhclient: send_packet: please consult README file
regarding broadc/var/log/syslog lines 147505-147530/155914 94%
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: Linux-2.6.32-rc1/2] wext refactor needs wpasupplicant 0.7.0+?
From: Sedat Dilek @ 2009-10-01 21:55 UTC (permalink / raw)
To: wireless; +Cc: Johannes Berg
In-Reply-To: <2d0a357f0910010247jfda1199h5a9b873233b186ca@mail.gmail.com>
Problem with wpasupplicant v0.6.9 seems to be fixed with my latest kernel:
Upstream (2.6.32-rc1-git2) with wireless-testing (master-2009-09-30) on top
I am sorry if I confused people...
- Sedat -
On Thu, Oct 1, 2009 at 11:47 AM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
> Hi,
>
> a few hours ago I compiled a new kernel from upstream and put
> wireless-testing master-2009-09-30 on top of it.
>
> Last commit a1bec0ecfc76281d5e1ebd33435c67da7dd0fe71
> wext: refactor
>
> linux-2.6/master:
> 84d88d5: Merge branch 'sched-fixes-for-linus' of
> git://git./linux/kernel/git/tip/linux-2.6-tip
>
> After installation of the above described kernel, I could not connect
> to my AP using wext driver and wpasupplicant (0.6.9-3) from Debian/sid
> [1].
> With ath5k I could not establish a network connection neither via DHCP
> nor via static-IP to my AP (iwl3945 on a second machine works with
> self-debianized wpasupplicant 0.7.0+ and static-IP, same kernel).
>
> Just for clarification:
> Does wext refactor need a wpasupplicant >= 0.7.0 from hostap GIT repository [2]?
>
> Below you will find some needful informations of my configuration and system.
>
> Kind Regards,
> - Sedat -
>
> P.S.:
> I can offer a debianized wpasupplicant package for 32bit, if you like.
>
> [1] http://packages.debian.org/sid/wpasupplicant
> [2] http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=summary
>
> ---- NEEDFUL INFORMATIONS ----
>
> # lspci -nnvv | grep -i ath
> 02:02.0 Ethernet controller [0200]: Atheros Communications Inc. AR5212
> 802.11abg NIC [168c:1014] (rev 01)
> Kernel driver in use: ath5k
>
> # ps axu | grep -v grep | grep wpa
> root 1411 0.0 0.1 4916 1124 ? Ss 10:59 0:00
> /sbin/wpa_supplicant -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0
> -D wext -C /var/run/wpa_supplicant
>
> # wpa_cli -iwlan0 status
> bssid=00:04:0e:e4:00:3d
> ssid=$mySSID
> id=0
> pairwise_cipher=CCMP
> group_cipher=CCMP
> key_mgmt=WPA2-PSK
> wpa_state=COMPLETED
> ip_address=$myIPADDR
>
> # cat /proc/version
> Linux version 2.6.32-rc1-iniza-686-kms (Debian 2.6.32~rc1-5)
> (sedat.dilek@gmail.com) (gcc version 4.4.1 (Debian 4.4.1-4) ) #1 SMP
> PREEMPT Thu Oct 1 04:57:49 CEST 2009
>
^ permalink raw reply
* Re: 2.6.32-rc0-git: oops in wireless, iwl3945 related?
From: Johannes Berg @ 2009-10-01 21:27 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-kernel, yi.zhu, reinette.chatre, linux-wireless
In-Reply-To: <1254431783.3959.45.camel@johannes.local>
On Thu, 2009-10-01 at 23:16 +0200, Johannes Berg wrote:
> > wlan0: Selected IBSS BSSID 02:18:41:de:3f:02 based on configured SSID
> > wlan0: Trigger new scan to find an IBSS to join
> > wlan0: Trigger new scan to find an IBSS to join
> > wlan0: Creating new IBSS network, BSSID f2:d3:80:82:ed:6a
> > wlan0: Creating new IBSS network, BSSID 52:17:bf:45:d6:9d
> > skb_over_panic: text:c07b4113 len:130 put:36 head:e4c3edf0
>
> This entire log is very odd ... can you reproduce this easily? printk
> timestamps would be useful.
Kinda looks like a race condition, but it's rather odd. I think there's
a race condition, so I'm going to submit this patch regardless after
some testing, but if you want please try the patch below.
johannes
---
net/mac80211/ibss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- wireless-testing.orig/net/mac80211/ibss.c 2009-10-01 23:21:11.000000000 +0200
+++ wireless-testing/net/mac80211/ibss.c 2009-10-01 23:22:24.000000000 +0200
@@ -831,7 +831,7 @@ void ieee80211_ibss_notify_scan_complete
if (!sdata->u.ibss.ssid_len)
continue;
sdata->u.ibss.last_scan_completed = jiffies;
- ieee80211_sta_find_ibss(sdata);
+ mod_timer(&ifibss->timer, 0);
}
mutex_unlock(&local->iflist_mtx);
}
^ permalink raw reply
* Re: [PATCH] ar9170usb: LEDs are confused
From: Hin-Tak Leung @ 2009-10-01 21:24 UTC (permalink / raw)
To: Christian Lamparter
Cc: Malte Gell, linux-wireless, Luis R. Rodriguez, linville
In-Reply-To: <200910012234.33182.chunkeey@googlemail.com>
On Thu, Oct 1, 2009 at 9:34 PM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Thursday 01 October 2009 20:06:35 Hin-Tak Leung wrote:
>> On Thu, Oct 1, 2009 at 3:54 PM, Christian Lamparter
>> <chunkeey@googlemail.com> wrote:
>> > On 2009-10-01 06:32 AM, Malte Gell wrote:
>> >>I first noticed the LEDs are confused,
>> > no, the LED colors are not _confused_ at all.
>> > This is simply different on.... well, you know: on a per-device base!
>> >
>> > For example: The Netgear uses a single bi-color LED for their WNDA3100 stick.
>> > It glows blue or/and orange depending on the selected band and current
>> > operation mode and state...
>> >
>> > No idea why they didn't stick to the usual red/green mix.
>> > Maybe because someone told the hw-devs about the existence of
>> > red/green colorblind people??!
>> >
>> > The original vendor driver (located: drivers/staging/otus/80211core/ledmgr.c)
>> > goes to great lengths to describe what's behind the variety of
>> > blinking signals. Which is nice, if you like expensive light shows...
>>
>> This is just based on my brief look at the relevant code itself - I
>> think the driver actually enumerates how many LEDs the device has, so
>> the ONLY_ONE_LED construct is a bit bogus. Also I think the
>> 0x0846:0x9001 is Malte's with swapped LEDs, not ONLY_ONE?
> ?
>
> 0x0846:0x9001 is a Netgear WN111 v2.
> (one LED reference: otus' ledmgr.c ~line 547)
>
> and AFAIK: Malte uses an AVM FRITZ!WLAN Stick N (2.4?).
I just remember the ID from Malte's ndiswrapper-list posting. It is
not unthinkable of a rebranded device, or even vendor abusing the
system a bit and put out a device which is subtly different with the
same ids.
>
>> I had a look when Malte first wrote about the swap - the code
>> basically just do assoc/data-tx in enumeration order (first LED found
>> is assoc, 2nd is tx, which make sense if some variant only have a
>> LED).
> Depends. I think it's more important to have some sort of an "an activity LED"
> than a connection indicator, because most desktops-guis nowadays have lots
> of fancy applets which are constantly monitoring your connection status and
> start to bark as soon as it changes...
>
> BTW: my laptop (with an IWL 5300) only has one LED assigned for wlan as well.
> But, someone had the genius idea to put the activity LED into _inverted_
> mode when the connection is established. It stays on after association
> and flashes under TX activity... This is nice, but it has a downside:
> two trigger _drive_ one LED => no real exclusive access anymore.
> If you want to reassign the LEDs the clueless user has to be aware about
> this trigger dependency, or he see some _blinking interference_.
>
>> As for the color - it is probably just a matter of commercial
>> interests (if they can get a particular color from a source cheaper)
> unlikely, the bi-color LED is a super bright one.
>
>> or simply variety to catch some customers - as you say, some *do* like
>> expensive light shows, and there is a market for it and money to be
>> made that way.
> :-D
>
> well to be fair, I think they tried to implement some sort of
> complex blinking language code. You can tell apart if
> the device is idling/scanning/connected/sending in the 5GHz or 2GHz
> band just by looking at the blue and orange rhythms...
> (maybe this visual feedback is indeed easier to comprehend for the generic
> customer than any hard and honest numbers)
>
> But back to the topic:
> This elaborate morse code is clearly way beyond the scope and
> abilities of ledclass. I think we should really stick to the
> simple rule: one trigger corresponds to only one physical LED.
>
>> Anyway, I am just writing regarding the ONLY_ONE_LED construct and its
>> association with 0x0846:0x9001 ...
> hmm, not sure what I should do here...
> Do you think the driver should simply ignore the lack of a second LED (color)?
> Or is it just that the ONLY_ONE_LED construct sounds really lame
> and needs a more cunning name?
>
> Regards,
> Chr
>
Hmm, I mean the ONLY_ONE_LED config should not be a compiled in config
associated with an vid/pid, but dynamically determined from the
enumeration.
In the case of only one LED, the it sounds quite neat to represent
both assciation status and transmission status by blinking pattern
:-).
But one of them should take priority in case of conflict, and in this
regard it seems that you and I disagree on which should be.
^ permalink raw reply
* Re: 2.6.32-rc0-git: oops in wireless, iwl3945 related?
From: Johannes Berg @ 2009-10-01 21:16 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-kernel, yi.zhu, reinette.chatre, linux-wireless
In-Reply-To: <20090929171249.GB14405@elf.ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]
On Tue, 2009-09-29 at 19:12 +0200, Pavel Machek wrote:
>
> Happened while playing with wireless.
>
> Kernel is:
>
> Linux version 2.6.31 (pavel@amd) (gcc version 4.3.3 (Debian 4.3.3-10)
> ) #72 SMP Thu Sep 10 21:56:19 CEST 2009
> KERNEL supported cpus:
>
> (Could we get kernels between release and -rc1 mark themselves
> somehow?)
CONFIG_LOCALVERSION_AUTO?
> Registered led device: iwl-phy0::radio
> Registered led device: iwl-phy0::assoc
> Registered led device: iwl-phy0::RX
> Registered led device: iwl-phy0::TX
> wlan0: Selected IBSS BSSID 02:18:41:de:3f:02 based on configured SSID
> wlan0: Trigger new scan to find an IBSS to join
> wlan0: Trigger new scan to find an IBSS to join
> wlan0: Creating new IBSS network, BSSID f2:d3:80:82:ed:6a
> wlan0: Creating new IBSS network, BSSID 52:17:bf:45:d6:9d
> skb_over_panic: text:c07b4113 len:130 put:36 head:e4c3edf0
This entire log is very odd ... can you reproduce this easily? printk
timestamps would be useful.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: BUG: "wext: refactor" broke compilation
From: Johannes Berg @ 2009-10-01 21:14 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <200910011139.30914.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]
On Thu, 2009-10-01 at 11:39 +0200, Holger Schurig wrote:
> LD net/wireless/built-in.o
> CC [M] net/wireless/core.o
> net/wireless/core.c: In function 'cfg80211_netdev_notifier_call':
> net/wireless/core.c:673: error: 'struct wireless_dev' has no member named 'wext'
> net/wireless/core.c:674: error: 'struct wireless_dev' has no member named 'wext'
> net/wireless/core.c:675: error: 'struct wireless_dev' has no member named 'wext'
> net/wireless/core.c:676: error: 'struct wireless_dev' has no member named 'wext'
> net/wireless/core.c:677: error: 'struct wireless_dev' has no member named 'wext'
> net/wireless/core.c:680: error: 'struct wireless_dev' has no member named 'wext'
> net/wireless/core.c:681: error: 'struct wireless_dev' has no member named 'wext'
> net/wireless/core.c:683: error: 'struct wireless_dev' has no member named 'wext'
>
> The reason is that currently two different Kconfig
> defines are used:
>
>
> in net/wireless/core.c:
>
> #ifdef CONFIG_WIRELESS_EXT
> wdev->wext.default_key = -1;
> ...
> #endif
Did you send a patch to change that to CONFIG_CFG80211_WEXT, or do I
need to?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Linux-2.6.32-rc1/2] wext refactor needs wpasupplicant 0.7.0+?
From: Johannes Berg @ 2009-10-01 20:56 UTC (permalink / raw)
To: Sedat Dilek; +Cc: wireless
In-Reply-To: <2d0a357f0910011344u4306ecf6ha11410b0f5ed62e3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 656 bytes --]
On Thu, 2009-10-01 at 22:44 +0200, Sedat Dilek wrote:
>
> 1254429476.088527: ctrl_iface bind(PF_UNIX) failed: Address already in use
> 1254429476.088543: ctrl_iface exists and seems to be in use - cannot override it
> 1254429476.088548: Delete '/var/run/wpa_supplicant/wlan0' manually if it is not used anymore
> 1254429476.088563: Failed to initialize control interface '/var/run/wpa_supplicant'.
> You may have another wpa_supplicant process already running or the file was
> left by an unclean termination of wpa_supplicant in which case you will need
> to manually remove this file before starting wpa_supplicant again.
Umm...
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Linux-2.6.32-rc1/2] wext refactor needs wpasupplicant 0.7.0+?
From: Sedat Dilek @ 2009-10-01 20:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: wireless
In-Reply-To: <1254426421.3959.29.camel@johannes.local>
[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]
Here the logs for wpasupplicant v06.9 and v0.7.0.
$ wpa_supplicant -v
$ /sbin/wpa_supplicant -ddt -B -P /var/run/wpa_supplicant.wlan0.pid -i
wlan0 -D wext -C /var/run/wpa_supplicant
- Sedat -
On Thu, Oct 1, 2009 at 9:47 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Thu, 2009-10-01 at 11:47 +0200, Sedat Dilek wrote:
>
>> a few hours ago I compiled a new kernel from upstream and put
>> wireless-testing master-2009-09-30 on top of it.
>>
>> Last commit a1bec0ecfc76281d5e1ebd33435c67da7dd0fe71
>> wext: refactor
>>
>> linux-2.6/master:
>> 84d88d5: Merge branch 'sched-fixes-for-linus' of
>> git://git./linux/kernel/git/tip/linux-2.6-tip
>>
>> After installation of the above described kernel, I could not connect
>> to my AP using wext driver and wpasupplicant (0.6.9-3) from Debian/sid
>> [1].
>> With ath5k I could not establish a network connection neither via DHCP
>> nor via static-IP to my AP (iwl3945 on a second machine works with
>> self-debianized wpasupplicant 0.7.0+ and static-IP, same kernel).
>>
>> Just for clarification:
>> Does wext refactor need a wpasupplicant >= 0.7.0 from hostap GIT repository [2]?
>
> Should be ok. Can we see wpa_supplicant -ddt log please?
>
> johannes
>
[-- Attachment #2: wpasupplicant-069.txt --]
[-- Type: text/plain, Size: 3646 bytes --]
wpa_supplicant v0.6.9
Copyright (c) 2003-2009, Jouni Malinen <j@w1.fi> and contributors
1254429474.982896: Initializing interface 'wlan0' conf 'N/A' driver 'wext' ctrl_interface '/var/run/wpa_supplicant' bridge 'N/A'
1254429475.079713: Interface wlan0 set UP - waiting a second for the driver to complete initialization
1254429476.080009: SIOCGIWRANGE: WE(compiled)=22 WE(source)=21 enc_capa=0xf
1254429476.080032: capabilities: key_mgmt 0xf enc 0xf flags 0x0
1254429476.084533: WEXT: Operstate: linkmode=1, operstate=5
1254429476.084633: Own MAC address: 00:05:4e:46:b4:1f
1254429476.084644: wpa_driver_wext_set_wpa
1254429476.084658: wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
1254429476.084677: wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0
1254429476.084689: wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0
1254429476.084699: wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0
1254429476.084710: wpa_driver_wext_set_countermeasures
1254429476.084717: wpa_driver_wext_set_drop_unencrypted
1254429476.084724: RSN: flushing PMKID list in the driver
1254429476.084792: Setting scan request: 0 sec 100000 usec
1254429476.084849: WPS: UUID based on MAC address - hexdump(len=16): 55 2a 23 9b 14 1f 53 7a 89 c6 98 d8 83 ac a7 26
1254429476.084876: WPS: Build Beacon and Probe Response IEs
1254429476.084888: WPS: * Version
1254429476.084896: WPS: * Wi-Fi Protected Setup State (0)
1254429476.084904: WPS: * Version
1254429476.084908: WPS: * Wi-Fi Protected Setup State (0)
1254429476.084913: WPS: * Response Type (2)
1254429476.084921: WPS: * UUID-E
1254429476.084928: WPS: * Manufacturer
1254429476.084933: WPS: * Model Name
1254429476.084938: WPS: * Model Number
1254429476.084942: WPS: * Serial Number
1254429476.084946: WPS: * Primary Device Type
1254429476.084951: WPS: * Device Name
1254429476.084955: WPS: * Config Methods (0)
1254429476.084960: WPS: * RF Bands (3)
1254429476.088433: EAPOL: SUPP_PAE entering state DISCONNECTED
1254429476.088441: EAPOL: KEY_RX entering state NO_KEY_RECEIVE
1254429476.088448: EAPOL: SUPP_BE entering state INITIALIZE
1254429476.088458: EAP: EAP entering state DISABLED
1254429476.088486: Using existing control interface directory.
1254429476.088527: ctrl_iface bind(PF_UNIX) failed: Address already in use
1254429476.088543: ctrl_iface exists and seems to be in use - cannot override it
1254429476.088548: Delete '/var/run/wpa_supplicant/wlan0' manually if it is not used anymore
1254429476.088563: Failed to initialize control interface '/var/run/wpa_supplicant'.
You may have another wpa_supplicant process already running or the file was
left by an unclean termination of wpa_supplicant in which case you will need
to manually remove this file before starting wpa_supplicant again.
1254429476.088573: Failed to add interface wlan0
1254429476.088582: State: DISCONNECTED -> DISCONNECTED
1254429476.088592: wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
1254429476.088599: WEXT: Operstate: linkmode=-1, operstate=5
1254429476.088615: No keys have been configured - skip key clearing
1254429476.088621: EAPOL: External notification - portEnabled=0
1254429476.088628: EAPOL: External notification - portValid=0
1254429476.088633: wpa_driver_wext_set_wpa
1254429476.088642: wpa_driver_wext_set_drop_unencrypted
1254429476.088649: wpa_driver_wext_set_countermeasures
1254429476.088655: No keys have been configured - skip key clearing
1254429476.089339: Cancelling scan request
1254429476.089349: Cancelling authentication timeout
1254429476.089411: WEXT: Operstate: linkmode=0, operstate=6
[-- Attachment #3: wpasupplicant-070.txt --]
[-- Type: text/plain, Size: 3961 bytes --]
wpa_supplicant v0.7.0
Copyright (c) 2003-2009, Jouni Malinen <j@w1.fi> and contributors
1254429555.677208: Initializing interface 'wlan0' conf 'N/A' driver 'wext' ctrl_interface '/var/run/wpa_supplicant' bridge 'N/A'
1254429555.733937: Interface wlan0 set UP - waiting a second for the driver to complete initialization
1254429556.734139: SIOCGIWRANGE: WE(compiled)=22 WE(source)=21 enc_capa=0xf
1254429556.734160: capabilities: key_mgmt 0xf enc 0xf flags 0x0
1254429556.737759: WEXT: Operstate: linkmode=1, operstate=5
1254429556.737818: Own MAC address: 00:05:4e:46:b4:1f
1254429556.737825: wpa_driver_wext_set_wpa
1254429556.737831: wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
1254429556.737841: wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0
1254429556.737846: wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0
1254429556.737851: wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0
1254429556.737855: wpa_driver_wext_set_countermeasures
1254429556.737858: wpa_driver_wext_set_drop_unencrypted
1254429556.737861: RSN: flushing PMKID list in the driver
1254429556.737879: Setting scan request: 0 sec 100000 usec
1254429556.737948: WPS: UUID based on MAC address - hexdump(len=16): 55 2a 23 9b 14 1f 53 7a 89 c6 98 d8 83 ac a7 26
1254429556.737959: WPS: Build Beacon and Probe Response IEs
1254429556.737965: WPS: * Version
1254429556.737968: WPS: * Wi-Fi Protected Setup State (0)
1254429556.737972: WPS: * Version
1254429556.737974: WPS: * Wi-Fi Protected Setup State (0)
1254429556.737977: WPS: * Response Type (2)
1254429556.737979: WPS: * UUID-E
1254429556.737982: WPS: * Manufacturer
1254429556.737984: WPS: * Model Name
1254429556.737986: WPS: * Model Number
1254429556.737988: WPS: * Serial Number
1254429556.737991: WPS: * Primary Device Type
1254429556.737993: WPS: * Device Name
1254429556.737995: WPS: * Config Methods (0)
1254429556.737997: WPS: * RF Bands (3)
1254429556.739312: EAPOL: SUPP_PAE entering state DISCONNECTED
1254429556.739316: EAPOL: Supplicant port status: Unauthorized
1254429556.739319: EAPOL: KEY_RX entering state NO_KEY_RECEIVE
1254429556.739321: EAPOL: SUPP_BE entering state INITIALIZE
1254429556.739325: EAP: EAP entering state DISABLED
1254429556.739328: EAPOL: Supplicant port status: Unauthorized
1254429556.739331: EAPOL: Supplicant port status: Unauthorized
1254429556.739343: Using existing control interface directory.
1254429556.739361: ctrl_iface bind(PF_UNIX) failed: Address already in use
1254429556.739371: ctrl_iface exists and seems to be in use - cannot override it
1254429556.739373: Delete '/var/run/wpa_supplicant/wlan0' manually if it is not used anymore
1254429556.739380: Failed to initialize control interface '/var/run/wpa_supplicant'.
You may have another wpa_supplicant process already running or the file was
left by an unclean termination of wpa_supplicant in which case you will need
to manually remove this file before starting wpa_supplicant again.
1254429556.739385: Failed to add interface wlan0
1254429556.739388: No keys have been configured - skip key clearing
1254429556.739391: State: DISCONNECTED -> DISCONNECTED
1254429556.739396: wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
1254429556.739399: WEXT: Operstate: linkmode=-1, operstate=5
1254429556.739407: EAPOL: External notification - portEnabled=0
1254429556.739410: EAPOL: Supplicant port status: Unauthorized
1254429556.739412: EAPOL: External notification - portValid=0
1254429556.739415: EAPOL: Supplicant port status: Unauthorized
1254429556.739418: wpa_driver_wext_set_wpa
1254429556.739422: wpa_driver_wext_set_drop_unencrypted
1254429556.739425: wpa_driver_wext_set_countermeasures
1254429556.739428: No keys have been configured - skip key clearing
1254429556.739682: Cancelling scan request
1254429556.739686: Cancelling authentication timeout
1254429556.739704: WEXT: Operstate: linkmode=0, operstate=6
^ permalink raw reply
* Re: [PATCH] ar9170usb: LEDs are confused
From: Christian Lamparter @ 2009-10-01 20:34 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Malte Gell, linux-wireless, Luis R. Rodriguez, linville
In-Reply-To: <3ace41890910011106p2609e928ycbc930a75ae2fb98@mail.gmail.com>
On Thursday 01 October 2009 20:06:35 Hin-Tak Leung wrote:
> On Thu, Oct 1, 2009 at 3:54 PM, Christian Lamparter
> <chunkeey@googlemail.com> wrote:
> > On 2009-10-01 06:32 AM, Malte Gell wrote:
> >>I first noticed the LEDs are confused,
> > no, the LED colors are not _confused_ at all.
> > This is simply different on.... well, you know: on a per-device base!
> >
> > For example: The Netgear uses a single bi-color LED for their WNDA3100 stick.
> > It glows blue or/and orange depending on the selected band and current
> > operation mode and state...
> >
> > No idea why they didn't stick to the usual red/green mix.
> > Maybe because someone told the hw-devs about the existence of
> > red/green colorblind people??!
> >
> > The original vendor driver (located: drivers/staging/otus/80211core/ledmgr.c)
> > goes to great lengths to describe what's behind the variety of
> > blinking signals. Which is nice, if you like expensive light shows...
>
> This is just based on my brief look at the relevant code itself - I
> think the driver actually enumerates how many LEDs the device has, so
> the ONLY_ONE_LED construct is a bit bogus. Also I think the
> 0x0846:0x9001 is Malte's with swapped LEDs, not ONLY_ONE?
?
0x0846:0x9001 is a Netgear WN111 v2.
(one LED reference: otus' ledmgr.c ~line 547)
and AFAIK: Malte uses an AVM FRITZ!WLAN Stick N (2.4?).
> I had a look when Malte first wrote about the swap - the code
> basically just do assoc/data-tx in enumeration order (first LED found
> is assoc, 2nd is tx, which make sense if some variant only have a
> LED).
Depends. I think it's more important to have some sort of an "an activity LED"
than a connection indicator, because most desktops-guis nowadays have lots
of fancy applets which are constantly monitoring your connection status and
start to bark as soon as it changes...
BTW: my laptop (with an IWL 5300) only has one LED assigned for wlan as well.
But, someone had the genius idea to put the activity LED into _inverted_
mode when the connection is established. It stays on after association
and flashes under TX activity... This is nice, but it has a downside:
two trigger _drive_ one LED => no real exclusive access anymore.
If you want to reassign the LEDs the clueless user has to be aware about
this trigger dependency, or he see some _blinking interference_.
> As for the color - it is probably just a matter of commercial
> interests (if they can get a particular color from a source cheaper)
unlikely, the bi-color LED is a super bright one.
> or simply variety to catch some customers - as you say, some *do* like
> expensive light shows, and there is a market for it and money to be
> made that way.
:-D
well to be fair, I think they tried to implement some sort of
complex blinking language code. You can tell apart if
the device is idling/scanning/connected/sending in the 5GHz or 2GHz
band just by looking at the blue and orange rhythms...
(maybe this visual feedback is indeed easier to comprehend for the generic
customer than any hard and honest numbers)
But back to the topic:
This elaborate morse code is clearly way beyond the scope and
abilities of ledclass. I think we should really stick to the
simple rule: one trigger corresponds to only one physical LED.
> Anyway, I am just writing regarding the ONLY_ONE_LED construct and its
> association with 0x0846:0x9001 ...
hmm, not sure what I should do here...
Do you think the driver should simply ignore the lack of a second LED (color)?
Or is it just that the ONLY_ONE_LED construct sounds really lame
and needs a more cunning name?
Regards,
Chr
^ permalink raw reply
* Re: [PATCH 0/2] cfg80211: firmware and hardware version
From: Luis R. Rodriguez @ 2009-10-01 19:56 UTC (permalink / raw)
To: John W. Linville, Perez-Gonzalez, Inaky
Cc: Kalle Valo, linux-wireless, netdev
In-Reply-To: <20091001170722.GC2895@tuxdriver.com>
On Thu, Oct 1, 2009 at 5:07 PM, John W. Linville <linville@tuxdriver.com> wrote:
> I don't predict a huge problem if there are
> valid extensions required for use by wireless drivers in the future.
> But for now, I'd like to see us make use of some of the debugging
> facilities available in the ethtool API -- hopefully the iwlwifi guys
> are listening... ;-)
Does the same apply to wimax then? Ethtool for 802.11 and wimax? Eh.
Luis
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox