Re: 2.6.20-rc2: known unfixed regressions (v2)
31 Ara 2006 Paz 02:47 tarihinde, Adrian Bunk şunları yazmıştı: [...] > Subject: ALSA: No sound in KDE with intel hda > References : http://lkml.org/lkml/2006/12/30/73 > Submitter : Ismail Dönmez <[EMAIL PROTECTED]> > Status : unknown Just tried with 2.6.18.6 and aRts still have no sound, there must be something else broken on my side. Thanks, ismail -- 2 + 2 = 5 for very large values of 2 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx-d80211: Interrogate hardware-enable switch and update LEDs
On Sunday 31 December 2006 06:25, Larry Finger wrote:
> The current bcm43xx driver ignores any wireless-enable switches on mini-PCI
> and mini-PCI-E cards. This patch implements a new routine to interrogate the
> radio hardware enabled bit in the interface, logs the initial state and any
> changes in the switch (if debugging enabled), activates the LED to show the
> state, and changes the periodic work handler to provide 1 second response
> to switch changes and to account for changes in the periodic work specs. It
> also incorporates changes in the LED state that were accepted into mainline
> some time ago.
>
> Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
> ---
>
> Michael,
>
> This patch is for wireless-idev, and is the same as the patch recently
> submitted for bcm43xx-softmac. These changes have been tested on
> a PCMCIA card with no wireless switch, A BCM4306 mini-PCI card, and
> a BCM4311 mini-PCIE card.
>
> Larry
>
>
> Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c
> +++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.c
> @@ -26,6 +26,7 @@
> */
>
> #include "bcm43xx_leds.h"
> +#include "bcm43xx_radio.h"
> #include "bcm43xx.h"
>
> #include
> @@ -108,6 +109,7 @@ static void bcm43xx_led_init_hardcoded(s
> switch (led_index) {
> case 0:
> led->behaviour = BCM43xx_LED_ACTIVITY;
> + led->activelow = 1;
> if (bcm->board_vendor == PCI_VENDOR_ID_COMPAQ)
> led->behaviour = BCM43xx_LED_RADIO_ALL;
> break;
> @@ -189,26 +191,31 @@ void bcm43xx_leds_update(struct bcm43xx_
> case BCM43xx_LED_INACTIVE:
> continue;
> case BCM43xx_LED_OFF:
> + case BCM43xx_LED_BCM4303_3:
> break;
> case BCM43xx_LED_ON:
> turn_on = 1;
> break;
> case BCM43xx_LED_ACTIVITY:
> + case BCM43xx_LED_BCM4303_0:
> turn_on = activity;
> break;
> case BCM43xx_LED_RADIO_ALL:
> - turn_on = radio->enabled;
> + turn_on = radio->enabled &&
> bcm43xx_is_hw_radio_enabled(bcm);
> break;
> case BCM43xx_LED_RADIO_A:
> - turn_on = (radio->enabled && phy->type ==
> BCM43xx_PHYTYPE_A);
> + case BCM43xx_LED_BCM4303_2:
> + turn_on = (radio->enabled &&
> bcm43xx_is_hw_radio_enabled(bcm) &&
> +phy->type == BCM43xx_PHYTYPE_A);
> break;
> case BCM43xx_LED_RADIO_B:
> - turn_on = (radio->enabled &&
> + case BCM43xx_LED_BCM4303_1:
> + turn_on = (radio->enabled &&
> bcm43xx_is_hw_radio_enabled(bcm) &&
> (phy->type == BCM43xx_PHYTYPE_B ||
> phy->type == BCM43xx_PHYTYPE_G));
> break;
> case BCM43xx_LED_MODE_BG:
> - if (phy->type == BCM43xx_PHYTYPE_G &&
> + if (phy->type == BCM43xx_PHYTYPE_G &&
> bcm43xx_is_hw_radio_enabled(bcm) &&
> 1/*FIXME: using G rates.*/)
> turn_on = 1;
> break;
> @@ -257,7 +264,8 @@ void bcm43xx_leds_update(struct bcm43xx_
> continue;
> #endif /* CONFIG_BCM43XX_DEBUG */
> default:
> - assert(0);
> + dprintkl(KERN_INFO PFX "Bad value in leds_update,"
> + " led->behaviour: 0x%x\n", led->behaviour);
> };
>
> if (led->activelow)
> Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.h
> ===
> --- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.h
> +++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_leds.h
> @@ -46,6 +46,12 @@ enum { /* LED behaviour values */
> BCM43xx_LED_TEST_BLINKSLOW,
> BCM43xx_LED_TEST_BLINKMEDIUM,
> BCM43xx_LED_TEST_BLINKFAST,
> +
> + /* Misc values for BCM4303 */
> + BCM43xx_LED_BCM4303_0 = 0x2B,
> + BCM43xx_LED_BCM4303_1 = 0x78,
> + BCM43xx_LED_BCM4303_2 = 0x2E,
> + BCM43xx_LED_BCM4303_3 = 0x19,
> };
>
> int bcm43xx_leds_init(struct bcm43xx_private *bcm);
> Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
> ===
> --- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
> +++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bc
Re: [OOPS] bcm43xx oops on 2.6.20-rc1 on x86_64
On Sat, Dec 30, 2006 at 04:45:21PM -0600, Larry Finger wrote: > Adrian Bunk wrote: > > On Sat, Dec 30, 2006 at 03:23:42PM -0600, Larry Finger wrote: > >> Adrian Bunk wrote: > >>> On Sun, Dec 17, 2006 at 03:15:28PM -0500, Aaron Sethman wrote: > Just was loading the bcm43xx module and got the following oops. Note > that > this card is one of the newer PCI-E cards. If any other info is needed > let me know. > >>> Is this issue still present in 2.6.10-rc2-git1? > >>> > >>> If yes, was 2.6.19 working fine? > >> ... > >> > >> Any oops involving wireless extensions is due to 2.6.20-rc1 and -rc2 not > >> having the fix for softmac > >> that is necessitated by the 2.6.20 changes in the work structure. > > > > "Any oops" are very strong words. > > Yes - but I have seen at least 7 or 8 different occurrences of that bug since > the patch was first > made available on Dec. 10, and I have seen no bcm43xx oopses from any other > cause. >... To avoid any misunderstandings: This wasn't in any way meant against you personally. And in this case you were right, it was the same bug. My answer was based on experiences like one during 2.6.19-rc where we had 4 bug reports for a regression with a patch available. And it turned out that one of them was for a completely different regression. That's why I prefer to get confirmations that a user actually run into the same issue, and not into something completely different with similar symptoms. > Larry cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [OOPS] bcm43xx oops on 2.6.20-rc1 on x86_64
Adrian Bunk wrote: > > To avoid any misunderstandings: > > This wasn't in any way meant against you personally. > > And in this case you were right, it was the same bug. > > My answer was based on experiences like one during 2.6.19-rc where we > had 4 bug reports for a regression with a patch available. And it turned > out that one of them was for a completely different regression. > > That's why I prefer to get confirmations that a user actually run into > the same issue, and not into something completely different with similar > symptoms. I certainly understood your intent and agree that confirmation is necessary. I was venting some frustration at it taking nearly 3 weeks to get a fix into the system for a bug that was caused by a change in an kernel structure that was not our doing. When Andrew posted a trial patch to fix the compilation error that resulted, I immediately responded with the two additional fixes that were needed, but they never made it into the code. Since then I have been seeing these obscure bug reports and quickly learned that if either softmac or bcm43xx WX were involved, this fix took care of the problem. Larry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net/core/flow.c: compare data with memcmp
From: Daniel Marjamäki
This has been tested by me.
Signed-off-by: Daniel Marjamäki <[EMAIL PROTECTED]>
--- linux-2.6.20-rc2/net/core/flow.c2006-12-27 09:59:56.0 +0100
+++ linux/net/core/flow.c 2006-12-31 18:26:06.0 +0100
@@ -144,29 +144,16 @@ typedef u32 flow_compare_t;
extern void flowi_is_missized(void);
-/* I hear what you're saying, use memcmp. But memcmp cannot make
- * important assumptions that we can here, such as alignment and
- * constant size.
- */
static int flow_key_compare(struct flowi *key1, struct flowi *key2)
{
- flow_compare_t *k1, *k1_lim, *k2;
- const int n_elem = sizeof(struct flowi) / sizeof(flow_compare_t);
-
if (sizeof(struct flowi) % sizeof(flow_compare_t))
flowi_is_missized();
- k1 = (flow_compare_t *) key1;
- k1_lim = k1 + n_elem;
-
- k2 = (flow_compare_t *) key2;
-
- do {
- if (*k1++ != *k2++)
- return 1;
- } while (k1 < k1_lim);
+ /* Number of elements to compare */
+ const int n_elem = sizeof(struct flowi) / sizeof(flow_compare_t);
- return 0;
+ /* Compare all elements in key1 and key2. */
+ return memcmp(key1, key2, n_elem * sizeof(flow_compare_t));
}
void *flow_cache_lookup(struct flowi *key, u16 family, u8 dir,
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
d80211-drivers pull request (week51)
Hi John,
Please pull
git://git.kernel.org/pub/scm/linux/kernel/git/mwu/d80211-drivers.git
for these patches:
adm8211-week51 branch:
adm8211: set phymode in RX
p54-week51 branch:
p54: fix device memory allocator
p54: fix TX of encrypted frames
p54: remove unnecessary use of __constant_cpu_to_*
p54: use hardware RX frequency reporting
p54: use link LED
p54: fix issues found by sparse
p54: set phymode in RX
zd1211rw-week51 branch:
zd1211rw-d80211: Fix of a locking bug
zd1211rw-d80211: Revert "zd1211rw: Removed unneeded packed attributes"
zd1211rw-d80211: Add 3 more device IDs
zd1211rw-d80211: Add ID for ZyXEL G-220
zd1211rw-d80211: Add ID for Planex GW-US54Mini
zd1211rw-d80211: Add ID for Belkin F5D7050 v4000
zd1211rw-d80211: cleanups
zd1211rw-d80211: Optimized handling of zero length entries in length info
zd1211rw-d80211: check IEEE80211_TXCTL_USE_CTS_PROTECT
zd1211rw-d80211: Use ieee80211_tx_status
zd1211rw-d80211: 2 new ZD1211B device ID's
zd1211rw-d80211: Add ID for Linksys WUSBF54G
The LED class patch for zd1211rw-d80211 was dropped.
A patch which updates zd1211rw-d80211 to the new workqueue API is attached
for when you pull those changes.
Thanks,
-Michael Wu
zd1211rw-d80211: fix workqueue breakage
From: Michael Wu <[EMAIL PROTECTED]>
This allows zd1211rw-d80211 to compile with the workqueue API changes.
Signed-off-by: Michael Wu <[EMAIL PROTECTED]>
---
drivers/net/wireless/d80211/zd1211rw/zd_mac.c |7 ---
drivers/net/wireless/d80211/zd1211rw/zd_mac.h |2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/d80211/zd1211rw/zd_mac.c b/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
index 6ee650f..7044ea3 100644
--- a/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
@@ -625,9 +625,10 @@ struct ieee80211_hw *zd_mac_alloc(struct
#define LINK_LED_WORK_DELAY HZ
-static void link_led_handler(void *p)
+static void link_led_handler(struct work_struct *work)
{
- struct zd_mac *mac = p;
+ struct zd_mac *mac =
+ container_of(work, struct zd_mac, housekeeping.link_led_work);
struct zd_chip *chip = &mac->chip;
int is_associated;
int r;
@@ -647,7 +648,7 @@ static void link_led_handler(void *p)
static void housekeeping_init(struct zd_mac *mac)
{
- INIT_WORK(&mac->housekeeping.link_led_work, link_led_handler, mac);
+ INIT_DELAYED_WORK(&mac->housekeeping.link_led_work, link_led_handler);
}
static void housekeeping_enable(struct zd_mac *mac)
diff --git a/drivers/net/wireless/d80211/zd1211rw/zd_mac.h b/drivers/net/wireless/d80211/zd1211rw/zd_mac.h
index e2ba410..6c402d9 100644
--- a/drivers/net/wireless/d80211/zd1211rw/zd_mac.h
+++ b/drivers/net/wireless/d80211/zd1211rw/zd_mac.h
@@ -119,7 +119,7 @@ enum mac_flags {
};
struct housekeeping {
- struct work_struct link_led_work;
+ struct delayed_work link_led_work;
};
#define ZD_MAC_STATS_BUFFER_SIZE 16
pgpm7T0K5zliF.pgp
Description: PGP signature
Re: [KJ] [PATCH] net/core/flow.c: compare data with memcmp
On 31.12.2006 [17:37:05 +0100], Daniel Marjam?ki wrote:
> From: Daniel Marjamäki
> This has been tested by me.
> Signed-off-by: Daniel Marjamäki <[EMAIL PROTECTED]>
> --- linux-2.6.20-rc2/net/core/flow.c 2006-12-27 09:59:56.0 +0100
> +++ linux/net/core/flow.c 2006-12-31 18:26:06.0 +0100
> @@ -144,29 +144,16 @@ typedef u32 flow_compare_t;
>
> extern void flowi_is_missized(void);
>
> -/* I hear what you're saying, use memcmp. But memcmp cannot make
> - * important assumptions that we can here, such as alignment and
> - * constant size.
> - */
> static int flow_key_compare(struct flowi *key1, struct flowi *key2)
> {
> - flow_compare_t *k1, *k1_lim, *k2;
> - const int n_elem = sizeof(struct flowi) / sizeof(flow_compare_t);
> -
> if (sizeof(struct flowi) % sizeof(flow_compare_t))
> flowi_is_missized();
>
> - k1 = (flow_compare_t *) key1;
> - k1_lim = k1 + n_elem;
> -
> - k2 = (flow_compare_t *) key2;
> -
> - do {
> - if (*k1++ != *k2++)
> - return 1;
> - } while (k1 < k1_lim);
> + /* Number of elements to compare */
> + const int n_elem = sizeof(struct flowi) / sizeof(flow_compare_t);
>
> - return 0;
> + /* Compare all elements in key1 and key2. */
> + return memcmp(key1, key2, n_elem * sizeof(flow_compare_t));
> }
Small nit, I don't think either of your comments make the code any
clearer than the code on its own, so drop them both.
Thanks,
Nish
--
Nishanth Aravamudan <[EMAIL PROTECTED]>
IBM Linux Technology Center
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/core/flow.c: compare data with memcmp
From: "Daniel_Marjamäki" <[EMAIL PROTECTED]> Date: Sun, 31 Dec 2006 17:37:05 +0100 > From: Daniel Marjamäki > This has been tested by me. > Signed-off-by: Daniel Marjamäki <[EMAIL PROTECTED]> Please do not do this. memcmp() cannot assume the alignment of the source and destination buffers and thus will run more slowly than that open-coded comparison. That code was done like that on purpose because it is one of the most critical paths in the networking flow cache lookup which runs for every IPSEC packet going throught the system. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 7757] New: ip_conntrack:table full, dropping connection after kernel update
On Sun, 31 Dec 2006 19:03:34 -0800 [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=7757 > >Summary: ip_conntrack:table full, dropping connection after > kernel update > Kernel Version: 2.6.19.1 > Status: NEW > Severity: normal > Owner: [EMAIL PROTECTED] > Submitter: [EMAIL PROTECTED] > > > Most recent kernel where this bug did *NOT* occur:2.6.10 > Distribution:Kubuntu > Hardware Environment:AMD64X2, Geforce6100 North, NForce 430 South, forcedeth > driver > Software Environment: > Problem Description:dmesg shows above/dead network. netstat shows piles of > FIN_WAIT1 connections, using same /proc/sys/net/ipv4 settings > > Steps to reproduce: Update Edgy 2.6.17-10 kernel with vanilla &.1 patch. > Turned > on DMA engine, and nv_sata with k7 (32 bit kernel) optimizations (only > changes). > Used GTK-gnutella or any p2p that really wrings out the ip stack. A few > hours > later bandwidth slows to a crawl and only currently open connections are > alive. > > Bring down the network and bringing it back up to clear the tables doesn't > remove the fin_wait1's. Any workarounds or maybe a new setting that I > overlooked that the kernel needs would be greatly appc'd. > > Cheers. > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/core/flow.c: compare data with memcmp
Hello! So you mean that in this particular case it's faster with a handcoded comparison than memcmp? Because both key1 and key2 are located at word-aligned addresses? That's fascinating. Best regards, Daniel 2006/12/31, David Miller <[EMAIL PROTECTED]>: From: "Daniel_Marjamäki" <[EMAIL PROTECTED]> Date: Sun, 31 Dec 2006 17:37:05 +0100 > From: Daniel Marjamäki > This has been tested by me. > Signed-off-by: Daniel Marjamäki <[EMAIL PROTECTED]> Please do not do this. memcmp() cannot assume the alignment of the source and destination buffers and thus will run more slowly than that open-coded comparison. That code was done like that on purpose because it is one of the most critical paths in the networking flow cache lookup which runs for every IPSEC packet going throught the system. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
