> if HIGH_RES_TIMERS is disabled then that is what happens. But frankly,
disabled? I would expect it (= more wakeups) when hrtimers are enabled.
> most futex waits are without timeouts - if an application cares about
> micro-effects like that then you are much better off not using a
>
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > even if this means more work for you (i'm sorry about that!) i'm
> > quite sure we should take Sebastien's hrtimers based implementation
> > of futex_wait(), and use the nanosleep method to restart it. There's
> > no point in further tweaking the
Hi,
On Monday, 12 March 2007 09:14, Pavel Machek wrote:
> Hi!
>
> > > > I personally think we should do the opposite, add
> > > > kthread_should_stop_check_freeze()
> > > > or something. kthread_should_stop() is like signal_pending(), we can use
> > > > it under spin_lock (and it is probably
On Sunday, 11 March 2007 21:45, Soeren Sonnenburg wrote:
> (sorry if I am CC'ing the wrong people, seemed for me this is related to
> rc-2 regression 5/6)
>
> After a very long compile sessions (is there something like git bisect
> to speed this up?) to find the config options that break s2ram
On Monday 12 March 2007, Radoslaw Szkodzinski wrote:
>On 3/11/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
>> On Sunday 11 March 2007, Mike Galbraith wrote:
>>
>> Just to comment, I've been running one of the patches between 20-ck1
>> and this latest one, which is building as I type, but I also run
At Sat, 10 Mar 2007 00:31:33 -0500,
Dave Jones wrote:
>
> =
> [ INFO: possible recursive locking detected ]
> 2.6.20-1.2962.fc7 #1
> -
> rosegardenseque/5229 is trying to acquire lock:
> (>list_mutex){},
On Mon, 2007-03-12 at 12:02 +0100, Ingo Molnar wrote:
> > Well I did convert futex_wait to an absolute timeout based version in
> > the subsequent incremental patch. I think that is OK?
>
> it still has the rounding artifacts: using timer_list there is no way to
> do a precise long sleep based
On Mon, Mar 12, 2007 at 12:02:04PM +0100, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > > i dont think we should try to do this. We should not and cannot do
> > > anything about all of the artifacts that comes with the use of
> > > relative timeouts and
Hi
I am trying to boot 2.6.20.2 on a Gigabyte GA-M57SLI-S4 with f7 stock bios.
I get the message:
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ... failed.
...trying
On Sun, 11 Mar 2007, David Miller wrote:
> I'm going to make the radical declaration that it be perhaps often
> better to always initialize page table chunks to all zeros on
> allocation.
That is the case if most of the page is going to be used soon. If we have
sparse access patterns then not
* Mike Galbraith <[EMAIL PROTECTED]> wrote:
> The test scenario was one any desktop user might do with every
> expectation responsiveness of the interactive application remain
> intact. I understand the concepts here Con, and I'm not knocking your
> scheduler. I find it to be a step forward
Hi folks.
I have a simple program, that analyzes ethernet packets. Counting
traffic on from/to basis, and dumping that informatio nevery minute.
Everything is cleared - in terms of memory, valgrind doesn't complain
a bit.
But once every 2-3 days the router on which the software is running,
> 1. I think these ports should be made dummy instead of returning
> -ENOENT on prereset(). -ENOENT from prereset() was a hack to keep
> ata_piix's behavior unchanged while converting it to new EH. If no
> one objcts, I'll convert similar usages to use dummy ports after new
> init model and drop
At Sat, 10 Mar 2007 19:05:13 +,
Ralf Baechle wrote:
>
> CC [M] sound/pci/hda/hda_intel.o
> sound/pci/hda/hda_intel.c:1508: error: position_fix_list causes a section
> type conflict
>
> Gcc like its __devinitdata readable not const, it seems. An alternative
> fix would be to remove the
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 12, 2007 at 12:00:20PM +0100, Thomas Gleixner wrote:
> > On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
> > > Ingo Molnar <[EMAIL PROTECTED]> writes:
> > > >
> > > > the only correct approach is the use of hrtimers, and a patch exists
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > i dont think we should try to do this. We should not and cannot do
> > anything about all of the artifacts that comes with the use of
> > relative timeouts and schedule_timeout().
> >
> > basically, using jiffies here (which schedule_timeout()
Soeren Sonnenburg wrote:
> Elsewise I still see the
>
> ATA: abnormal status 0x80 on port 0x000140df
> ATA: abnormal status 0x80 on port 0x000140df
> ata1.00: configured for UDMA/33
> ata3.01: revalidation failed (errno=-2)
> ata3: failed to recover some devices, retrying in 5 secs
> ATA:
On Mon, Mar 12, 2007 at 12:00:20PM +0100, Thomas Gleixner wrote:
> On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
> > Ingo Molnar <[EMAIL PROTECTED]> writes:
> > >
> > > the only correct approach is the use of hrtimers, and a patch exists for
> > > that - see below. This has been included
On Mon, 2007-03-12 at 21:27 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 20:38, Mike Galbraith wrote:
> >
> Now I think you're getting carried away because of your expectations from the
> previous scheduler and its woefully unfair treatment towards interactive
> tasks. Look at how you're
On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
> >
> > the only correct approach is the use of hrtimers, and a patch exists for
> > that - see below. This has been included in -rt for quite some time.
>
> But isn't that bad for power management?
On Mon, 2007-03-12 at 10:13 +0100, Ingo Molnar wrote:
> Subject: [patch] futex: PI state locking fix
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> testing of -rt by IBM uncovered a locking bug in wake_futex_pi(): the PI
> state needs to be locked before we access it.
>
> this patch has been
Davide,
On Sun, 2007-03-11 at 16:04 -0700, Davide Libenzi wrote:
> +static int timerfd_setup(struct timerfd_ctx *ctx, int clockid, int tmrtype,
> + const struct itimerspec *ktmr)
> +{
> + enum hrtimer_mode htmode;
> + ktime_t texp, tintv;
> +
> + if (clockid !=
Hi Amit,
On Thu, Mar 08, 2007 at 11:14:01PM -0800, Amit Choudhary wrote:
> Description: Check the return value of kmalloc() in function
> videocodec_build_table(), in file drivers/media/video/videocodec.c.
No need for `Description:'. This line is automatically put in the logs
as a patch
Hi,
On 3/12/07, Valerie Henson <[EMAIL PROTECTED]> wrote:
--- tulip-2.6-mm-linux.orig/drivers/net/tulip/tulip_core.c
+++ tulip-2.6-mm-linux/drivers/net/tulip/tulip_core.c
@@ -17,11 +17,11 @@
#define DRV_NAME "tulip"
#ifdef CONFIG_TULIP_NAPI
-#define DRV_VERSION"1.1.14-NAPI" /* Keep
Hello Vincent,
> patched kernel. Now it looks more like 5 seconds faster!
> Wow.. nice work CK!
>
> 2.6.18.8 vanilla kernel:
> [ 48.185716] libata version 2.00 loaded.
> [ 49.838513] scsi0 : sata_nv
>
>
> 2.6.18.8-rsdl-0.30:
> [ 43.144312] libata version 2.00 loaded.
> [ 45.820504]
Sorry for last post, i have been sent to the wrong mailing list.
I was looking for ltsp list and did not notice that OpenSuscriber
had changed the group. Thousand excuses!
--
This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com
Hello.
I am new to the LTSP local devices, even though my TS works fine. The
need to use local storage (read USB keys) prompted me to install the
local storage part. I am running a 32bit debian etch and followed the
ltsp4.2:
http://wiki.ltsp.org/twiki/bin/view/Ltsp/LTSP-42-LocalDev-DebianEtch
and
On Monday 12 March 2007 20:38, Xavier Bestel wrote:
> On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> > On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > > Hmm. So... anything that's client/server is going to suffer horribly
> > > unless niced tasks are niced all the way down to
Troy Benjegerdes <[EMAIL PROTECTED]> writes:
> I am attempting to make a 2.6.20 kernel boot on a Cray XD1 node with a
> Mellanox InfiniBand card installed, however both the ancient supplied
> cray 2.6.5 suse derivative, and a 2.6.20 kernel I just booted fail
> on APIC initialization.
>
> Below
On Monday 12 March 2007 20:38, Mike Galbraith wrote:
> On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> > On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > > On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
> > > > I'll save you the trouble. I just checked myself and indeed the
Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> the only correct approach is the use of hrtimers, and a patch exists for
> that - see below. This has been included in -rt for quite some time.
But isn't that bad for power management? You'll likely get more
idle wakeups, won't you?
-Andi
-
To
On Monday 12 March 2007, Gene Heskett wrote:
>On Monday 12 March 2007, Con Kolivas wrote:
>>Hi Gene.
>>
>>On Monday 12 March 2007 16:38, Gene Heskett wrote:
>>> I hate to say it Con, but this one seems to have broken the
>>> amanda-tar symbiosis.
>>>
>>> I haven't tried a plain 21-rc3, so the
On Tue, 6 Mar 2007, Jeff Garzik wrote:
> Jay Vosburgh (3):
> bonding: Improve IGMP join processing
ip_mc_rejoin_group: Kill warning about unused variable `in_dev' when
CONFIG_IP_MULTICAST is not set.
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
diff --git a/net/ipv4/igmp.c
From: Guido Classen <[EMAIL PROTECTED]>
This small patch fixes two issues with the Lite-On 82c168 PNIC adapters.
I've tested it with two cards in different machines both chip rev 17
The first is the wrong register address CSR6 for writing the MII register
which instead is 0xB8 (this may get a
Hello,
> > That sounds a quite expensive solution ;)
>
> You should be able to just move the drive attached at ata1 to ata2.
> Please report whether that works.
I'll try to find an unused disk... As I said, these ports are part of
Asus EZRaid solution, and i'd prefer this piece of code not to
On 3/11/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
My current understanding of Paul Menage's container patch is that it is
a useful improvement for some of the metered classes - those that could
make good use of a file system like hierarchy for their interface.
It probably doesn't benefit all
On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > Hmm. So... anything that's client/server is going to suffer horribly
> > unless niced tasks are niced all the way down to 19?
>
> Fortunately most client server models dont usually
Rev tulip version... things have changed since 2002!
Signed-off-by: Valerie Henson <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
---
drivers/net/tulip/tulip_core.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
---
This patch set includes a fix for Lite-on from Guido Classen, some
minor debugging/typo fixes, and a long-need rev to the version (the
last time this was done was 2002!).
-VAL
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Only print out debugging info for tulip_stop_rxtx if debug is on.
Many cards (including at least two of my own) fail to stop properly
during initialization according to this test with no apparent ill
effects. Worse, it tends to spam logs when the driver doesn't work.
Signed-off-by: Val Henson
Fix an annoying typo - SytemError -> SystemError
Signed-off-by: Valerie Henson <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
---
drivers/net/tulip/interrupt.c |4 ++--
drivers/net/tulip/tulip.h |2 +-
drivers/net/tulip/winbond-840.c |2 +-
3 files changed, 4
doesn't look so good for me, mainly becaus of the
additional per page data and per page processing
on 4GB memory, with 100 guests, 50% shared for each
guest, this basically means ~1mio pages, 500k shared
and 1500k x sizeof(page_container) entries, which
roughly boils down to ~25MB of wasted
On Sun, Mar 11, 2007 at 05:25:46PM -0700, Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> > Hmm, it probably needs a EXPORT_SYMBOL. The previous change only
> > fixed the in kernel build.
> >
> > Does it work with this patch?
> >
> > -Andi
> >
> > Export _proxy_pda for gcc 4.2
> >
>
> Gak.
Hi!
> > > > Quoting Linus Torvalds <[EMAIL PROTECTED]>:
> > > >
> > > > Ok, it does indeed solve the problem for me.
> > >
> > > Not yet for me unfortunately, although this seems to help.
> > > Is this the patch I should have applied?
> > > http://lkml.org/lkml/2007/3/5/445
> > >
> > > With
On Mon, Mar 12, 2007 at 10:28:13AM +1100, Rusty Russell wrote:
> BUILD_BUG_ON_ZERO is named perfectly wrong, and BUILD_BUG_ON_RETURN_ZERO
> is too long. Flip three bits, and the name is much more suitable.
Ok for me.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe
On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
> > > I'll save you the trouble. I just checked myself and indeed the load is
> > > only 1. What this means is that although there
Allow me to annotate your nice summary. A lot of this is elaborating on
what you are saying; and I think where we disagree, the differences are
not important.
Paul Jackson wrote:
> We have actors, known as threads, tasks or processes, which use things,
> which are instances of such classes of
On Thursday 08 March 2007 10:19, Chris Friesen wrote:
> I still haven't seen any replies, so I'm resending with a few more
> people directly in the TO list.
>
> The timeslice of a SCHED_RR process currently varies with nice level the
> same way that it does for SCHED_OTHER. I've included a small
On Mon, 2007-03-12 at 08:23 +, Jan Beulich wrote:
> I have to admit that I don't see the point here - I can't seem to make
> any sense of the OR... Jan
At least one other person thought that:
#define BUILD_BUG_ON_ZERO(e) BUILD_BUG_ON((e) == 0)
OTOH, BUILD_BUG_OR_ZERO says what
On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
> > I'll save you the trouble. I just checked myself and indeed the load is
> > only 1. What this means is that although there are 2 tasks running, only
> > one is running at any time
Krzysztof Halasa wrote:
> "Tosoni" <[EMAIL PROTECTED]> writes:
> > As far as I know in the old times this was the *standard*
> way to use a modem
> > (per CCITT V24), and even nowadays many modems can handle
> this method for
> > transmit, to stay compatible with the standard.
>
> I think it
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Mon, Mar 12, 2007 at 11:55:30AM +0300, Dmitriy Monakhov wrote:
>> Nick Piggin <[EMAIL PROTECTED]> writes:
>>
>> > On Mon, Mar 12, 2007 at 10:58:10AM +0300, Dmitriy Monakhov wrote:
>
>> >> @@ -2240,6 +2241,29 @@ ssize_t generic_file_aio_write(struct
On Mon, Mar 12, 2007 at 10:10:06AM +0100, Ingo Molnar wrote:
>
> * Roland McGrath <[EMAIL PROTECTED]> wrote:
>
> > I agree it should restart. But I don't think this is quite right in
> > the timeout case. It will increase the total maximum real time spent
> > arbitrarily by the amount of
Subject: [patch] futex: PI state locking fix
From: Ingo Molnar <[EMAIL PROTECTED]>
testing of -rt by IBM uncovered a locking bug in wake_futex_pi(): the PI
state needs to be locked before we access it.
this patch has been tested in -rt. Must-have for v2.6.21.
Signed-off-by: Ingo Molnar <[EMAIL
On 3/12/07, Francis Moreau <[EMAIL PROTECTED]> wrote:
I updated my kernel to 2.6.19-1.2911.6.5.fc6 and unfortunately it
doesn't help, I still have these errors.
I attached the new dmesg, if anybody can give me some hints that would be great.
oops sent it too fast...
with the dmesg this time.
* Roland McGrath <[EMAIL PROTECTED]> wrote:
> I agree it should restart. But I don't think this is quite right in
> the timeout case. It will increase the total maximum real time spent
> arbitrarily by the amount of time elapsed in signal handlers. Other
> restartable, timed calls have to
On Mon, Mar 12, 2007 at 11:55:30AM +0300, Dmitriy Monakhov wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
>
> > On Mon, Mar 12, 2007 at 10:58:10AM +0300, Dmitriy Monakhov wrote:
> >> @@ -2240,6 +2241,29 @@ ssize_t generic_file_aio_write(struct kiocb *iocb,
> >> const struct iovec *iov,
> >>
Eric,
> And misses every resource sharing opportunity in sight.
that was my point too.
> Except for
> filtering the which pages are eligible for reclaim an RSS limit should
> not need to change the existing reclaim logic, and with things like the
> memory zones we have had that kind of
Hi,
On 3/9/07, Jim van Wel <[EMAIL PROTECTED]> wrote:
Hi there,
Please try first a newer kernel of FC6.
2.6.19-1.2911.6.5.fc6
That's 2.6.19.7.
That's the newest one.
I updated my kernel to 2.6.19-1.2911.6.5.fc6 and unfortunately it
doesn't help, I still have these errors.
I attached the
Jiri Kosina napsal(a):
On Sun, 11 Mar 2007, Jiri Slaby wrote:
- /* make sure the unused bits in the last byte are zeros */
- if (count > 0 && size > 0)
- data[(offset+count*size-1)/8] = 0;
-
No, this doesn't help -- -rc3-mm2 minus this behaves exactly the same.
Hi!
> Make swsusp use memory bitmaps instead of page flags for marking 'nosave' and
> free pages. This allows us to 'recycle' two page flags that can be used for
> other
> purposes. Also, the memory needed to store the bitmaps is allocated when
> necessary (ie. before the suspend) and freed
On Sun 2007-03-11 11:34:53, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Remove the two page flags that were previously used by swsusp and are no
> longer
> needed.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
ACK.
On Sun, Mar 11, 2007 at 10:26:52PM +0100, Giuliano Pochini wrote:
>
>
> Since 2.6.20 /sys/devices/system/cpu/cpuX/online isn't there anymore. The
> directories exist, though. I also tested linux-2.6.21rc3. I had a look at the
> archives and I found nothing about the removal of that file, which
Hi!
> Replace direct invocations of SetPageNosave(), SetPageNosaveFree() etc. with
> calls to inline functions that can be changed in subsequent patches without
> modifying the code calling them.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
ACK.
>>> Maybe you have some ideas how we can decide on this?
>> We need to work out what the requirements are before we can
>> settle on an implementation.
>
> Linux-VServer (and probably OpenVZ):
>
> - shared mappings of 'shared' files (binaries
>and libraries) to allow for reduced memory
>
2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
-d 1 /dev/hda):
hda: dma_timer_expiry: dma status == 0x20
hda: DMA timeout retry
hda: timeout waiting for DMA
hda: status error: status=0x58 {
DriveReady
SeekComplete
On Mon, 2007-03-12 at 19:29 +1100, Con Kolivas wrote:
> I'll save you the trouble. I just checked myself and indeed the load is only
> 1. What this means is that although there are 2 tasks running, only one is
> running at any time making a total load of 1. So, if we add two other tasks
> that
Nick Piggin <[EMAIL PROTECTED]> writes:
> On Mon, Mar 12, 2007 at 10:58:10AM +0300, Dmitriy Monakhov wrote:
>> I realy don't want to be annoying by sending this patcheset over and over
>> again, i just want the issue to be solved. If anyone think this solution
>> is realy cappy, please comment
Am Samstag, 10. März 2007 20:19 schrieb Alan Stern:
> On Fri, 9 Mar 2007, Oliver Neukum wrote:
>
> > Am Freitag, 9. März 2007 21:08 schrieb Alan Stern:
> > > After some more thought, I basically agree with what Oliver wrote
> > > originally. sysfs_dirent is indeed the logical place to store the
On 09-03-2007 14:40, Thomas Graf wrote:
> * Kok, Auke <[EMAIL PROTECTED]> 2007-02-08 16:09
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 455d589..42b635c 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -1477,6 +1477,49 @@ gso:
>> skb->tc_verd =
On Mon, 2007-03-12 at 18:48 +1100, Con Kolivas wrote:
>
> Just a couple of questions;
>
> The X/Gforce case; do they alternate cpu between them? By that I mean when
> they're the only thing running does the cpu load summate to 1 or does it
> summate to 2?
They're each on their own cpu
On Mar 12 2007 08:23, Jan Beulich wrote:
>
>I have to admit that I don't see the point here - I can't seem to make any
>sense of the OR... Jan
BUILD_BUG_OR_ZERO will either (a) result in a build bug or (b) the number
zero, suitable for arithmetic.
Rusty Russell <[EMAIL PROTECTED]> 12.03.07
On Mon, Mar 12, 2007 at 10:57:53AM +0300, Dmitriy Monakhov wrote:
> I realy don't want to be annoying by sending this patcheset over and over
> again. If anyone think this patch is realy cappy, please comment what
> exectly is bad. Thank you.
Doesn't seem like a bad idea.
>
> Changes:
> -
[snip]
>> We need to decide whether we want to do per-container memory
>> limitation via these data structures, or whether we do it via
>> a physical scan of some software zone, possibly based on Mel's
>> patches.
> why not do simple page accounting (as done currently
> in
On Monday 12 March 2007 18:48, Con Kolivas wrote:
> On Monday 12 March 2007 18:22, Mike Galbraith wrote:
> > On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
> > > * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > > > > Full patch for 2.6.21-rc3-mm2:
> > > > >
On Mon, Mar 12, 2007 at 10:57:53AM +0300, Dmitriy Monakhov wrote:
> +/*
> + * Performs necessary checks before doing a write
> + *
> + * Adjust number of segments and amount of bytes to write.
> + * Returns appropriate error code that caller should return or
> + * zero in case that write should be
I have to admit that I don't see the point here - I can't seem to make any
sense of the OR... Jan
>>> Rusty Russell <[EMAIL PROTECTED]> 12.03.07 00:28 >>>
BUILD_BUG_ON_ZERO is named perfectly wrong, and BUILD_BUG_ON_RETURN_ZERO
is too long. Flip three bits, and the name is much more suitable.
->prereset() returns -ENOENT to tell libata that the port is empty and
reset sequencing should be stopped. This is not an error condition.
Update ata_eh_reset() such that it sets device classes to ATA_DEV_NONE
and return success in on -ENOENT. This makes spurious error message
go away.
On Mon, Mar 12, 2007 at 10:58:10AM +0300, Dmitriy Monakhov wrote:
> I realy don't want to be annoying by sending this patcheset over and over
> again, i just want the issue to be solved. If anyone think this solution
> is realy cappy, please comment what exectly is bad. Thank you.
If you don't
Hi!
> > > I personally think we should do the opposite, add
> > > kthread_should_stop_check_freeze()
> > > or something. kthread_should_stop() is like signal_pending(), we can use
> > > it under spin_lock (and it is probably used this way by some out-of-tree
> > > driver). The new helper is
Paul Rolland wrote:
>> I keep forgetting about this. I'll ask SIMG how to deal with
>> this. For
>> the time being, connecting a device to the PMP port should remove the
>> timeouts.
>
> That sounds a quite expensive solution ;)
You should be able to just move the drive attached at ata1 to
Hello,
> It involves a long timeout, so it's bothersome. This is caused by
> Silicon Image 4726/3726 storage processor (SATA Port Multiplier with
> extra features) attached to one of the ICH ports.
Yes, I think this is the part Asus is using for it's EZ-Raid feature
on this motherboard, and
I realy don't want to be annoying by sending this patcheset over and over
again. If anyone think this patch is realy cappy, please comment what
exectly is bad. Thank you.
Changes:
- patch was split in two patches.
- comments added. I think now it is clearly describe things.
- make
I realy don't want to be annoying by sending this patcheset over and over
again, i just want the issue to be solved. If anyone think this solution
is realy cappy, please comment what exectly is bad. Thank you.
Changes:
- patch was split in two patches.
- comments added. I think now it is
Hello,
> Ok, so that's just a message irritation, not actually bothersome
> otherwise?
It is somewhat painful, because delays involved are quite long, and
it is not possible to explain the machine to "ignore" the port, and
skip to the next one...
> > The second problem is a Jmicron363
Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> On 3/8/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
>> Absolutely not. We dont want to slow down kernel 'just in case a fool might
>> want to do crazy things'
>
> Actually, I think it would make the kernel (negligibly) faster to bump
> f_pos before
On Monday 12 March 2007 18:22, Mike Galbraith wrote:
> On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
> > * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> > > > Full patch for 2.6.21-rc3-mm2:
> > > > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-
> > > >0.29.patch
> > >
On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> > > Full patch for 2.6.21-rc3-mm2:
> > > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29.patch
> >
> > I'm seeing a cpu distribution problem running this on my P4
On Sun, Mar 11, 2007 at 09:20:02AM +0100, Ingo Molnar wrote:
>
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
> > Unfortunately, these tend to crash the box when you pass wrong
> > options, and I do not see easy way to test "can user see whats on
> > display" automatically.
>
> you could perhaps
Dmitriy Monakhov <[EMAIL PROTECTED]> writes:
> - ext3_dx_find_entry() exit with out setting proper error pointer
> - do_split() exit with out setting proper error pointer
>it is realy painful because many callers contain folowing code:
>de = do_split(handle,dir, , frame, , );
>
On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
Full patch for 2.6.21-rc3-mm2:
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.29.patch
I'm seeing a cpu distribution problem running this on my P4 box.
With
On Monday 12 March 2007 18:22, Mike Galbraith wrote:
On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
Full patch for 2.6.21-rc3-mm2:
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-
0.29.patch
I'm seeing a cpu
Michael K. Edwards [EMAIL PROTECTED] wrote:
On 3/8/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Absolutely not. We dont want to slow down kernel 'just in case a fool might
want to do crazy things'
Actually, I think it would make the kernel (negligibly) faster to bump
f_pos before the
Hi!
I personally think we should do the opposite, add
kthread_should_stop_check_freeze()
or something. kthread_should_stop() is like signal_pending(), we can use
it under spin_lock (and it is probably used this way by some out-of-tree
driver). The new helper is obviously
I have to admit that I don't see the point here - I can't seem to make any
sense of the OR... Jan
Rusty Russell [EMAIL PROTECTED] 12.03.07 00:28
BUILD_BUG_ON_ZERO is named perfectly wrong, and BUILD_BUG_ON_RETURN_ZERO
is too long. Flip three bits, and the name is much more suitable.
[snip]
We need to decide whether we want to do per-container memory
limitation via these data structures, or whether we do it via
a physical scan of some software zone, possibly based on Mel's
patches.
why not do simple page accounting (as done currently
in Linux) and use that for the
On Monday 12 March 2007 18:48, Con Kolivas wrote:
On Monday 12 March 2007 18:22, Mike Galbraith wrote:
On Sun, 2007-03-11 at 13:10 +0100, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
Full patch for 2.6.21-rc3-mm2:
On Mar 12 2007 08:23, Jan Beulich wrote:
I have to admit that I don't see the point here - I can't seem to make any
sense of the OR... Jan
BUILD_BUG_OR_ZERO will either (a) result in a build bug or (b) the number
zero, suitable for arithmetic.
Rusty Russell [EMAIL PROTECTED] 12.03.07 00:28
On Mon, 2007-03-12 at 18:48 +1100, Con Kolivas wrote:
Just a couple of questions;
The X/Gforce case; do they alternate cpu between them? By that I mean when
they're the only thing running does the cpu load summate to 1 or does it
summate to 2?
They're each on their own cpu (sibling).
Am Samstag, 10. März 2007 20:19 schrieb Alan Stern:
On Fri, 9 Mar 2007, Oliver Neukum wrote:
Am Freitag, 9. März 2007 21:08 schrieb Alan Stern:
After some more thought, I basically agree with what Oliver wrote
originally. sysfs_dirent is indeed the logical place to store the kref
401 - 500 of 980 matches
Mail list logo
