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 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 ch
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_HEAD(wor
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, &workqueues, list) {
cwq = per_cpu_ptr(wq->cpu_wq, cpu);
switc
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 rep
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 off.
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 rig
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 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/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
s
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/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
>>
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:
> > ...
&g
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/unregiste
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: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:
mutex_loc
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 iterator
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 creatin
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 conv
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 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:
... ha
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 th
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 --
> include/lin
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 a
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 u
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 | 1
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 yet
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 sl
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 someth
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 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 p
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 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, bec
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 chang
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 e
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
[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 r
Andrew Morton wrote, On 12/15/2007 12:13 PM:
> On Fri, 14 Dec 2007 22:58:24 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
...
>> I applied the patch and then tried my test again. This time my system
>> locked up.
>> Perhaps I should open a new thread for this, since the problem looks
>> prett
Andrew Morton wrote, On 12/15/2007 12:13 PM:
> On Fri, 14 Dec 2007 22:58:24 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
>
>> On Dec 14, 2007 6:36 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>>> On Fri, 14 Dec 2007 17:13:21 -0500
>>> "Miles Lane" <[EMAIL PROTECTED]> wrote:
...
Pid: 6944, c
David Miller wrote, On 12/13/2007 11:34 PM:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Thu, 13 Dec 2007 23:28:41 +0100
>
>> ...I'm afraid I can't understand: I mean doing the same but without
>> passing this info with 'work == weight': if
David Miller wrote, On 12/13/2007 09:37 PM:
...
> For example, if we export the list handling widget into the ->poll()
> routines, god help the person who wants to change how the poll list is
> managed in net_rx_action() :-/
...I'm afraid I can't understand: I mean doing the same but without
pass
Stephen Hemminger wrote, On 12/13/2007 09:41 PM:
> David Miller wrote:
>> From: Jarek Poplawski <[EMAIL PROTECTED]>
>> Date: Thu, 13 Dec 2007 21:16:12 +0100
>>
>>
>>> I see in a nearby thread you would prefer to save some work to drivers
>>>
David Miller wrote, On 12/13/2007 02:50 PM:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Thu, 13 Dec 2007 14:49:53 +0100
>
>> As a matter of fact, since it's "unlikely()" in net_rx_action() anyway,
>> I wonder what is the main reason or gain of l
On Thu, Dec 13, 2007 at 05:50:13AM -0800, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Thu, 13 Dec 2007 14:49:53 +0100
>
> > As a matter of fact, since it's "unlikely()" in net_rx_action() anyway,
> > I wonder what is the ma
On 12-12-2007 19:41, Kok, Auke wrote:
> David Miller wrote:
>> From: Andrew Gallatin <[EMAIL PROTECTED]>
>> Date: Wed, 12 Dec 2007 12:29:23 -0500
>>
>>> Is the netif_running() check even required?
>> No, it is not.
>>
>> When a device is brought down, one of the first things
>> that happens is that
Peter Zijlstra wrote, On 12/08/2007 09:50 PM:
> On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote:
>
>> Which problems? I did not see any special things, it looked rather
>> straight forward. What have I overlooked?
>
> On suspend it locks the whole device tree, this means it has 'unbounded'
Arjan van de Ven wrote, On 12/05/2007 10:26 PM:
> On Wed, 05 Dec 2007 21:15:30 +0100
> Holger Wolf <[EMAIL PROTECTED]> wrote:
...
>> a 2.6.23 kernel. We saw a throughput degradation from 7.2 to 23.4
>
> this is good news!
> dbench rewards unfair behavior... so higher dbench usually means a
> wo
On 04-12-2007 23:26, Jarek Poplawski wrote:
...
> But, IMHO, blowing ASSERT_RTNL up in a few places shouldn't be much
> worse. After all, how long such a debugging code should be kept. It
> seems, at least sometimes we should be a bit more confident of how
> it's called.
I
Joonwoo Park wrote, On 12/04/2007 10:48 AM:
> Hi,
> dev_set_rx_mode calls __dev_set_rx_mode with softirq disabled (by
> netif_tx_lock_bh)
> therefore __dev_set_promiscuity can be called with softirq disabled.
> It will cause in_interrupt() to return true and ASSERT_RTNL warning.
> Is there a good
Alan Stern wrote, On 12/04/2007 08:28 PM:
> On Tue, 4 Dec 2007, Jarek Poplawski wrote:
...
> But you have to consider hypothetical kernel bugs. That's exactly what
> lockdep is for -- to warn you about possible deadlocks that could be
> caused by bugs.
>
> As a simpl
Alan Stern wrote, On 12/04/2007 04:17 PM:
...
> Furthermore, in this case deadlock isn't really impossible -- it could
> occur if there were a bug somewhere else in the kernel. So lockdep was
> correct to warn that deadlock might occur.
Alan, if the scenario was like you described at the begi
Alan Stern wrote, On 12/03/2007 04:08 PM:
> On Mon, 3 Dec 2007, Jarek Poplawski wrote:
>
>>> System sleep start:
>>> down_read(notifier-chain rwsem);
>>> call the notifier routine
>>> down_write(&system_sle
On 02-12-2007 20:45, Alan Stern wrote:
> Ingo:
>
> I ran into a lockdep reporting issue just now with some new code under
> development. I think it's a false positive; the question is how best
> to deal with it.
>
> Here's the situation. The new code runs during a system sleep (i.e.,
> suspe
On 30-11-2007 00:03, Neil Brown wrote:
> On Friday November 30, [EMAIL PROTECTED] wrote:
...
>> Or have I just not had enough coffee this morning?
>
> :-) And I cannot even blame the lack of coffee as I don't drink it.
>
Looks like logical error...
(Or I haven't had enough coffee this morning
On 30-11-2007 04:32, H. Peter Anvin wrote:
...
> As far as I can tell, Documentation/Changes is the only thing we have
> that even attempts to document the basic requirements. This attempts
> to formalize that fact.
>
> Documentation/Changes | 396
> ---
On 29-11-2007 03:34, David Schwartz wrote:
>> Thanks for the help. Someday, I hope to understand this stuff.
>>
>> Larry
>
> Any code either deals with an object or it doesn't. If it doesn't deal with
> that object, it should not be acquiring locks on that object. If it does
> deal with that objec
On Wed, Nov 28, 2007 at 03:33:12PM -0800, Stephen Hemminger wrote:
...
> WTF are you teaching a lesson on how NOT to do locking?
>
> Any code which has this kind of convoluted dependency on conditional
> locking is fundamentally broken.
>
As a matter of fact I've been thinking, about one more Re
Jarek Poplawski wrote, On 11/28/2007 11:56 PM:
> Jarek Poplawski wrote, On 11/28/2007 11:45 PM:
>
>> Larry Finger wrote, On 11/28/2007 04:41 PM:
>>
>>> Andreas Schwab wrote:
>>>> Larry Finger <[EMAIL PROTECTED]> writes:
>>>>
>>&
Jarek Poplawski wrote, On 11/28/2007 11:45 PM:
> Larry Finger wrote, On 11/28/2007 04:41 PM:
>
>> Andreas Schwab wrote:
>>> Larry Finger <[EMAIL PROTECTED]> writes:
>>>
>>>> If a particular routine needs to lock a mutex, but it may be entered with
Larry Finger wrote, On 11/28/2007 04:41 PM:
> 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_trylo
Adrian Bunk wrote, On 11/27/2007 11:53 PM:
> On Tue, Nov 27, 2007 at 11:15:48PM +0100, Jarek Poplawski wrote:
...
> Most Google hits are about abortion.
>
> The fact that people use this term in some completely different
> context does not give it the meaning you implied it ha
Jarek Poplawski wrote, On 11/27/2007 11:15 PM:
...
> Otherwise it's not so hard to overlook some stagnation.
Btw., after this 'forking' thing etc. it seems I might have lost the point
a little: which removed choices should justify such a fork. But, I hope,
you didn'
Adrian Bunk wrote, On 11/27/2007 05:47 PM:
> On Tue, Nov 27, 2007 at 08:09:12AM +0100, Jarek Poplawski wrote:
>> On 25-11-2007 18:22, Jens Axboe wrote:
>>> On Sun, Nov 25 2007, Adrian Bunk wrote:
>> ...
>>>> Is there any technical reason why we need 4 diffe
On Tue, Nov 27, 2007 at 09:50:38AM +0100, Jarek Poplawski wrote:
...
> with any "you should" if possible.
without any "you should" if possible.
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On 26-11-2007 22:02, Rafael J. Wysocki wrote:
...
>
> For completness, below is an updated version of the patch, modified to take
> some Adrian's comments into account.
>
> Comments welcome.
...You mean any comments?...
Well, I've written something similar about something similar somewhere
else
On 25-11-2007 18:22, Jens Axboe wrote:
> On Sun, Nov 25 2007, Adrian Bunk wrote:
...
>> Is there any technical reason why we need 4 different schedulers at all?
>
> Until we have the perfect scheduler :-)
IMHO this is not enough yet. There is something called "the right
of choice", and, it seems,
Petr Baudis wrote, On 11/21/2007 04:18 PM:
> On Wed, Nov 21, 2007 at 08:52:17AM +0100, Jarek Poplawski wrote:
>> ...
>> tags
>> 4 days ago v2.6.24-rc3 Linux 2.6.24-rc3
>> 2 weeks ago v2.6.24-rc2 Linux 2.6.24-rc2
>> 4 weeks ago v2.6.24-rc1 Linux 2
Kay Sievers wrote, On 11/21/2007 05:06 PM:
> On Nov 21, 2007 8:52 AM, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>> On Tue, Nov 20, 2007 at 10:20:09PM -0500, J. Bruce Fields wrote:
>>> On Wed, Nov 21, 2007 at 12:30:23AM +0100, Jarek Poplawski wrote:
>>>> I do
On Wed, Nov 21, 2007 at 08:52:17AM +0100, Jarek Poplawski wrote:
...
> Of course, you are right, and I probably miss something, but to be
> sure we think about the same thing let's look at some example: so, I
> open a page with current Linus' tree, go to something titled:
> /
On Tue, Nov 20, 2007 at 10:20:09PM -0500, J. Bruce Fields wrote:
> On Wed, Nov 21, 2007 at 12:30:23AM +0100, Jarek Poplawski wrote:
> > I don't know git, but it seems, at least if done for web only, this
> > shouldn't be so 'heavy'. It could be a 'simple
Petr Baudis wrote, On 11/20/2007 10:59 PM:
> Hi,
>
> On Tue, Nov 20, 2007 at 03:20:42PM +0100, Jarek Poplawski wrote:
>> I see gitweb is much more usable (faster) than a few months ago, but
>> there is one thing a bit problematic: in the history of patches I'm
>>
Hi,
I see gitweb is much more usable (faster) than a few months ago, but
there is one thing a bit problematic: in the history of patches I'm
very often interested in which kernel version of Linus' tree the patch
appeared for the first time. If it's not some big problem, and maybe
somebody else fin
Bill Fink wrote, On 11/16/2007 08:26 PM:
...
> Regarding the Target IP, RFC 826 says:
>
> "The target protocol address is necessary in the request form
> of the packet so that a machine can determine whether or not
> to enter the sender information in a table or to send a reply.
Jon Nelson wrote, On 11/15/2007 09:21 PM:
...
> NOTE: to avoid list noise, I can make a bug out of this on
> bugzilla.kernel.org and we can proceed from there if that is
> preferred.
Why avoid list noise? These lists are made just for this. But, since
this case needs a lot of space for your confi
On 13-11-2007 19:57, Jon Nelson wrote:
> I'm not sure if this is the right place,
Me too. Looks more like acpi or pci problem. Did you try to experiment
with something like: pci=noacpi or acpi=off boot parameters? Probably
some point to your .config and dmesg should be useful too, so taking
it to
On 13-11-2007 12:15, Andrew Morton wrote:
...
> Zero responses from developers
...
> No response from developers
...
> Andreas did some work, seemed to lose interest.
...
> Rafael poked Thomas a week ago, to no effect. Thomas has been travelling.
Looks like very reproducible!
Maybe you should add
Tomasz Kłoczko wrote, On 11/12/2007 06:57 PM:
> Some data showed by top command looks like completly trashed.
> Fragment from top output:
>
> Mem: 2075784k total, 2053352k used,22432k free,19260k buffers
> Swap: 2096472k total, 136k used, 2096336k free, 1335080k cached
>
>
On 04-11-2007 01:04, Theodore Tso wrote:
> On Sat, Nov 03, 2007 at 12:14:15PM +, Remigiusz Modrzejewski wrote:
>> We've all seen the last flame war about Linux stealing BSD code. Due to
>> Theo's bad wording whole discussion rolled around the question about
>> legality of this, a big waste of t
On Mon, Oct 22, 2007 at 10:02:59PM +0400, Oleg Nesterov wrote:
...
> If this work doesn't rearm itself - yes. (otherwise, the same ->func
> can run twice _at the same time_)
>
> But again, in this case wait_on_work() after try_to_grab_pending() == 1
> doesn't block, so we can just do
>
> if
On Mon, Oct 22, 2007 at 10:02:59PM +0400, Oleg Nesterov wrote:
> On 10/22, Jarek Poplawski wrote:
...
> > OK, I know I'm dumber and dumber everyday,
>
> You are not alone. I have the same feeling about myself!
Feeling is not the same, only true knowledge counts!
>
&g
On Fri, Oct 19, 2007 at 09:50:14AM +0200, Jarek Poplawski wrote:
> On Thu, Oct 18, 2007 at 07:48:19PM +0400, Oleg Nesterov wrote:
> > On 10/18, Jarek Poplawski wrote:
> > >
> > > +/**
> > > + * flush_work_sync - block until a w
On Fri, Oct 19, 2007 at 12:38:29PM +0100, Maciej W. Rozycki wrote:
> On Thu, 18 Oct 2007, Maciej W. Rozycki wrote:
>
> > > 1) phy_change() checks PHY_HALTED flag without lock; I think it's
> > > racy: eg. if it's done during phy_stop() it can check just before
> > > the flag is set and reenable in
On Thu, Oct 18, 2007 at 12:30:35PM +0100, Maciej W. Rozycki wrote:
> On Wed, 17 Oct 2007, Jarek Poplawski wrote:
...
> > 2) phy_change() doesn't reenable irq line after it sees returns
> > with errors; IMHO it should at least write some warning, but maybe
> > try some
On Fri, Oct 19, 2007 at 09:50:14AM +0200, Jarek Poplawski wrote:
...
> sched_work_sync() with rtnl_lock(). It's only less probable to lockup
> with this than with flush_schedule_work().
...But, not much less...
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, Oct 18, 2007 at 07:48:19PM +0400, Oleg Nesterov wrote:
> On 10/18, Jarek Poplawski wrote:
> >
> > +/**
> > + * flush_work_sync - block until a work_struct's callback has terminated
> ^^^
&
1 - 100 of 414 matches
Mail list logo
