On Thu, Feb 21, 2008 at 07:43:46AM +, Jarek Poplawski wrote:
...
> ...Or at least to mention APM in SUSPEND title and description.
> Actually, this is really strange: both SUSPEND and PM_SLEEP have
> default = y. So it seems they are intended to be more "advertised"
> tha
On Thu, Feb 21, 2008 at 07:43:46AM +, Jarek Poplawski wrote:
...
...Or at least to mention APM in SUSPEND title and description.
Actually, this is really strange: both SUSPEND and PM_SLEEP have
default = y. So it seems they are intended to be more advertised
than they are?
Now I see
On Thu, Feb 21, 2008 at 02:21:52AM +0100, Rafael J. Wysocki wrote:
> On Thursday, 21 of February 2008, Frans Pop wrote:
> > Rafael J. Wysocki wrote:
> > > On Wednesday, 20 of February 2008, Jarek Poplawski wrote:
> > >> So, has it to be so hard? It seems no
Hi,
I needed APM to have poweroff on old box. So, in 2.6.24.2 menuconfig:
1) Power management options -->
No APM.
2) [*] Power Management support
No APM. I can see ACPI...
3) I try searching with "/" + "APM"
APM [=n]
Depends on: !X86_VOYAGER && X86_32 && PM_SLEEP && !X86_VISWS
4) I
Hi,
I needed APM to have poweroff on old box. So, in 2.6.24.2 menuconfig:
1) Power management options --
No APM.
2) [*] Power Management support
No APM. I can see ACPI...
3) I try searching with / + APM
APM [=n]
Depends on: !X86_VOYAGER X86_32 PM_SLEEP !X86_VISWS
4) I check above:
On Thu, Feb 21, 2008 at 02:21:52AM +0100, Rafael J. Wysocki wrote:
On Thursday, 21 of February 2008, Frans Pop wrote:
Rafael J. Wysocki wrote:
On Wednesday, 20 of February 2008, Jarek Poplawski wrote:
So, has it to be so hard? It seems not - at least in good old times...
Something
On 19-02-2008 23:58, Adrian Bunk wrote:
...
> --- a/net/mac80211/ieee80211_sta.c
> +++ b/net/mac80211/ieee80211_sta.c
> @@ -1116,9 +1116,10 @@ static void ieee80211_sta_process_addba_request(struct
> net_device *dev,
...
> + printk(KERN_ERR "can not allocate reordering buffer
On 19-02-2008 23:58, Adrian Bunk wrote:
...
--- a/net/mac80211/ieee80211_sta.c
+++ b/net/mac80211/ieee80211_sta.c
@@ -1116,9 +1116,10 @@ static void ieee80211_sta_process_addba_request(struct
net_device *dev,
...
+ printk(KERN_ERR can not allocate reordering buffer
+
On Mon, Feb 18, 2008 at 02:45:56AM +0300, Oleg Nesterov wrote:
> On 02/17, Jarek Poplawski wrote:
...
> > 1) ... workqueue_cpu_callback(...)
...
> Yes, but this is harmless. cpu-hotplug callbacks are not time-critical,
> and cpu_down/cpu_up happens not often, and LIST_
Hi Oleg,
This patch looks OK to me. But while reading this I got some doubts
in nearby places, so BTW 2 small questions:
1) ... workqueue_cpu_callback(...)
{
...
list_for_each_entry(wq, , list) {
cwq = per_cpu_ptr(wq->cpu_wq, cpu);
switch (action)
On Mon, Feb 18, 2008 at 02:45:56AM +0300, Oleg Nesterov wrote:
On 02/17, Jarek Poplawski wrote:
...
1) ... workqueue_cpu_callback(...)
...
Yes, but this is harmless. cpu-hotplug callbacks are not time-critical,
and cpu_down/cpu_up happens not often, and LIST_HEAD(workqueues) is not
very long
Jarek Poplawski wrote, On 02/15/2008 10:03 PM:
...
> ...On the other hand this:
>
>> Feb 15 15:50:17 217.151.X.X [1521315.068984] BUG: spinlock lockup on CPU#1,
>> ksoftirqd/1/7, f0551180
>
> seems to point just at spinlock lockup, so it's more about the full report.
Jarek Poplawski wrote, On 02/15/2008 09:21 PM:
> Denys Fedoryshchenko wrote, On 02/15/2008 08:42 PM:
> ...
>
>> I have similar crashes on completely different hardware with same job (QOS),
>> so i think it is actually some nasty bug in networking.
>
> Maybe yo
Denys Fedoryshchenko wrote, On 02/15/2008 08:42 PM:
...
> I have similar crashes on completely different hardware with same job (QOS),
> so i think it is actually some nasty bug in networking.
Maybe you could try with some other debugging options? E.g. since lockdep
doesn't help - turn this
Jarek Poplawski wrote, On 02/15/2008 09:21 PM:
Denys Fedoryshchenko wrote, On 02/15/2008 08:42 PM:
...
I have similar crashes on completely different hardware with same job (QOS),
so i think it is actually some nasty bug in networking.
Maybe you could try with some other debugging
Denys Fedoryshchenko wrote, On 02/15/2008 08:42 PM:
...
I have similar crashes on completely different hardware with same job (QOS),
so i think it is actually some nasty bug in networking.
Maybe you could try with some other debugging options? E.g. since lockdep
doesn't help - turn this off.
Jarek Poplawski wrote, On 02/15/2008 10:03 PM:
...
...On the other hand this:
Feb 15 15:50:17 217.151.X.X [1521315.068984] BUG: spinlock lockup on CPU#1,
ksoftirqd/1/7, f0551180
seems to point just at spinlock lockup, so it's more about the full report.
I wonder if this patch to prink
On Tue, Feb 12, 2008 at 08:32:18PM +0100, Jarek Poplawski wrote:
...
> It seems the above version of this macro uses the barrier for 0, but
> if I miss something, or for these other: documenting reasons,
...or __builtin_constants could be used for indexing (?!),
> then of
> course y
On Tue, Feb 12, 2008 at 08:07:29AM -0800, Paul E. McKenney wrote:
...
> "All programmers are blind, especially me."
Hmm... I got it my way: you - superheroes - sometimes seem to be just
like us - common people... (Probably early in the morning, before
dressing your funny costumes?)
> You are
On 12-02-2008 02:16, David Miller wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Mon, 11 Feb 2008 16:59:54 -0800
>
> linux-kernel added to CC:, any change to generic kernel infrastructure
> should be posted there
>
>> Eliminate warnings when rcu_assign_pointer is used with unsigned
On 12-02-2008 02:16, David Miller wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Mon, 11 Feb 2008 16:59:54 -0800
linux-kernel added to CC:, any change to generic kernel infrastructure
should be posted there
Eliminate warnings when rcu_assign_pointer is used with unsigned long.
It
On Tue, Feb 12, 2008 at 08:32:18PM +0100, Jarek Poplawski wrote:
...
It seems the above version of this macro uses the barrier for 0, but
if I miss something, or for these other: documenting reasons,
...or __builtin_constants could be used for indexing (?!),
then of
course you are right
On 22-01-2008 01:55, Dave Young wrote:
...
> Hi, thanks your effort. Now I think we should stop this thread and
> waiting the class_device going away :)
Sure! But, if you change your mind I'm interested in this subject.
Thanks,
Jarek P.
--
To unsubscribe from this list: send the line
Dave Young wrote, On 01/21/2008 09:44 AM:
...
> I applied it in my kernel, built and run without warnings, but it need
> more testing.
> I will be very glad to see the test result about this if you could, thanks.
Bad news. (Alas I won't be able to check this today.)
On Mon, Jan 21, 2008 at 04:44:36PM +0800, Dave Young wrote:
...
> I applied it in my kernel, built and run without warnings, but it need
> more testing.
> I will be very glad to see the test result about this if you could, thanks.
I'll try this of course, but alas I don't have anything such more
On Mon, Jan 21, 2008 at 09:43:35AM +0800, Dave Young wrote:
...
> Convert the class semaphore to mutex.
> class_interface_register/unregister use class_device_* functions, so
> SINGLE_DEPTH_NESTING added for lockdep please in these functions.
Looks fine to me now, but... I think you forgot
On Mon, Jan 21, 2008 at 04:44:36PM +0800, Dave Young wrote:
...
I applied it in my kernel, built and run without warnings, but it need
more testing.
I will be very glad to see the test result about this if you could, thanks.
I'll try this of course, but alas I don't have anything such more
On Mon, Jan 21, 2008 at 09:43:35AM +0800, Dave Young wrote:
...
Convert the class semaphore to mutex.
class_interface_register/unregister use class_device_* functions, so
SINGLE_DEPTH_NESTING added for lockdep please in these functions.
Looks fine to me now, but... I think you forgot again
Dave Young wrote, On 01/21/2008 09:44 AM:
...
I applied it in my kernel, built and run without warnings, but it need
more testing.
I will be very glad to see the test result about this if you could, thanks.
Bad news. (Alas I won't be able to check this today.)
On 22-01-2008 01:55, Dave Young wrote:
...
Hi, thanks your effort. Now I think we should stop this thread and
waiting the class_device going away :)
Sure! But, if you change your mind I'm interested in this subject.
Thanks,
Jarek P.
--
To unsubscribe from this list: send the line unsubscribe
Dave Young wrote, On 01/18/2008 10:07 AM:
> On Jan 18, 2008 4:23 PM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>> On Fri, Jan 18, 2008 at 03:48:02PM +0800, Dave Young wrote:
...
>>> 1) Using CLASS_NORMAL/CLASS_PARENT/CLASS_CHILD will be enough.
>>> or
>&
Dave Young wrote, On 01/18/2008 10:07 AM:
On Jan 18, 2008 4:23 PM, Jarek Poplawski [EMAIL PROTECTED] wrote:
On Fri, Jan 18, 2008 at 03:48:02PM +0800, Dave Young wrote:
...
1) Using CLASS_NORMAL/CLASS_PARENT/CLASS_CHILD will be enough.
or
2) Simply add SINGLE_LEVEL_NESTING
On Fri, Jan 18, 2008 at 11:45:12AM +0100, Kay Sievers wrote:
> On Fri, 2008-01-18 at 08:38 +0100, Jarek Poplawski wrote:
> > On Fri, Jan 18, 2008 at 01:31:17PM +0800, Dave Young wrote:
> > > On Jan 18, 2008 11:18 AM, Kay Sievers <[EMAIL PROTECTED]> wrote:
> > ...
On Fri, Jan 18, 2008 at 09:00:34AM +0100, Jarek Poplawski wrote:
> On Fri, Jan 18, 2008 at 09:42:25AM +0800, Dave Young wrote:
> ...
> > After digging the class usage code again, I found that the only
> > possible double lock place is the class_interface_register/unreg
On Fri, Jan 18, 2008 at 03:48:02PM +0800, Dave Young wrote:
> On Jan 18, 2008 3:38 PM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
...
> > IMHO, it would be nice to get the real state of current lockdep
> > problems here to figure out if there is any chance to do this ri
On Fri, Jan 18, 2008 at 09:00:34AM +0100, Jarek Poplawski wrote:
On Fri, Jan 18, 2008 at 09:42:25AM +0800, Dave Young wrote:
...
After digging the class usage code again, I found that the only
possible double lock place is the class_interface_register/unregister
in which the class_device
On Fri, Jan 18, 2008 at 11:45:12AM +0100, Kay Sievers wrote:
On Fri, 2008-01-18 at 08:38 +0100, Jarek Poplawski wrote:
On Fri, Jan 18, 2008 at 01:31:17PM +0800, Dave Young wrote:
On Jan 18, 2008 11:18 AM, Kay Sievers [EMAIL PROTECTED] wrote:
...
Yeah, might be better to wait until
On Fri, Jan 18, 2008 at 09:42:25AM +0800, Dave Young wrote:
...
> After digging the class usage code again, I found that the only
> possible double lock place is the class_interface_register/unregister
> in which the class_device api could be called.
OK, but currently after using mostly:
On Fri, Jan 18, 2008 at 01:31:17PM +0800, Dave Young wrote:
> On Jan 18, 2008 11:18 AM, Kay Sievers <[EMAIL PROTECTED]> wrote:
...
> > Yeah, might be better to wait until class_device is gone, otherwise you
> > may need to fix stuff that is just going to be removed. Your change to
> > have
On Thu, Jan 17, 2008 at 09:31:55PM +0100, Jarek Poplawski wrote:
> On Thu, Jan 17, 2008 at 02:57:36PM -0500, Alan Stern wrote:
> > On Thu, 17 Jan 2008, Jarek Poplawski wrote:
> >
> > > On Thu, Jan 17, 2008 at 10:16:30AM -0500, Alan Stern wrote:
> > > > O
On Thu, Jan 17, 2008 at 09:31:55PM +0100, Jarek Poplawski wrote:
> On Thu, Jan 17, 2008 at 02:57:36PM -0500, Alan Stern wrote:
...
> > If I recall correctly the nature of the warning was that a method
> > routine for one class (called with the class's mutex held) was creating
>
On Thu, Jan 17, 2008 at 01:11:01PM -0800, Greg KH wrote:
...
> I've known Greg to make lots of mistakes :)
Right! Above is one example...
> I don't remember ever saying that the "code is correct with the lockdep
> warnings", I think I said, "Make sure there are no lockdep warnings with
> any
On Thu, Jan 17, 2008 at 02:57:36PM -0500, Alan Stern wrote:
> On Thu, 17 Jan 2008, Jarek Poplawski wrote:
>
> > On Thu, Jan 17, 2008 at 10:16:30AM -0500, Alan Stern wrote:
> > > On Thu, 17 Jan 2008, Dave Young wrote:
> > >
> > > > > Your meaning isn'
On Thu, Jan 17, 2008 at 10:16:30AM -0500, Alan Stern wrote:
> On Thu, 17 Jan 2008, Dave Young wrote:
>
> > > Your meaning isn't clear. Do you mean that your patch doesn't generate
> > > any lockdep warnings at all? Or do you mean that it generates a single
> > > lockdep warning at boot time and
On 17-01-2008 02:17, Dave Young wrote:
> On Jan 16, 2008 4:34 PM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>> On Wed, Jan 16, 2008 at 09:03:03AM +0800, Dave Young wrote:
>> ...
>>> The lockdep warining was posted in the below thread, actually, I have
>&g
On 17-01-2008 02:17, Dave Young wrote:
On Jan 16, 2008 4:34 PM, Jarek Poplawski [EMAIL PROTECTED] wrote:
On Wed, Jan 16, 2008 at 09:03:03AM +0800, Dave Young wrote:
...
The lockdep warining was posted in the below thread, actually, I have
built and run this patced kernel for several days
On Thu, Jan 17, 2008 at 10:16:30AM -0500, Alan Stern wrote:
On Thu, 17 Jan 2008, Dave Young wrote:
Your meaning isn't clear. Do you mean that your patch doesn't generate
any lockdep warnings at all? Or do you mean that it generates a single
lockdep warning at boot time and then no
On Thu, Jan 17, 2008 at 02:57:36PM -0500, Alan Stern wrote:
On Thu, 17 Jan 2008, Jarek Poplawski wrote:
On Thu, Jan 17, 2008 at 10:16:30AM -0500, Alan Stern wrote:
On Thu, 17 Jan 2008, Dave Young wrote:
Your meaning isn't clear. Do you mean that your patch doesn't
generate
On Thu, Jan 17, 2008 at 09:31:55PM +0100, Jarek Poplawski wrote:
On Thu, Jan 17, 2008 at 02:57:36PM -0500, Alan Stern wrote:
...
If I recall correctly the nature of the warning was that a method
routine for one class (called with the class's mutex held) was creating
a second class
On Thu, Jan 17, 2008 at 01:11:01PM -0800, Greg KH wrote:
...
I've known Greg to make lots of mistakes :)
Right! Above is one example...
I don't remember ever saying that the code is correct with the lockdep
warnings, I think I said, Make sure there are no lockdep warnings with
any conversion
On Thu, Jan 17, 2008 at 09:31:55PM +0100, Jarek Poplawski wrote:
On Thu, Jan 17, 2008 at 02:57:36PM -0500, Alan Stern wrote:
On Thu, 17 Jan 2008, Jarek Poplawski wrote:
On Thu, Jan 17, 2008 at 10:16:30AM -0500, Alan Stern wrote:
On Thu, 17 Jan 2008, Dave Young wrote:
Your
On Fri, Jan 18, 2008 at 01:31:17PM +0800, Dave Young wrote:
On Jan 18, 2008 11:18 AM, Kay Sievers [EMAIL PROTECTED] wrote:
...
Yeah, might be better to wait until class_device is gone, otherwise you
may need to fix stuff that is just going to be removed. Your change to
have iterators for
On Fri, Jan 18, 2008 at 09:42:25AM +0800, Dave Young wrote:
...
After digging the class usage code again, I found that the only
possible double lock place is the class_interface_register/unregister
in which the class_device api could be called.
OK, but currently after using mostly:
On Wed, Jan 16, 2008 at 10:27:54AM -0500, Alan Stern wrote:
> On Wed, 16 Jan 2008, Dave Young wrote:
>
> > The lockdep warining was posted in the below thread, actually, I have
> > built and run this patced kernel for several days, there's no more
> > warnings.
> > http://lkml.org/lkml/2008/1/3/2
On Wed, Jan 16, 2008 at 09:04:58PM +0100, Willy Tarreau wrote:
...
> you can work with latest release provided that you always have a fallback
> to an earlier one. That way, you don't bet too much on something you don't
> completely control. If it works, it tells you you'll be able to completely
>
On Wed, Jan 16, 2008 at 09:03:03AM +0800, Dave Young wrote:
...
> The lockdep warining was posted in the below thread, actually, I have
> built and run this patced kernel for several days, there's no more
> warnings.
> http://lkml.org/lkml/2008/1/3/2
Right... But, with something like this:
...
On Wed, Jan 16, 2008 at 09:03:03AM +0800, Dave Young wrote:
...
The lockdep warining was posted in the below thread, actually, I have
built and run this patced kernel for several days, there's no more
warnings.
http://lkml.org/lkml/2008/1/3/2
Right... But, with something like this:
...
On Wed, Jan 16, 2008 at 09:04:58PM +0100, Willy Tarreau wrote:
...
you can work with latest release provided that you always have a fallback
to an earlier one. That way, you don't bet too much on something you don't
completely control. If it works, it tells you you'll be able to completely
On Wed, Jan 16, 2008 at 11:17:08AM +1100, Herbert Xu wrote:
...
> Well people are always going to operate on this model for commercial
> reasons. FWIW I used to work for a company that stuck to a specific
> version of the Linux kernel, and I suppose I still do even now :)
>
> But the important
On Tue, Jan 15, 2008 at 08:47:07AM -0600, Chris Friesen wrote:
> Jarek Poplawski wrote:
>
>> IMHO, checking this with a current stable, which probably you are going
>> to do some day, anyway, should be 100% acceptable: giving some input to
>> netdev, while still working f
On Tue, Jan 15, 2008 at 05:15:27PM +0800, Dave Young wrote:
> Convert the class semaphore to mutex.
>
> Signed-off-by: Dave Young <[EMAIL PROTECTED]>
>
> ---
> drivers/base/class.c | 38 +++---
> drivers/base/core.c| 18 --
>
On Tue, Jan 15, 2008 at 05:15:27PM +0800, Dave Young wrote:
Convert the class semaphore to mutex.
Signed-off-by: Dave Young [EMAIL PROTECTED]
---
drivers/base/class.c | 38 +++---
drivers/base/core.c| 18 --
On Tue, Jan 15, 2008 at 08:47:07AM -0600, Chris Friesen wrote:
Jarek Poplawski wrote:
IMHO, checking this with a current stable, which probably you are going
to do some day, anyway, should be 100% acceptable: giving some input to
netdev, while still working for yourself.
While I would love
On Wed, Jan 16, 2008 at 11:17:08AM +1100, Herbert Xu wrote:
...
Well people are always going to operate on this model for commercial
reasons. FWIW I used to work for a company that stuck to a specific
version of the Linux kernel, and I suppose I still do even now :)
But the important thing
On 14-01-2008 16:58, Chris Friesen wrote:
...
> How close to bleeding edge do we need to be for it to be considered
> acceptable to ask questions on netdev?
>
> Given that the embedded space tends to be perpetually stuck on older
> kernels (our "current" release is based on 2.6.14) do you have
On 14-01-2008 16:58, Chris Friesen wrote:
...
How close to bleeding edge do we need to be for it to be considered
acceptable to ask questions on netdev?
Given that the embedded space tends to be perpetually stuck on older
kernels (our current release is based on 2.6.14) do you have any
On Mon, Jan 14, 2008 at 09:36:04AM +0800, Dave Young wrote:
> On Jan 13, 2008 4:11 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
...
> > Probably some tiny oversight, but I see this comment to struct class
> > doesn't mention devices list, so maybe this needs to be update
On Mon, Jan 14, 2008 at 09:36:04AM +0800, Dave Young wrote:
On Jan 13, 2008 4:11 AM, Jarek Poplawski [EMAIL PROTECTED] wrote:
...
Probably some tiny oversight, but I see this comment to struct class
doesn't mention devices list, so maybe this needs to be updated BTW?:
(from include/linux
On Sat, Jan 12, 2008 at 05:47:54PM +0800, Dave Young wrote:
> Add the following class iteration functions for driver use:
> class_for_each_device
> class_find_device
> class_for_each_child
> class_find_child
>
> Signed-off-by: Dave Young <[EMAIL PROTECTED]>
>
> ---
> drivers/base/class.c |
On Sat, Jan 12, 2008 at 05:47:54PM +0800, Dave Young wrote:
Add the following class iteration functions for driver use:
class_for_each_device
class_find_device
class_for_each_child
class_find_child
Signed-off-by: Dave Young [EMAIL PROTECTED]
---
drivers/base/class.c | 159
On Wed, Jan 09, 2008 at 08:57:53AM +0900, FUJITA Tomonori wrote:
...
> diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
> new file mode 100644
> index 000..495575a
> --- /dev/null
> +++ b/lib/iommu-helper.c
> @@ -0,0 +1,80 @@
> +/*
> + * IOMMU helper functions for the free area management
On Wed, Jan 09, 2008 at 08:57:53AM +0900, FUJITA Tomonori wrote:
...
diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
new file mode 100644
index 000..495575a
--- /dev/null
+++ b/lib/iommu-helper.c
@@ -0,0 +1,80 @@
+/*
+ * IOMMU helper functions for the free area management
+ */
+
On 08-01-2008 06:59, Al Viro wrote:
> On Mon, Jan 07, 2008 at 07:26:12PM -0800, Linus Torvalds wrote:
>
>> I usually just compile a small program like
>>
>> const char array[]="\xnn\xnn\xnn...";
>>
>> int main(int argc, char **argv)
>> {
>> printf("%p\n", array);
>>
On Mon, Jan 07, 2008 at 02:23:33PM +0100, Stefan Richter wrote:
> David Brownell wrote:
> > On Monday 07 January 2008, Greg KH wrote:
> >> Most of the non-driver core code should be converted to not use the
> >> lock in the class at all. They should use a local lock instead.
> >
> > Or better
On Mon, Jan 07, 2008 at 02:23:33PM +0100, Stefan Richter wrote:
David Brownell wrote:
On Monday 07 January 2008, Greg KH wrote:
Most of the non-driver core code should be converted to not use the
lock in the class at all. They should use a local lock instead.
Or better yet, that
On 08-01-2008 06:59, Al Viro wrote:
On Mon, Jan 07, 2008 at 07:26:12PM -0800, Linus Torvalds wrote:
I usually just compile a small program like
const char array[]=\xnn\xnn\xnn...;
int main(int argc, char **argv)
{
printf(%p\n, array);
*(int
On Sun, Jan 06, 2008 at 11:30:48AM +0100, Torsten Kaiser wrote:
...
> I think this bug is highly timing dependent. Its not always the same
> package that dies and as this is a SMP system I would guess two CPUs
> using the same data will trigger this.
> And using the poison-option will definitily
On Sat, Jan 05, 2008 at 03:52:32PM +0100, Torsten Kaiser wrote:
...
> So my personal conclusion would be, that someone is writing to memory
> that he no longer owns. Most probably 0-bytes. (the complete_routine
> got NULLed and the warning about dst->__refcnt being 0).
>
> Use-after-free or
On Sat, Jan 05, 2008 at 03:52:32PM +0100, Torsten Kaiser wrote:
...
So my personal conclusion would be, that someone is writing to memory
that he no longer owns. Most probably 0-bytes. (the complete_routine
got NULLed and the warning about dst-__refcnt being 0).
Use-after-free or something
On Sun, Jan 06, 2008 at 11:30:48AM +0100, Torsten Kaiser wrote:
...
I think this bug is highly timing dependent. Its not always the same
package that dies and as this is a SMP system I would guess two CPUs
using the same data will trigger this.
And using the poison-option will definitily slow
On Sat, Jan 05, 2008 at 09:01:02AM +0100, Torsten Kaiser wrote:
> On Jan 5, 2008 1:07 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > On Fri, Jan 04, 2008 at 04:21:26PM +0100, Torsten Kaiser wrote:
> > > On Jan 4, 2008 2:30 PM, Jarek Poplawski <[EMAIL PROTECTED]&g
On Sat, Jan 05, 2008 at 09:01:02AM +0100, Torsten Kaiser wrote:
On Jan 5, 2008 1:07 AM, Jarek Poplawski [EMAIL PROTECTED] wrote:
On Fri, Jan 04, 2008 at 04:21:26PM +0100, Torsten Kaiser wrote:
On Jan 4, 2008 2:30 PM, Jarek Poplawski [EMAIL PROTECTED] wrote:
The only thing that is sadly
On Fri, Jan 04, 2008 at 04:21:26PM +0100, Torsten Kaiser wrote:
> On Jan 4, 2008 2:30 PM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
...
> I'm open for any suggestions and will try to answer any questions.
I'm very glad, thanks!
> The only thing that is sadly not practic
On 04-01-2008 11:23, Torsten Kaiser wrote:
> On Jan 2, 2008 10:51 PM, Herbert Xu <[EMAIL PROTECTED]> wrote:
>> On Wed, Jan 02, 2008 at 07:29:59PM +0100, Torsten Kaiser wrote:
>>> Vanilla 2.6.24-rc6 seems stable. I did not see any crash or warnings.
>> OK that's great. The next step would be to
On 04-01-2008 11:23, Torsten Kaiser wrote:
On Jan 2, 2008 10:51 PM, Herbert Xu [EMAIL PROTECTED] wrote:
On Wed, Jan 02, 2008 at 07:29:59PM +0100, Torsten Kaiser wrote:
Vanilla 2.6.24-rc6 seems stable. I did not see any crash or warnings.
OK that's great. The next step would be to try
On Fri, Jan 04, 2008 at 04:21:26PM +0100, Torsten Kaiser wrote:
On Jan 4, 2008 2:30 PM, Jarek Poplawski [EMAIL PROTECTED] wrote:
...
I'm open for any suggestions and will try to answer any questions.
I'm very glad, thanks!
The only thing that is sadly not practical is bisecting the borkenout
On Thu, Jan 03, 2008 at 03:21:36PM +0800, Dave Young wrote:
...
> I don't know if there's other possible warning places with this mutex
> or not, if you have any ideas about this, please tell me.
I think lockdep is just to tell such things. So, the question is, how
much it was tested already,
On Thu, Jan 03, 2008 at 08:06:09AM +0100, Jarek Poplawski wrote:
> On Thu, Jan 03, 2008 at 01:50:20PM +0800, Dave Young wrote:
> > Convert semaphore to mutex in struct class.
> ...
> > One lockdep warning detected as following, thus use mutex_lock_nested with
> &
On Thu, Jan 03, 2008 at 01:50:20PM +0800, Dave Young wrote:
> Convert semaphore to mutex in struct class.
...
> One lockdep warning detected as following, thus use mutex_lock_nested with
> SINGLE_DEPTH_NESTING in class_device_add
>
> Jan 3 10:45:15 darkstar kernel:
On Wed, Jan 02, 2008 at 01:39:38PM +0100, Jarek Poplawski wrote:
> On 02-01-2008 08:00, Greg KH wrote:
> ...
> > If no one has noticed any issues in this area, [...]
BTW, if 'we' are sure there are no issues, and only lockdep is not
clever enough yet, why not do such a change pa
On 02-01-2008 08:00, Greg KH wrote:
...
> If no one has noticed any issues in this area, [...]
...Could also mean there are hidden issues, so it doesn't look like
very convincing argument.
...Unless after the change there will be found no hidden issues,
then, of course, it looks like convincing
On 02-01-2008 08:00, Greg KH wrote:
...
If no one has noticed any issues in this area, [...]
...Could also mean there are hidden issues, so it doesn't look like
very convincing argument.
...Unless after the change there will be found no hidden issues,
then, of course, it looks like convincing
On Wed, Jan 02, 2008 at 01:39:38PM +0100, Jarek Poplawski wrote:
On 02-01-2008 08:00, Greg KH wrote:
...
If no one has noticed any issues in this area, [...]
BTW, if 'we' are sure there are no issues, and only lockdep is not
clever enough yet, why not do such a change partially, e.g
On Thu, Jan 03, 2008 at 01:50:20PM +0800, Dave Young wrote:
Convert semaphore to mutex in struct class.
...
One lockdep warning detected as following, thus use mutex_lock_nested with
SINGLE_DEPTH_NESTING in class_device_add
Jan 3 10:45:15 darkstar kernel:
On Thu, Jan 03, 2008 at 08:06:09AM +0100, Jarek Poplawski wrote:
On Thu, Jan 03, 2008 at 01:50:20PM +0800, Dave Young wrote:
Convert semaphore to mutex in struct class.
...
One lockdep warning detected as following, thus use mutex_lock_nested with
SINGLE_DEPTH_NESTING in class_device_add
On Thu, Jan 03, 2008 at 03:21:36PM +0800, Dave Young wrote:
...
I don't know if there's other possible warning places with this mutex
or not, if you have any ideas about this, please tell me.
I think lockdep is just to tell such things. So, the question is, how
much it was tested already,
Jarek Poplawski wrote, On 11/27/2007 11:15 PM:
> Adrian Bunk wrote, On 11/27/2007 05:47 PM:
...
>> There is nothing like a "right of choice".
(very late) PS:
...I was a bit confused with this, wondering: so, we've envied you
(the West) this "thing" for so many
Jarek Poplawski wrote, On 11/27/2007 11:15 PM:
Adrian Bunk wrote, On 11/27/2007 05:47 PM:
...
There is nothing like a right of choice.
(very late) PS:
...I was a bit confused with this, wondering: so, we've envied you
(the West) this thing for so many years, and now it seems, you have
[EMAIL PROTECTED] wrote, On 12/24/2007 07:18 PM:
> Hello again.
> Its bug depend to
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4aae07025265151e3f7041dfbf0f529e122de1d8
> ?
Hello Vyacheslav!
I wonder why do you think there is such a dependency, and why do you
[EMAIL PROTECTED] wrote, On 12/24/2007 07:18 PM:
Hello again.
Its bug depend to
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4aae07025265151e3f7041dfbf0f529e122de1d8
?
Hello Vyacheslav!
I wonder why do you think there is such a dependency, and why do you
1 - 100 of 821 matches
Mail list logo
