Robie Basak <rb-oss-3@...> writes:
>
> On 2010-11-12, Larry Finger <Larry.Finger@...> wrote:
> > What does the following log entry signify?
> >
> > Nov 12 16:29:03 tiny kernel: [ 160.306731]
> >=>>>>>>>>>>=============================>set power:0,0!
> >
> > On my system, switching to battery does not affect the rtl8187se at all.
>
> That is consistently showing up every time I switch from AC to battery
> (but not battery to AC) while wireless is on. It does not appear if I
> turn the wireless off, disconnect AC and then turn wireless on again.
>
> Also for a suspend/resume cycle, it appears only if on battery and
> wireless is on.
>
> Robie
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@...
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
It's good to see that this problem is being examined closely. I have been living
with this issue on my EeePC 701SD for some time and it has been very
frustrating. I can confirm that the same issue Robie describes occur for my
701SD with r8187se wireless card (Fn+F2 causes a kernel panic when turning the
wireless card off -- this doesn't seem to occur when turning it on if the
netbook starts up with the wireless adapter off). This has occured in Ubuntu
versions 9.04 through to 10.10. I recently switched to Debian Squeeze (testing,
beta1), currently running 2.6.32-5-686 kernel and am experiencing an identical
problem. I'm not experienced in debugging this type of issue myself, but would
be happy to test any suggested fixes for the issue and report back results
(though you would need to advise as to how to do this and what to include in
replies).
Regards
James
On 11/14/2010 06:22 AM, James Womack wrote:
> Okay, I've downloaded the necessary tools and extracted the kernel
> source. I have a tutorial on how to patch and build the kernel. Where
> should I apply your patches?
Change directory to the main directory of the kernel source - the one with
subdirectories like arch, block, crypto, drivers, etc. Apply patches with a
command of the form
patch -p1 --dry-run < <nameofpatch>
If that works without any error, then leave out the "--dry-run" to apply the
patch. If/when it is necessary to remove the patch, adding a "-R" option will do
that.
When you build the kernel, you should do that as a normal user, not root. If the
source files are not owned by that user, you should do a chown on that tree
before starting.
Larry
On 13/11/10 18:44, Larry Finger wrote:
> On 11/13/2010 12:18 PM, James Womack wrote:
>>
>> It's good to see that this problem is being examined closely. I have been living
>> with this issue on my EeePC 701SD for some time and it has been very
>> frustrating. I can confirm that the same issue Robie describes occur for my
>> 701SD with r8187se wireless card (Fn+F2 causes a kernel panic when turning the
>> wireless card off -- this doesn't seem to occur when turning it on if the
>> netbook starts up with the wireless adapter off). This has occured in Ubuntu
>> versions 9.04 through to 10.10. I recently switched to Debian Squeeze (testing,
>> beta1), currently running 2.6.32-5-686 kernel and am experiencing an identical
>> problem. I'm not experienced in debugging this type of issue myself, but would
>> be happy to test any suggested fixes for the issue and report back results
>> (though you would need to advise as to how to do this and what to include in
>> replies).
>
> Testing would require that you have kernel source, apply the patches, and build
> a new kernel with those included. On some distros, these steps are easier than
> for others. Is your skill set up to this?
>
> I will push the patch that changes the panic/crash into a simple warning with
> the request that this be applied to stable. If/when this happens, you will have
> that fix in your standard kernel. How long it takes will depend on the distro.
>
> It is strange that I was not aware of this problem until Robie recently posted
> in this list. Running the RTL8187SE on my computer has been a pain as the BIOS
> in my computer does not have that device in its whitelist of approved devices.
> As such, rebooting with it required that I shut down, remove the card, boot to
> GRUB, and then hot-plug the card while being careful not to short it. That
> changed in the past 2 days as I now have an ExpressCard to mini PCIe extender
> that allows me to boot with the card installed. Unfortunately, I do not yet know
> how to change the RFKILL setting with this device.
>
> Larry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
If building a kernel is as simple as building other programs from source
(i.e. configure, make, make install), I could do that. I'm using Debian
at the moment. Presumably I'd need a compiler of some kind, which I
could obtain from the repos. I am not sure how one would apply patches
to the kernel, however. Would I be able to compile a modified kernel and
add this to grub whilst retaining the ability to boot in the unmodified
kernel?
James
On 11/13/2010 12:18 PM, James Womack wrote:
>
> It's good to see that this problem is being examined closely. I have been living
> with this issue on my EeePC 701SD for some time and it has been very
> frustrating. I can confirm that the same issue Robie describes occur for my
> 701SD with r8187se wireless card (Fn+F2 causes a kernel panic when turning the
> wireless card off -- this doesn't seem to occur when turning it on if the
> netbook starts up with the wireless adapter off). This has occured in Ubuntu
> versions 9.04 through to 10.10. I recently switched to Debian Squeeze (testing,
> beta1), currently running 2.6.32-5-686 kernel and am experiencing an identical
> problem. I'm not experienced in debugging this type of issue myself, but would
> be happy to test any suggested fixes for the issue and report back results
> (though you would need to advise as to how to do this and what to include in
> replies).
Testing would require that you have kernel source, apply the patches, and build
a new kernel with those included. On some distros, these steps are easier than
for others. Is your skill set up to this?
I will push the patch that changes the panic/crash into a simple warning with
the request that this be applied to stable. If/when this happens, you will have
that fix in your standard kernel. How long it takes will depend on the distro.
It is strange that I was not aware of this problem until Robie recently posted
in this list. Running the RTL8187SE on my computer has been a pain as the BIOS
in my computer does not have that device in its whitelist of approved devices.
As such, rebooting with it required that I shut down, remove the card, boot to
GRUB, and then hot-plug the card while being careful not to short it. That
changed in the past 2 days as I now have an ExpressCard to mini PCIe extender
that allows me to boot with the card installed. Unfortunately, I do not yet know
how to change the RFKILL setting with this device.
Larry
On 14/11/10 16:18, Larry Finger wrote:
> On 11/14/2010 06:22 AM, James Womack wrote:
>> Okay, I've downloaded the necessary tools and extracted the kernel
>> source. I have a tutorial on how to patch and build the kernel. Where
>> should I apply your patches?
>
> Change directory to the main directory of the kernel source - the one with
> subdirectories like arch, block, crypto, drivers, etc. Apply patches with a
> command of the form
>
> patch -p1 --dry-run< <nameofpatch>
>
> If that works without any error, then leave out the "--dry-run" to apply the
> patch. If/when it is necessary to remove the patch, adding a "-R" option will do
> that.
>
> When you build the kernel, you should do that as a normal user, not root. If the
> source files are not owned by that user, you should do a chown on that tree
> before starting.
>
> Larry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hey, I tried patching the kernel I downloaded, but the dry runs both
presented errors detailed below:
james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run <
/home/james/rtl8187se_change_panic_to_warn
patching file drivers/staging/rtl8187se/r8185b_init.c
Hunk #1 succeeded at 356 with fuzz 2 (offset 92 lines).
Hunk #2 FAILED at 302.
1 out of 2 hunks FAILED -- saving rejects to file
drivers/staging/rtl8187se/r8185b_init.c.rej
james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run <
/home/james/rtl8187se_
rtl8187se_change_panic_to_warn rtl8187se_lock_pci_remove
james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run <
/home/james/rtl8187se_lock_pci_remove
patching file drivers/staging/rtl8187se/r8180_core.c
patch unexpectedly ends in middle of line
patch: **** unexpected end of file in patch
james@mercury:/usr/src/linux-source-2.6.32$
Do I need to do anything to the kernel source before applying the patches?
James
On 14/11/10 20:23, Larry Finger wrote:
> On 11/14/2010 12:49 PM, James Womack wrote:
>> Hey, I tried patching the kernel I downloaded, but the dry runs both
>> presented errors detailed below:
>>
>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>> /home/james/rtl8187se_change_panic_to_warn
>> patching file drivers/staging/rtl8187se/r8185b_init.c
>> Hunk #1 succeeded at 356 with fuzz 2 (offset 92 lines).
>> Hunk #2 FAILED at 302.
>> 1 out of 2 hunks FAILED -- saving rejects to file
>> drivers/staging/rtl8187se/r8185b_init.c.rej
>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>> /home/james/rtl8187se_
>> rtl8187se_change_panic_to_warn rtl8187se_lock_pci_remove
>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>> /home/james/rtl8187se_lock_pci_remove
>> patching file drivers/staging/rtl8187se/r8180_core.c
>> patch unexpectedly ends in middle of line
>> patch: **** unexpected end of file in patch
>> james@mercury:/usr/src/linux-source-2.6.32$
>>
>> Do I need to do anything to the kernel source before applying the patches?
>
> You needed a different version of the patch for 2.6.32. Apply the attached
> version. You only need the one patch.
>
> Larry
Hello,
I managed to compile the patched kernel. To confirm - the issue of the
kernel panic occuring when Fn-F2 is used to turn off the wireless card
is resolved. Thank you. I'll let you know if I notice any side effects
from the patch.
James
On 13/11/10 20:02, Larry Finger wrote:
> On 11/13/2010 01:27 PM, James Womack wrote:
>> If building a kernel is as simple as building other programs from source
>> (i.e. configure, make, make install), I could do that. I'm using Debian
>> at the moment. Presumably I'd need a compiler of some kind, which I
>> could obtain from the repos. I am not sure how one would apply patches
>> to the kernel, however. Would I be able to compile a modified kernel and
>> add this to grub whilst retaining the ability to boot in the unmodified
>> kernel?
>
> It is similar to the process used with other programs. My distro is openSUSE and
> the steps are to get the kernel source, the kernel development package, and the
> patch utility using YaST. Other distros use emerge, apt-get, or similar
> utilities. The easiest way to configure the kernel is to match the current one
> using the compressed version in /proc/config.gz. You should end up with an
> additional kernel in the GRUB menu that can be selected at boot time.
>
> Larry
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Okay, I've downloaded the necessary tools and extracted the kernel
source. I have a tutorial on how to patch and build the kernel. Where
should I apply your patches?
James
On 15/11/10 23:44, Larry Finger wrote:
> On 11/15/2010 03:05 PM, James Womack wrote:
>> On 14/11/10 20:23, Larry Finger wrote:
>>> On 11/14/2010 12:49 PM, James Womack wrote:
>>>> Hey, I tried patching the kernel I downloaded, but the dry runs both
>>>> presented errors detailed below:
>>>>
>>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>>> /home/james/rtl8187se_change_panic_to_warn
>>>> patching file drivers/staging/rtl8187se/r8185b_init.c
>>>> Hunk #1 succeeded at 356 with fuzz 2 (offset 92 lines).
>>>> Hunk #2 FAILED at 302.
>>>> 1 out of 2 hunks FAILED -- saving rejects to file
>>>> drivers/staging/rtl8187se/r8185b_init.c.rej
>>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>>> /home/james/rtl8187se_
>>>> rtl8187se_change_panic_to_warn rtl8187se_lock_pci_remove
>>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>>> /home/james/rtl8187se_lock_pci_remove
>>>> patching file drivers/staging/rtl8187se/r8180_core.c
>>>> patch unexpectedly ends in middle of line
>>>> patch: **** unexpected end of file in patch
>>>> james@mercury:/usr/src/linux-source-2.6.32$
>>>>
>>>> Do I need to do anything to the kernel source before applying the
>>>> patches?
>>>
>>> You needed a different version of the patch for 2.6.32. Apply the
>>> attached
>>> version. You only need the one patch.
>>>
>>> Larry
>>
>> Hello,
>>
>> I managed to compile the patched kernel. To confirm - the issue of the
>> kernel panic occuring when Fn-F2 is used to turn off the wireless card
>> is resolved. Thank you. I'll let you know if I notice any side effects
>> from the patch.
>
> After you do the Fn-F2 sequence, there should be a stack dump in the output of
> the dmesg command. Could you please post that? With it, I should be able to find
> what is leading to the original error. It does not happen on my system.
>
> Larry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Okay, I used dmesg | tail to print the last 10 lines of dmesg. Hopefully
this is what you were asking for:
[ 812.500300] [<f81d97c1>] ? eeepc_rfkill_hotplug+0x127/0x142
[eeepc_laptop]
[ 812.500311] [<c116a27d>] ? acpi_ev_notify_dispatch+0x4c/0x57
[ 812.500320] [<c115db60>] ? acpi_os_execute_deferred+0x1a/0x23
[ 812.500330] [<c103fc20>] ? worker_thread+0x142/0x1c2
[ 812.500337] [<c115db46>] ? acpi_os_execute_deferred+0x0/0x23
[ 812.500347] [<c104289e>] ? autoremove_wake_function+0x0/0x29
[ 812.500354] [<c103fade>] ? worker_thread+0x0/0x1c2
[ 812.500362] [<c1042680>] ? kthread+0x5f/0x64
[ 812.500369] [<c1042621>] ? kthread+0x0/0x64
[ 812.500379] [<c1003ca7>] ? kernel_thread_helper+0x7/0x10
[ 812.700057] r8180: WW:Card reset timeout!
[ 812.908439] r8180: Freeing irq 18
[ 812.920050] r8180 0000:01:00.0: PCI INT A disabled
[ 812.920056] r8180: wlan driver removed
[ 812.920058]
Regards,
James
On 16/11/10 15:00, Larry Finger wrote:
> On 11/16/2010 08:46 AM, James Womack wrote:
>
>> This should be sufficient, hopefully!
>
> Perfect.
>
> Larry
Good. Thanks for fixing this issue. Do you have any idea when we could
expect to see this fix incorporated into a mainstream kernel?
James
On 11/14/2010 12:49 PM, James Womack wrote:
> Hey, I tried patching the kernel I downloaded, but the dry runs both
> presented errors detailed below:
>
> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run <
> /home/james/rtl8187se_change_panic_to_warn
> patching file drivers/staging/rtl8187se/r8185b_init.c
> Hunk #1 succeeded at 356 with fuzz 2 (offset 92 lines).
> Hunk #2 FAILED at 302.
> 1 out of 2 hunks FAILED -- saving rejects to file
> drivers/staging/rtl8187se/r8185b_init.c.rej
> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run <
> /home/james/rtl8187se_
> rtl8187se_change_panic_to_warn rtl8187se_lock_pci_remove
> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run <
> /home/james/rtl8187se_lock_pci_remove
> patching file drivers/staging/rtl8187se/r8180_core.c
> patch unexpectedly ends in middle of line
> patch: **** unexpected end of file in patch
> james@mercury:/usr/src/linux-source-2.6.32$
>
> Do I need to do anything to the kernel source before applying the patches?
You needed a different version of the patch for 2.6.32. Apply the attached
version. You only need the one patch.
Larry
On 11/15/2010 03:05 PM, James Womack wrote:
> On 14/11/10 20:23, Larry Finger wrote:
>> On 11/14/2010 12:49 PM, James Womack wrote:
>>> Hey, I tried patching the kernel I downloaded, but the dry runs both
>>> presented errors detailed below:
>>>
>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>> /home/james/rtl8187se_change_panic_to_warn
>>> patching file drivers/staging/rtl8187se/r8185b_init.c
>>> Hunk #1 succeeded at 356 with fuzz 2 (offset 92 lines).
>>> Hunk #2 FAILED at 302.
>>> 1 out of 2 hunks FAILED -- saving rejects to file
>>> drivers/staging/rtl8187se/r8185b_init.c.rej
>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>> /home/james/rtl8187se_
>>> rtl8187se_change_panic_to_warn rtl8187se_lock_pci_remove
>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>> /home/james/rtl8187se_lock_pci_remove
>>> patching file drivers/staging/rtl8187se/r8180_core.c
>>> patch unexpectedly ends in middle of line
>>> patch: **** unexpected end of file in patch
>>> james@mercury:/usr/src/linux-source-2.6.32$
>>>
>>> Do I need to do anything to the kernel source before applying the
>>> patches?
>>
>> You needed a different version of the patch for 2.6.32. Apply the
>> attached
>> version. You only need the one patch.
>>
>> Larry
>
> Hello,
>
> I managed to compile the patched kernel. To confirm - the issue of the
> kernel panic occuring when Fn-F2 is used to turn off the wireless card
> is resolved. Thank you. I'll let you know if I notice any side effects
> from the patch.
After you do the Fn-F2 sequence, there should be a stack dump in the output of
the dmesg command. Could you please post that? With it, I should be able to find
what is leading to the original error. It does not happen on my system.
Larry
On 11/16/2010 08:46 AM, James Womack wrote:
> This should be sufficient, hopefully!
Perfect.
Larry
On 11/16/2010 09:08 AM, Rafał Miłecki wrote:
> 2010/11/16 Larry Finger <[email protected]>:
>> On 11/16/2010 08:46 AM, James Womack wrote:
>>
>>> This should be sufficient, hopefully!
>>
>> Perfect.
>
> Would be nice if you could decide to talk privately or on ML ;)
>
> James you do not use "Reply to all" for most of the discussion.
I want it to be on the mailing list. I didn't notice that James had sent it
privately, otherwise I would not have trimmed my reply so drasticly. For
completeness, the traceback is as follows:
[ 3604.120086] rtl8187se: HwThreeWire(): CmdReg: 0XFF RE|WE bits are not clear!!
[ 3604.120099] Pid: 17, comm: kacpi_notify Tainted: G C 2.6.32-custom #1
[ 3604.120106] Call Trace:
[ 3604.120151] [<f7ff67e9>] ? HwHSSIThreeWire+0x55/0x1fe [rtl8187se]
[ 3604.120176] [<f7ff6ae8>] ? RF_WriteReg+0xb5/0xd7 [rtl8187se]
[ 3604.120198] [<f7ff5391>] ? rtl8225z2_rf_close+0x12/0x3d [rtl8187se]
[ 3604.120216] [<f800293f>] ? rtl8180_pci_remove+0x3e/0xdd [rtl8187se]
[ 3604.120231] [<c11406cd>] ? pci_device_remove+0x16/0x35
[ 3604.120241] [<c11aab79>] ? __device_release_driver+0x54/0x97
[ 3604.120249] [<c11aac48>] ? device_release_driver+0x15/0x1e
[ 3604.120258] [<c11aa2a9>] ? bus_remove_device+0x6e/0x7d
[ 3604.120265] [<c11a907d>] ? device_del+0xf0/0x146
[ 3604.120273] [<c11a90db>] ? device_unregister+0x8/0x10
[ 3604.120281] [<c113ce42>] ? pci_stop_bus_device+0x42/0x60
[ 3604.120288] [<c113cece>] ? pci_remove_bus_device+0xa/0x8e
[ 3604.120301] [<f823c7c1>] ? eeepc_rfkill_hotplug+0x127/0x142 [eeepc_laptop]
[ 3604.120312] [<c116a27d>] ? acpi_ev_notify_dispatch+0x4c/0x57
[ 3604.120322] [<c115db60>] ? acpi_os_execute_deferred+0x1a/0x23
[ 3604.120331] [<c103fc20>] ? worker_thread+0x142/0x1c2
[ 3604.120339] [<c115db46>] ? acpi_os_execute_deferred+0x0/0x23
[ 3604.120349] [<c104289e>] ? autoremove_wake_function+0x0/0x29
[ 3604.120356] [<c103fade>] ? worker_thread+0x0/0x1c2
[ 3604.120364] [<c1042680>] ? kthread+0x5f/0x64
[ 3604.120371] [<c1042621>] ? kthread+0x0/0x64
[ 3604.120381] [<c1003ca7>] ? kernel_thread_helper+0x7/0x10
[ 3604.320072] r8180: WW:Card reset timeout!
[ 3604.528471] r8180: Freeing irq 18
[ 3604.537501] r8180 0000:01:00.0: PCI INT A disabled
[ 3604.537507] r8180: wlan driver removed
[ 3604.537509]
Larry
On 11/16/2010 03:55 AM, James Womack wrote:
> On 15/11/10 23:44, Larry Finger wrote:
>> On 11/15/2010 03:05 PM, James Womack wrote:
>>> On 14/11/10 20:23, Larry Finger wrote:
>>>> On 11/14/2010 12:49 PM, James Womack wrote:
>>>>> Hey, I tried patching the kernel I downloaded, but the dry runs both
>>>>> presented errors detailed below:
>>>>>
>>>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>>>> /home/james/rtl8187se_change_panic_to_warn
>>>>> patching file drivers/staging/rtl8187se/r8185b_init.c
>>>>> Hunk #1 succeeded at 356 with fuzz 2 (offset 92 lines).
>>>>> Hunk #2 FAILED at 302.
>>>>> 1 out of 2 hunks FAILED -- saving rejects to file
>>>>> drivers/staging/rtl8187se/r8185b_init.c.rej
>>>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>>>> /home/james/rtl8187se_
>>>>> rtl8187se_change_panic_to_warn rtl8187se_lock_pci_remove
>>>>> james@mercury:/usr/src/linux-source-2.6.32$ patch -p1 --dry-run<
>>>>> /home/james/rtl8187se_lock_pci_remove
>>>>> patching file drivers/staging/rtl8187se/r8180_core.c
>>>>> patch unexpectedly ends in middle of line
>>>>> patch: **** unexpected end of file in patch
>>>>> james@mercury:/usr/src/linux-source-2.6.32$
>>>>>
>>>>> Do I need to do anything to the kernel source before applying the
>>>>> patches?
>>>>
>>>> You needed a different version of the patch for 2.6.32. Apply the
>>>> attached
>>>> version. You only need the one patch.
>>>>
>>>> Larry
>>>
>>> Hello,
>>>
>>> I managed to compile the patched kernel. To confirm - the issue of the
>>> kernel panic occuring when Fn-F2 is used to turn off the wireless card
>>> is resolved. Thank you. I'll let you know if I notice any side effects
>>> from the patch.
>>
>> After you do the Fn-F2 sequence, there should be a stack dump in the
>> output of
>> the dmesg command. Could you please post that? With it, I should be
>> able to find
>> what is leading to the original error. It does not happen on my system.
>>
>> Larry
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-wireless" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> Okay, I used dmesg | tail to print the last 10 lines of dmesg. Hopefully
> this is what you were asking for:
>
> [ 812.500300] [<f81d97c1>] ? eeepc_rfkill_hotplug+0x127/0x142
> [eeepc_laptop]
> [ 812.500311] [<c116a27d>] ? acpi_ev_notify_dispatch+0x4c/0x57
> [ 812.500320] [<c115db60>] ? acpi_os_execute_deferred+0x1a/0x23
> [ 812.500330] [<c103fc20>] ? worker_thread+0x142/0x1c2
> [ 812.500337] [<c115db46>] ? acpi_os_execute_deferred+0x0/0x23
> [ 812.500347] [<c104289e>] ? autoremove_wake_function+0x0/0x29
> [ 812.500354] [<c103fade>] ? worker_thread+0x0/0x1c2
> [ 812.500362] [<c1042680>] ? kthread+0x5f/0x64
> [ 812.500369] [<c1042621>] ? kthread+0x0/0x64
> [ 812.500379] [<c1003ca7>] ? kernel_thread_helper+0x7/0x10
> [ 812.700057] r8180: WW:Card reset timeout!
> [ 812.908439] r8180: Freeing irq 18
> [ 812.920050] r8180 0000:01:00.0: PCI INT A disabled
> [ 812.920056] r8180: wlan driver removed
> [ 812.920058]
I need a few more than that. The sequence I want should start with the phrase
"RE|WE bits not cleared".
Larry
On 11/16/2010 10:55 AM, James Womack wrote:
> On 16/11/10 15:00, Larry Finger wrote:
>> On 11/16/2010 08:46 AM, James Womack wrote:
>>
>>> This should be sufficient, hopefully!
>>
>> Perfect.
>>
>> Larry
>
> Good. Thanks for fixing this issue. Do you have any idea when we could
> expect to see this fix incorporated into a mainstream kernel?
The fix to change the panic into a simple warning has been pushed upstream. If
GregKH, the staging maintainer, thinks it can go into 2.6.37, then the
backporting to stable will happen fairly quickly. If he decides it is too
invasive (not likely), then the patch will wait for ~2 months for 2.6.38. Once
in mainline, there will be some delay as the patch for 2.6.37 does not apply to
your kernel (2.6.32 as I recall), thus I will have to supply a revised version.
Once it is in 2.6.32.Y, then your disto will have to pick up the changes and
create an updated kernel. The wheels of change turn slowly - kernel stability is
extremely important.
My estimate would be 6 weeks at a minimum. Note that I still do not have a real
fix for the warning. That could take a long time to find, particularly as I
cannot duplicate the condition on my box. Long-range debugging is a very slow
process.
One other thing to note. I have a mac80211 version of the rtl8187se driver that
almost works. It is able to receive and transmit short packets. When a packet
longer than about 64 bytes is sent, the firmware locks up. I sent my source to
Realtek to see if they could see what I'm doing wrong. Their report is that the
driver is now working, but not stable. Once that driver is finished, it wil;l;
be submitted to mainline, and the version in staging will be dropped.
Larry
>
> I need a few more than that. The sequence I want should start with the phrase
> "RE|WE bits not cleared".
>
> Larry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[ 3604.120086] rtl8187se: HwThreeWire(): CmdReg: 0XFF RE|WE bits are not
clear!!
[ 3604.120099] Pid: 17, comm: kacpi_notify Tainted: G C
2.6.32-custom #1
[ 3604.120106] Call Trace:
[ 3604.120151] [<f7ff67e9>] ? HwHSSIThreeWire+0x55/0x1fe [rtl8187se]
[ 3604.120176] [<f7ff6ae8>] ? RF_WriteReg+0xb5/0xd7 [rtl8187se]
[ 3604.120198] [<f7ff5391>] ? rtl8225z2_rf_close+0x12/0x3d [rtl8187se]
[ 3604.120216] [<f800293f>] ? rtl8180_pci_remove+0x3e/0xdd [rtl8187se]
[ 3604.120231] [<c11406cd>] ? pci_device_remove+0x16/0x35
[ 3604.120241] [<c11aab79>] ? __device_release_driver+0x54/0x97
[ 3604.120249] [<c11aac48>] ? device_release_driver+0x15/0x1e
[ 3604.120258] [<c11aa2a9>] ? bus_remove_device+0x6e/0x7d
[ 3604.120265] [<c11a907d>] ? device_del+0xf0/0x146
[ 3604.120273] [<c11a90db>] ? device_unregister+0x8/0x10
[ 3604.120281] [<c113ce42>] ? pci_stop_bus_device+0x42/0x60
[ 3604.120288] [<c113cece>] ? pci_remove_bus_device+0xa/0x8e
[ 3604.120301] [<f823c7c1>] ? eeepc_rfkill_hotplug+0x127/0x142
[eeepc_laptop]
[ 3604.120312] [<c116a27d>] ? acpi_ev_notify_dispatch+0x4c/0x57
[ 3604.120322] [<c115db60>] ? acpi_os_execute_deferred+0x1a/0x23
[ 3604.120331] [<c103fc20>] ? worker_thread+0x142/0x1c2
[ 3604.120339] [<c115db46>] ? acpi_os_execute_deferred+0x0/0x23
[ 3604.120349] [<c104289e>] ? autoremove_wake_function+0x0/0x29
[ 3604.120356] [<c103fade>] ? worker_thread+0x0/0x1c2
[ 3604.120364] [<c1042680>] ? kthread+0x5f/0x64
[ 3604.120371] [<c1042621>] ? kthread+0x0/0x64
[ 3604.120381] [<c1003ca7>] ? kernel_thread_helper+0x7/0x10
[ 3604.320072] r8180: WW:Card reset timeout!
[ 3604.528471] r8180: Freeing irq 18
[ 3604.537501] r8180 0000:01:00.0: PCI INT A disabled
[ 3604.537507] r8180: wlan driver removed
[ 3604.537509]
This should be sufficient, hopefully!
James
2010/11/16 Larry Finger <[email protected]>:
> On 11/16/2010 08:46 AM, James Womack wrote:
>
>> This should be sufficient, hopefully!
>
> Perfect.
Would be nice if you could decide to talk privately or on ML ;)
James you do not use "Reply to all" for most of the discussion.
--
Rafał
On 11/13/2010 01:27 PM, James Womack wrote:
> If building a kernel is as simple as building other programs from source
> (i.e. configure, make, make install), I could do that. I'm using Debian
> at the moment. Presumably I'd need a compiler of some kind, which I
> could obtain from the repos. I am not sure how one would apply patches
> to the kernel, however. Would I be able to compile a modified kernel and
> add this to grub whilst retaining the ability to boot in the unmodified
> kernel?
It is similar to the process used with other programs. My distro is openSUSE and
the steps are to get the kernel source, the kernel development package, and the
patch utility using YaST. Other distros use emerge, apt-get, or similar
utilities. The easiest way to configure the kernel is to match the current one
using the compressed version in /proc/config.gz. You should end up with an
additional kernel in the GRUB menu that can be selected at boot time.
Larry