Andrew Morton wrote:
That's a bit surprising - the initcall levels don't affect modules.
Presumably something went wrong in core kernel which later caused yenta
and/or 8139too to fail.
Have you tried diffing the before- and after-dmesgs to see if that particular
commit has caused any
Andrew Morton wrote:
On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx [EMAIL PROTECTED] wrote:
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
Will appear later at
When I configure 'CPU Idle PM Support' on my HP dv2125nr notebook with a Turion
X64 X2 processor and
X86_64 architecture selected, the computer freezes on bootup. I have included a
portion the
configuration file and part of /var/log/boot.msg for my working system. Please
let me know if
further
Matt Mackall wrote:
With the latest -mm, I'm now getting this:
Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless
2200BG Network Connection
Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected
value (0)
Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw
Matt Mackall wrote:
With the latest -mm, I'm now getting this:
Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless
2200BG Network Connection
Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected
value (0)
Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw
Andrew Morton wrote:
On Tue, 20 Mar 2007 17:23:54 -0600 Zan Lynx [EMAIL PROTECTED] wrote:
On Mon, 2007-03-19 at 20:56 -0800, Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
Will appear later at
Cornelia Huck wrote:
On Thu, 22 Mar 2007 07:23:06 -0500,
This would indicate that dev_uevent had been called. But how could
kobject_uevent then return an error without moaning about an uevent()
error code? Maybe the following debug patch could shed some light on
this (all moaning is
Cornelia Huck wrote:
On Thu, 22 Mar 2007 13:55:51 -0500,
Larry Finger [EMAIL PROTECTED] wrote:
I applied the debug patch, but I don't see any error codes being returned.
This time I also got the
General Protection Faults. An excerpt of the log is attached.
Hm, I think I have an idea about
Zan Lynx wrote:
It may have partly been a problem of having half of softmac and half
devicescape. I'm not entirely sure what udev did.
I tried a patch for the Sonic Silicon that was posted and I turned off
all the configuration for the softmac driver.
It isn't crashing right now but
With the following line in /etc/modprobe.conf.local:
options bcm43xx fwpostfix = .fw3 locale=8
the kernel oops below is generated. I realize that the line should have no whitespace around the
=, but I do not feel that an oops is the best way to report the syntax error. Could there be a
more
Randy Dunlap wrote:
On Sat, 07 Apr 2007 19:21:01 -0500 Larry Finger wrote:
With the following line in /etc/modprobe.conf.local:
options bcm43xx fwpostfix = .fw3 locale=8
the kernel oops below is generated. I realize that the line should have no whitespace around the
=, but I do not feel
Pavel Machek wrote:
Hi!
-stable review patch. If anyone has any objections, please let us know.
--
From: Larry Finger [EMAIL PROTECTED]
There is a kernel oops on bcm43xx when resuming due to an overly tight
timeout loop.
Signed-off-by: Larry Finger [EMAIL PROTECTED
Michael Buesch wrote:
On Saturday 03 March 2007 20:03, Sam Ravnborg wrote:
Replacing use of UTS_RELEASE with utsname()-release
avoids that this module is rebuild each
time the kernel version changes.
Compile tested only.
I vote to get rid of the whole bcm43xx_ethtool.c file, as it's
The code sequence
u32 macstat;
.
macstat = le32_to_cpu(rxhdr-mac_status);
generates the following sparse warnings
drivers/net/wireless/b43legacy/xmit.c:446:12: warning: cast to restricted type
drivers/net/wireless/b43legacy/xmit.c:446:12: warning: cast from restricted type
For those variants of BCM43xx cards that use 64-bit DMA, there is a requirement
that all descriptor
rings must be aligned on an 8K boundary and must fit within an 8K page. On the
x86_64 architecture
where the page size is 4K, I was getting addresses like 0x67AF000 when using
dma_alloc_coherent
Theodore Tso wrote:
On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote:
Btw, I used to test every -mm kernel. But since I've switched distros
(gentoo-ubuntu)
and I have less time, I feel it's harder to test -rc or -mm kernels (I
know this isn't a lkml problem
but more a distro
Theodore Tso wrote:
Heh. I hadn't enabled CONFIG_BCM43XX_DEBUG myself, but I just changed
it for my next kernel build. This is a slightly different issue,
which is that sometimes _DEBUG options shouldn't be turned on by
default (because they really trash performance and bloat log size),
Andi Kleen wrote:
Larry Finger [EMAIL PROTECTED] writes:
For those variants of BCM43xx cards that use 64-bit DMA, there is a
requirement that all descriptor
rings must be aligned on an 8K boundary and must fit within an 8K page. On
the x86_64 architecture
where the page size is 4K, I
Ingo Molnar wrote:
* Mark Lord [EMAIL PROTECTED] wrote:
You're assuming that everything in linux-2.6 was downloaded; that's
not true. Everything in linux-2.6/.git was downloaded; but then you
do a checkout which happens to approximately double the size of the
linux-2.6 directory.
..
I get a failure of 64-bit DMA on a BCM94311MCG rev 02 wireless interface
running on x86_64 using an
AMD Turion 64 X2 processor on an HP Pavilion dv2125nr laptop. The error code
indicates that the
interface is getting a descriptor read error, even though the descriptor ring
and all the DMA
Arjan van de Ven wrote:
On Sun, 18 Nov 2007 18:04:51 -0600
Larry Finger [EMAIL PROTECTED] wrote:
I get a failure of 64-bit DMA on a BCM94311MCG rev 02 wireless
interface running on x86_64 using an AMD Turion 64 X2 processor on an
HP Pavilion dv2125nr laptop. The error code indicates
[EMAIL PROTECTED] wrote:
On Dec 15, 2007 7:38 AM, [EMAIL PROTECTED] wrote:
I'll build latest wireless git without ipv6 late tonight.
Ok, built and tested, and it's actually faster! Although still not as
fast as bcm43xx or softmac or whatever the problem is, I was getting a
steady 200 kB/s
[EMAIL PROTECTED] wrote:
I don't know what happened before, but after a reboot, I can't repeat
the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I
didn't move the laptop, or the ap, the only thing I can think of that
might have changed is the noise level. FWIW, link
[EMAIL PROTECTED] wrote:
Larry, thanks for being so patient so far. Tomorrow I plan to take my
laptop to somewhere with coffee and a wireless network. For now
though, can you tell me if these messages could be related:
PCI: Cannot allocate resource region 7 of bridge :00:05.0
PCI: Cannot
With 2.6.24-rc5, a b43 user reports a problem at bootup. The b43 module, which
should be loaded by
the ssb module, fails with the following type of message:
ssb: Sonics Silicon Backplane found on PCI device :0c:00.0
b43: disagrees about version of symbol ssb_device_is_enabled
b43: Unknown
Shourya Sarcar wrote:
Larry Finger wrote:
With 2.6.24-rc5, a b43 user reports a problem at bootup. The b43
module, which should be loaded by the ssb module, fails with the
following type of message:
ssb: Sonics Silicon Backplane found on PCI device :0c:00.0 b43:
disagrees about version
Ray Lee wrote:
Hey there Larry, all,
git blame fingered commit id efe870f9 (from Larry) for adding a couple
of fairly harmless looking messages to
net/ieee80211/softmac/ieee80211softmac_wx.c . The problem is that one
of them is clogging up my syslog at the tune of once a second or so
(SoftMAC:
If a particular routine needs to lock a mutex, but it may be entered with that
mutex already locked,
would the following code be SMP safe?
hold_lock = mutex_trylock()
...
if (hold_lock)
mutex_unlock()
Thanks,
Larry
-
To unsubscribe from this list: send the line unsubscribe
Robert Hancock wrote:
Larry Finger wrote:
If a particular routine needs to lock a mutex, but it may be entered
with that mutex already locked,
would the following code be SMP safe?
hold_lock = mutex_trylock()
..
if (hold_lock)
mutex_unlock()
Not if another task could be acquiring
Matthias Kaehlcke wrote:
El Tue, Nov 27, 2007 at 10:37:00PM -0600 Larry Finger ha dit:
If a particular routine needs to lock a mutex, but it may be entered with
that mutex already locked,
would the following code be SMP safe?
hold_lock = mutex_trylock()
...
if (hold_lock
Andreas Schwab wrote:
Larry Finger [EMAIL PROTECTED] writes:
If a particular routine needs to lock a mutex, but it may be entered with
that mutex already locked,
would the following code be SMP safe?
hold_lock = mutex_trylock()
...
if (hold_lock)
mutex_unlock()
When two CPUs
Michael Buesch wrote:
On Friday 14 December 2007 01:05:00 Ray Lee wrote:
Okay, I had to modprobe rfkill-input and rfkill by hand, didn't
realize that. Hopefully that'll be automatic soon. Regardless, upon
doing so, and loading ssb and b43, it sees my card, but is still not
fully functional.
Rafael J. Wysocki wrote:
Actually, can you explain why, from the technical point of view, the version 4
firware is better than version 3, please?
I will be very interested in Michael's answer to this question; however, my experience is that it
doesn't make much difference if your device is
[EMAIL PROTECTED] wrote:
Could this be the reason my BCM94311MCG rev 1 receives such terrible
performance with b43 but works well with bcm43xx? The device is
802.11b/g but my router is 802.11b. I filed a report on this issue
here: https://bugzilla.redhat.com/show_bug.cgi?id=413291
No. On my
[EMAIL PROTECTED] wrote:
On Dec 14, 2007 11:37 PM, [EMAIL PROTECTED] wrote:
I'll attach these logs since I can't read much into them.
I should do what I say...
It will take a while to finish looking over those logs, but are you using ipv6? If not, please
blacklist the ipv6 module to
Michael Buesch wrote:
On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote:
Well, the only problem with that is I suspect there are some newer cards that
work better with v3 firmware, although they are supposed to support both.
And I suspect that you are wrong until you show me one. :)
On my openSUSE 10.3 x86_64 system running v2.6.24-rc1-281-g22d2aa1, I get the
sysfs rename messages.
Using Greg's patch, nothing changed. The log results are:
sysfs: duplicate filename 'eth1' can not be created
WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
Call Trace:
[802d1180]
Kay Sievers wrote:
On Fri, 2007-10-26 at 12:05 -0500, Larry Finger wrote:
On my openSUSE 10.3 x86_64 system running v2.6.24-rc1-281-g22d2aa1,
I get the sysfs rename messages.
Care to try this? Seems like a silly bug in the core if
SYSFS_DEPRECATED=y. That's why we didn't catch this earlier
controller for mpc52xx
Driver for ethernet on mpc5200/mpc5200b SoCs (FEC).
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
Acked-by: Dale Farnsworth [EMAIL PROTECTED]
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
Larry Finger
-
To unsubscribe from this list: send the line unsubscribe
Jiri Kosina wrote:
On Fri, 19 Oct 2007, Larry Finger wrote:
As I said earlier, the lock problem went away; however, I get the
following two kernel warnings:
That's because I messed up the patch, sorry. The one below should work
better.
From: Jiri Kosina [EMAIL PROTECTED]
USB
Jiri Kosina wrote:
On Fri, 19 Oct 2007, Larry Finger wrote:
While attempting to configure a new USB modem, the following locking
problem occurred. In addition, shortly after this problem occurred, the
computer froze. The log data starts at the point that usbserial was
loaded and contains
Jiri Kosina wrote:
On Fri, 19 Oct 2007, Larry Finger wrote:
While attempting to configure a new USB modem, the following locking
problem occurred. In addition, shortly after this problem occurred, the
computer froze. The log data starts at the point that usbserial was
loaded and contains
My network also fails - my interface is a BCM4311 using b43 as the driver.
Upon bisecting, I find that d3904b739928edd83d117f1eb5bfa69f18d6f046 is first
bad commit
commit d3904b739928edd83d117f1eb5bfa69f18d6f046
Author: Pavel Emelyanov [EMAIL PROTECTED]
Date: Wed Oct 17 21:22:17 2007 -0700
While attempting to configure a new USB modem, the following locking problem
occurred. In addition,
shortly after this problem occurred, the computer froze. The log data starts at
the point that
usbserial was loaded and contains everything that was written to disk before
the machine locked up.
Is the set_pages_* API that replaces change_page_attr described somewhere? I have been unable to
find it with Google.
I'm trying to modify the VirtualBox kernel module to work with 2.6.24-git (and 2.6.25) on x86_64
architecture. The current code has a value of the third argument of the call
Arjan van de Ven wrote:
On Sat, 09 Feb 2008 15:40:12 -0700
Larry Finger [EMAIL PROTECTED] wrote:
Is the set_pages_* API that replaces change_page_attr described
somewhere? I have been unable to find it with Google.
I'm trying to modify the VirtualBox kernel module to work with
2.6.24-git
---
drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Larry Finger larry.fin...@lwfinger.net
Thanks,
Larry
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index c9a6a7f
Andy,
The checkpatch.pl version in mainline is issuing what I think are false warnings
of the type
WARNING: networking block comments put the trailing */ on a separate line
#93: FILE: drivers/net/wireless/rtlwifi/wifi.h:208:
+ u32 rf_rb; /* rflssi_readback */
Is a trailing
On 10/12/2012 01:38 PM, Joe Perches wrote:
On Fri, 2012-10-12 at 13:23 -0500, Larry Finger wrote:
Andy,
The checkpatch.pl version in mainline is issuing what I think are false warnings
of the type
WARNING: networking block comments put the trailing */ on a separate line
#93: FILE: drivers/net
The VirtualBox kernel modules need to be modified to account for the removal of
VM_RESERVED in version 3.7-rc1. When I used the normal test of
LINUX_VERSION_CODE against KERNEL_VERSION(3, 7, 0), the fix did not work. To
test why, I added the following code snippet to a module:
#if
The value for LINUX_VERSION_CODE was not updated for kernel 3.7-rc1.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
---
version.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
Index: linux-2.6/include/linux/version.h
On 10/15/2012 04:54 PM, Borislav Petkov wrote:
On Mon, Oct 15, 2012 at 04:43:27PM -0500, Larry Finger wrote:
The value for LINUX_VERSION_CODE was not updated for kernel 3.7-rc1.
That's probably fallout from the whole UAPI thing.
Signed-off-by: Larry Finger larry.fin...@lwfinger.net
In the process of advising a user on getting a BCM4311 wireless device to work
with bcm43xx rather
than ndiswrapper, the device stopped appearing in an lspci output. The 'lspci
-vn' output
for this device before this failure was:
03:00.0 0280: 14e4:4311 (rev 01)
Subsystem: 103c:1363
track the reason for not calling these routines, but leave that for the ACPI wizards. The
following hack works for my system:
Avoid a NULL pointer kernel oops on x86_64 caused by throttling.states_fss not
being allocated.
Signed-off-by: Larry
A new driver for the Broadcom BCM43xx devices has been written that uses mac80211, rather than
softmac. The newest versions of the Broadcom firmware does not support all the BCM devices.
Accordingly, a separate driver is being prepared that will use an older version of the firmware and
support
Kay Sievers wrote:
On 8/17/07, Larry Finger [EMAIL PROTECTED] wrote:
A new driver for the Broadcom BCM43xx devices has been written that uses
mac80211, rather than
softmac. The newest versions of the Broadcom firmware does not support all the
BCM devices.
Accordingly, a separate driver
I am getting the following error message from drivers/base/core.c:
net eth1: device_rename: sysfs_create_symlink failed (-17)
Upon investigation, the call generating the error is renaming 'eth1' to 'eth1'. The following patch
suppresses the error.
Index: wireless-dev/drivers/base/core.c
David Miller wrote:
From: Larry Finger [EMAIL PROTECTED]
Date: Tue, 07 Aug 2007 23:17:23 -0500
I am getting the following error message from drivers/base/core.c:
net eth1: device_rename: sysfs_create_symlink failed (-17)
Upon investigation, the call generating the error is renaming 'eth1
David Miller wrote:
From: Larry Finger [EMAIL PROTECTED]
Date: Tue, 07 Aug 2007 23:52:34 -0500
Yes, it is most likely coming from udev. Do you know who maintains
udev? Google didn't give an answer in the first two pages.
I may be mis-remembering but I thought Greg KH was at the
helm at least
Cornelia Huck wrote:
On Tue, 07 Aug 2007 21:37:24 -0700 (PDT),
David Miller [EMAIL PROTECTED] wrote:
I think this check belongs in udev not in the kernel. Thankfully
this message at least tells us it is happening, please don't
remove it.
Hm, device_rename() could alternatively just return
Kay Sievers wrote:
On 8/8/07, Larry Finger [EMAIL PROTECTED] wrote:
I agree with you, but you and David can fight it out. While finding out where
to ask/complain about
udev, I had a private communication with GregKH. He thinks that a patch to fix
this has already been
pushed through Linus
Kay Sievers wrote:
On Wed, 2007-08-08 at 08:59 -0500, Larry Finger wrote:
Kay Sievers wrote:
On 8/8/07, Larry Finger [EMAIL PROTECTED] wrote:
I agree with you, but you and David can fight it out. While finding out where
to ask/complain about
udev, I had a private communication with GregKH
On 2.6.23-git1, if MMC/SD card support is selected, and LED driver support is
not selected in the
configuration, the following build errors occur:
drivers/mmc/core/host.c: In function ‘mmc_remove_host’:
drivers/mmc/core/host.c:146: error: implicit declaration of function
Geert Uytterhoeven wrote:
linux/drivers/net/wireless/b43/pio.h: In function 'b43_pio_write':
linux/drivers/net/wireless/b43/pio.h:89: error: implicit declaration of
function 'mmiowb'
linux/drivers/net/wireless/b43/phy.c: In function 'b43_phy_write':
In commit 7eff2e7a8b65c25920207324e56611150eb1cd9a, the calling sequence
for add_uevent_var was changed, but the ssb driver was not modified, which
leads to a Unable to handle kernel paging request oops. This patch fixes
the problem.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
drivers/ssb
In commit 7eff2e7a8b65c25920207324e56611150eb1cd9a, the calling sequence
for add_uevent_var was changed, but the ssb driver was not modified, which
leads to a Unable to handle kernel paging request oops. This patch fixes
the problem.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
drivers/ssb
In commit 7eff2e7a8b65c25920207324e56611150eb1cd9a, the calling sequence
for add_uevent_var was changed. This patch propagates this change to
MMC/SD card support.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
Linus, Andrew,
The wring patch was sent the first time.
Sorry,
Larry
drivers
WANG Cong wrote:
Initialize err in drivers/net/wireless/b43legacy/main.c::b43legacy_start()
in case of returning an uninitialized value.
From: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: WANG Cong [EMAIL PROTECTED]
---
drivers/net/wireless/b43/main.c |2 +-
1 file changed, 1
On 04/03/2013 09:36 PM, Stephen Rothwell wrote:
Hi Larry,
On Wed, 03 Apr 2013 20:17:01 -0500 Larry Finger larry.fin...@lwfinger.net
wrote:
On 04/03/2013 08:04 PM, Stephen Rothwell wrote:
On Thu, 4 Apr 2013 12:00:43 +1100 Stephen Rothwell s...@canb.auug.org.au
wrote:
After merging
On 04/04/2013 02:10 AM, Stephen Rothwell wrote:
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/net/wireless/rtlwifi/rtl8188ee/built-in.o: In function
`.rtl92c_phy_ap_calibrate':
(.text+0x21d14): multiple definition of
After receiving a number of inquiries regarding a Linux driver for the RTL8723AU
device with USB ID 0bda:1724, I asked my contacts in the USB group at Realtek if
such a driver were available. They responded that there is one, but not on their
public FTP site; however, they gave me the necessary
On 04/01/2013 09:34 PM, Stephen Rothwell wrote:
Hi John,
After merging the wireless-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/net/wireless/rtlwifi/rtl8188ee/dm.c:30:18: fatal error: wifi.h: No such
file or directory
Caused by commit f0eb856e0b6c
On 04/01/2013 10:31 PM, Stephen Rothwell wrote:
Hi Larry,
On Mon, 01 Apr 2013 22:07:24 -0500 Larry Finger larry.fin...@lwfinger.net
wrote:
On 04/01/2013 09:34 PM, Stephen Rothwell wrote:
After merging the wireless-next tree, today's linux-next build (x86_64
allmodconfig) failed like
On 04/03/2013 08:04 PM, Stephen Rothwell wrote:
Hi John,
On Thu, 4 Apr 2013 12:00:43 +1100 Stephen Rothwell s...@canb.auug.org.au
wrote:
After merging the wireless-next tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
x86_64-linux-gcc: warning:
I am chasing what I suspect is a firmware error for the Realtek RTL8723AE
device. The symptom is that the RX buffer is corrupted, and I get a kernel panic
due to a bad pointer in an interrupt routine.
I am currently checking that pointer for NULL, which is catching some of the
situations, but
In kernel 3.9-rc1, I get the following lockdep warning. This kernel is from the
wireless-testing tree, but I have seen the same message from the mainline kernel.
[ 4199.401157]
[ 4199.401159] ==
[ 4199.401160] [ INFO: possible circular locking
, GFP_ATOMIC);
+ buffer = kmemdup(data, len, GFP_ATOMIC);
if (!buffer)
return;
- memcpy(buffer, data, len);
usb_control_msg(udev, pipe, request, reqtype, wvalue,
index, buffer, len, 50);
Acked-by: Larry Finger larry.fin...@lwfinger.net
On 03/04/2013 07:02 PM, Shuah Khan wrote:
PCI_BUS defined in defs.h results in warnings from all brcm80211 source files
including defs.h. This define is not used in brcm80211. Removing this define
fixes the warning.
In file included from drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c:35:0:
/rtl871x_cmd.c |1 -
drivers/staging/rtl8712/rtl871x_ioctl_set.c |2 --
drivers/staging/rtl8712/rtl871x_mlme.c |5 -
4 files changed, 10 deletions(-)
Acked-by: Larry Finger larry.fin...@lwfinger.net (for r8712u)
Thanks,
Larry
diff --git a/drivers/staging/rtl8712/mlme_linux.c
changed, 2 insertions(+), 1 deletion(-)
Acked-by: Larry Finger larry.fin...@lwfinger.net
Thanks,
Larry
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index 3a64790..2c73319 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b
Hi,
With v3.8-8693-gbf722a0 from the mainline repo, I get the following warning
because the pointer for tty is NULL:
[ 34.956862] WARNING: at drivers/tty/tty_buffer.c:428
flush_to_ldisc+0x1bb/0x1c0()
[ 34.956865] Hardware name: HP Pavilion dv2700 Notebook PC
[ 34.956867] tty is NULL
[
On 02/27/2013 03:19 PM, Jiri Slaby wrote:
On 02/26/2013 10:56 PM, Daniel Mack wrote:
On Tue, Feb 26, 2013 at 10:25 PM, Larry Finger
larry.fin...@lwfinger.net wrote:
Hi,
With v3.8-8693-gbf722a0 from the mainline repo, I get the following warning
because the pointer for tty is NULL
On 02/14/2013 11:24 PM, Greg KH wrote:
On Fri, Feb 15, 2013 at 04:01:24PM +1100, Stephen Rothwell wrote:
Hi Greg,
Today's linux-next merge of the driver-core tree got a conflict in
drivers/net/wireless/rtlwifi/Kconfig between commit 06e7cda3ce30
(rtlwifi: Rework Kconfig) from the wireless-next
With the current wireless-testing tree, unloading b43 produces the lockdep log
splat copied below. My understanding of locking is deficient, and I would like
to learn. Any help on understanding this problem is appreciated.
Larry
[ 3093.900871]
On 02/24/2013 12:32 PM, Michael Büsch wrote:
On Sun, 24 Feb 2013 11:31:47 -0600
Larry Finger larry.fin...@lwfinger.net wrote:
With the current wireless-testing tree, unloading b43 produces the lockdep log
splat copied below. My understanding of locking is deficient, and I would like
to learn
On 02/24/2013 12:14 PM, Johannes Berg wrote:
On Sun, 2013-02-24 at 11:31 -0600, Larry Finger wrote:
Thanks for the detailed analysis. It was very helpful.
Here request_firmware calls wiphy_register which locks the RTNL, and
it's running from the work struct. This was newly introduced
roucaries bastien wrote:
My bcm43xx oops after suspend to disk on a 2.6.20rc5 kernel (preempt+smp).
---
Jan 25 19:47:39 portablebastien kernel: caller is oops_begin+0xb/0x80
Jan 25 19:47:39 portablebastien kernel:
Jan 25 19:47:39 portablebastien kernel: Call Trace:
Jan 25
roucaries bastien wrote:
Do you have the log stuff that precedes this part? In particular, was
there a assertion that failed?
It is oops on resume and no asseertion failled this boot. However I
have usually a lot of
bcm43xx: ASSERTION FAILED (radio_attenuation 10) at:
Is there a convention regarding the information that a wireless MAC layer
should provide when
reporting scan data from an AP with a hidden SSID?
In ieee80211, the software inserts the string hidden for such an AP, which
seems to give
wpa_supplicant fits because it rejects the SSID before even
Dan Williams wrote:
On Fri, 2007-01-26 at 21:48 -0600, Larry Finger wrote:
Is there a convention regarding the information that a wireless MAC layer
should provide when
reporting scan data from an AP with a hidden SSID?
In ieee80211, the software inserts the string hidden for such an AP
Dan Williams wrote:
On Fri, 2007-01-26 at 21:48 -0600, Larry Finger wrote:
Is there a convention regarding the information that a wireless MAC layer
should provide when
reporting scan data from an AP with a hidden SSID?
In ieee80211, the software inserts the string hidden for such an AP
Matthew Garrett wrote:
On Mon, Jan 29, 2007 at 01:55:41PM +0100, roucaries bastien wrote:
- return 0;
+ return bcm43xx_init_one(pdev, NULL);
}
While this may well work (it's basically equivalent to unloading and
reloading the module), it's not a long-term fix - userspace is
that contains the essid
of the AP that wpa_supplicant is trying to find. The existing routine,
ieee80211_wx_get_scan, calls the new one with the false ssid. The code in
ieee80211softmac is also modified to use the new routine and has been tested
with bcm43xx.
Signed-off-by: Larry Finger [EMAIL PROTECTED
Jouni Malinen wrote:
On Mon, Jan 29, 2007 at 10:52:20PM -0600, Larry Finger wrote:
When an AP has a hidden SSID, ieee80211 fails, at least with wpa_supplicant,
which searches through the scan data looking for a particular ssid. Because
ieee80211 has substituted a false ssid, namely hidden
Jouni Malinen wrote:
On Tue, Jan 30, 2007 at 01:08:29AM -0600, Larry Finger wrote:
Any AP with a hidden SSID will only respond to probe requests that specify
its SSID, and will ignore
any other probes. In addition, the response will have an empty SSID field.
These responses are the
only
-off-by: Ulrich Kunitz [EMAIL PROTECTED]
Acked-by: Michael Buesch [EMAIL PROTECTED]
Signed-off-by: Larry Finger [EMAIL PROTECTED]
---
John,
This patch should be pushed upstream to 2.6.20. At the moment, the work
struct changes have not yet propagated to wireless-2.6. When they do,
it will be needed
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
I have a new laptop - an HP Pavilion dv2125nr with an AMD Turion 64 X2 Mobile
CPU. With any kernel
later than 2.6.18, the sound does not work. The audio interface is reported by
lspci as Audio
device: nVidia Corporation MCP51 High Definition Audio (rev a2), and uses the
snd_hda_intel module.
Daniel Drake wrote:
Larry Finger wrote:
When this commit is reverted, I get sound, but playing a sound file
results in about an 0.5 sec
fragment being replayed over and over forever. If commit
7376d013fc6d3a45..., which is entitled
Simple patch to enable Message Signalled Interrupts
Tobin Davis wrote:
Which alsa patch was this? I'm not seeing anything in the hg logs for
this. Or is this something from the kernel side?
It seems to have come from suse. The full commit message is:
commit a7da6ce564a80952d9c0b210deca5a8cd3474a31
Author: Takashi Iwai [EMAIL PROTECTED]
Date:
1 - 100 of 1407 matches
Mail list logo
