Hi Paul,
On 2016-03-23, Paul E. McKenney wrote:
> Please boot with the following parameters:
>
> rcu_tree.rcu_kick_kthreads ftrace
> trace_event=sched_waking,sched_wakeup,sched_wake_idle_without_ipi
With these parameters I expected more details to show up in the kernel logs but
cannot
Hi Paul,
On 2016-03-23, Paul E. McKenney wrote:
> Please boot with the following parameters:
>
> rcu_tree.rcu_kick_kthreads ftrace
> trace_event=sched_waking,sched_wakeup,sched_wake_idle_without_ipi
With these parameters I expected more details to show up in the kernel logs but
cannot
Hi Paul,
On 2016-03-23, Paul E. McKenney wrote:
> Please boot with the following parameters:
>
> rcu_tree.rcu_kick_kthreads ftrace
> trace_event=sched_waking,sched_wakeup,sched_wake_idle_without_ipi
>
> Or was this run with tracing? If so, less than three hours isn't too bad.
This was
Hi Paul,
On 2016-03-23, Paul E. McKenney wrote:
> Please boot with the following parameters:
>
> rcu_tree.rcu_kick_kthreads ftrace
> trace_event=sched_waking,sched_wakeup,sched_wake_idle_without_ipi
>
> Or was this run with tracing? If so, less than three hours isn't too bad.
This was
Hi Paul,
On 2016-03-22, Paul E. McKenney wrote:
> On Tue, Mar 22, 2016 at 09:04:47PM +0000, Chatre, Reinette wrote:
>> On 2016-03-22, Paul E. McKenney wrote:
>>> You set CONFIG_RCU_CPU_STALL_TIMEOUT=60, which matches the 60004
>>> jiffies above. Is that value due to a
Hi Paul,
On 2016-03-22, Paul E. McKenney wrote:
> On Tue, Mar 22, 2016 at 09:04:47PM +0000, Chatre, Reinette wrote:
>> On 2016-03-22, Paul E. McKenney wrote:
>>> You set CONFIG_RCU_CPU_STALL_TIMEOUT=60, which matches the 60004
>>> jiffies above. Is that value due to a
Hi Paul,
On 2016-03-22, Paul E. McKenney wrote:
> On Tue, Mar 22, 2016 at 04:35:32PM +0000, Chatre, Reinette wrote:
>> On 2016-03-21, Paul E. McKenney wrote:
>>> On Mon, Mar 21, 2016 at 09:22:30AM -0700, Jacob Pan wrote:
>>>> On Fri, 18 Mar 2016 16:56:41 -0700
Hi Paul,
On 2016-03-22, Paul E. McKenney wrote:
> On Tue, Mar 22, 2016 at 04:35:32PM +0000, Chatre, Reinette wrote:
>> On 2016-03-21, Paul E. McKenney wrote:
>>> On Mon, Mar 21, 2016 at 09:22:30AM -0700, Jacob Pan wrote:
>>>> On Fri, 18 Mar 2016 16:56:41 -0700
On , Lukas Hejtmanek wrote:
> as of pre 2.6.25 kernels, kismet monitoring tool does not work with
> the message: # kismet
> Launching kismet_server: //usr/bin/kismet_server
> Suid priv-dropping disabled. This may not be secure.
> No specific sources given to be enabled, all will be enabled.
>
On Tuesday, February 19, 2008 1:20 PM, Wael Nasreddine wrote:
> Since the problem I am having is slightly different than the bugs
> above, I'm not sure I should post the debug there but feel free to
> post it if you think it is the same...
In this case, please create a new bug report for the
On Monday, February 18, 2008 7:47 AM, John W. Linville wrote:
> On Mon, Feb 18, 2008 at 05:54:25AM +0100, Wael Nasreddine wrote:
>> Hello,
>>
>> I have a Toshiba Satellite A135-S4427 with and Intel 3945ABG card,
>> the driver is not working properly.
>>
>> When I turn on my PC it works fine,
On Monday, February 18, 2008 7:47 AM, John W. Linville wrote:
On Mon, Feb 18, 2008 at 05:54:25AM +0100, Wael Nasreddine wrote:
Hello,
I have a Toshiba Satellite A135-S4427 with and Intel 3945ABG card,
the driver is not working properly.
When I turn on my PC it works fine, but If I ever
On Tuesday, February 19, 2008 1:20 PM, Wael Nasreddine wrote:
Since the problem I am having is slightly different than the bugs
above, I'm not sure I should post the debug there but feel free to
post it if you think it is the same...
In this case, please create a new bug report for the
On , Lukas Hejtmanek wrote:
as of pre 2.6.25 kernels, kismet monitoring tool does not work with
the message: # kismet
Launching kismet_server: //usr/bin/kismet_server
Suid priv-dropping disabled. This may not be secure.
No specific sources given to be enabled, all will be enabled.
On Wednesday, February 06, 2008 1:00 PM, Pavel Machek wrote:
> Hmmm... bugzilla says:
>
>* Exact steps to reproduce
>* Reproducability of bug (e.g. intermittent or 100% reproducable)
>* Did this problem not exist in previous version of the driver?
>* kernel version
>* AP
On Wednesday, February 06, 2008 1:00 PM, Pavel Machek wrote:
Hmmm... bugzilla says:
* Exact steps to reproduce
* Reproducability of bug (e.g. intermittent or 100% reproducable)
* Did this problem not exist in previous version of the driver?
* kernel version
* AP
On Tuesday, February 12, 2008 3:06 PM,
[EMAIL PROTECTED] wrote:
> From: Marcin Slusarz <[EMAIL PROTECTED]>
>
> replace all:
> little_endian_variable =
> cpu_to_leX(leX_to_cpu(little_endian_variable) +
> expression_in_cpu_byteorder);
> with:
>
On Tuesday, February 12, 2008 3:06 PM,
[EMAIL PROTECTED] wrote:
From: Marcin Slusarz [EMAIL PROTECTED]
replace all:
little_endian_variable =
cpu_to_leX(leX_to_cpu(little_endian_variable) +
expression_in_cpu_byteorder);
with:
On Wednesday, February 06, 2008 1:00 PM, Pavel Machek wrote:
>* dmesg output at debug level 0x43fff
> ~~~
> it would be nice to specify how to do this. It is
> insmod parameter, right?
correct. you can do this as follows:
$ insmod iwl3945
On Wednesday, February 06, 2008 6:32 AM, Pavel Machek wrote:
> On Tue 2008-02-05 18:20:58, Chatre, Reinette wrote:
>> On Tuesday, February 05, 2008 1:45 PM, Pavel Machek wrote:
>>
>>>
>>> ...I've reported this before, with full debugging. Not sure if
>&g
On Wednesday, February 06, 2008 6:32 AM, Pavel Machek wrote:
On Tue 2008-02-05 18:20:58, Chatre, Reinette wrote:
On Tuesday, February 05, 2008 1:45 PM, Pavel Machek wrote:
...I've reported this before, with full debugging. Not sure if
anything happened.
Could you please point me
On Wednesday, February 06, 2008 1:00 PM, Pavel Machek wrote:
* dmesg output at debug level 0x43fff
~~~
it would be nice to specify how to do this. It is
insmod parameter, right?
correct. you can do this as follows:
$ insmod iwl3945
On Tuesday, February 05, 2008 1:45 PM, Pavel Machek wrote:
>
> ...I've reported this before, with full debugging. Not sure if
> anything happened.
Could you please point me to where you have reported it before?
> Now, I got BUG() in iwl3945-base.c: 3824
Which driver and kernel are you
On Tuesday, February 05, 2008 1:45 PM, Pavel Machek wrote:
...I've reported this before, with full debugging. Not sure if
anything happened.
Could you please point me to where you have reported it before?
Now, I got BUG() in iwl3945-base.c: 3824
Which driver and kernel are you using?
Joonwoo Park <[EMAIL PROTECTED]> wrote:
> interrupt mask
>
> After enabling/disabling interrupts flushing is required
>
I have been looking at this patch and I would like to get some more
feedback from the experts in the group.
First off, the register used for the read in order to flush has
Joonwoo Park [EMAIL PROTECTED] wrote:
interrupt mask
After enabling/disabling interrupts flushing is required
I have been looking at this patch and I would like to get some more
feedback from the experts in the group.
First off, the register used for the read in order to flush has to be
On , Joonwoo Park wrote:
> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> @@ -6262,6 +6262,10 @@ static void __iwl_down(struct iwl_priv *priv)
> /* tell the device to stop sending interrupts */
> iwl_disable_interrupts(priv);
>
On , Joonwoo Park wrote:
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -6262,6 +6262,10 @@ static void __iwl_down(struct iwl_priv *priv)
/* tell the device to stop sending interrupts */
iwl_disable_interrupts(priv);
+
28 matches
Mail list logo
