This is basically a set of bug fixes with a few minor cleanups thrown
in. There are also a few bsg fixes we're taking through this tree
because SCSI is the current sole consumer. The reason for the huge size
is the lindent of the advansys driver along with a few cleanups.
The patch is available
Commit 22ad42033b7d2b3d7928fba9f89d1c7f8a3c9581 did not completely fix all
the possible NULL dereferences. Besides hci_uart_close(), we also need to
make sure that hdev is valid before calling hci_{unregister,free}_dev().
Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
---
Adam,
Yep. That did it
Thank You Very Much for your Super Quick Fix..
---( Nick )---
On Sun, Jul 29, 2007 at 10:04:44AM -0400, Adam Kropelin wrote:
> From: "Nick Pasich" <[EMAIL PROTECTED]>
> >Here's the dmesg output ..
> >
> >[...]
> >Jul 29 05:20:07 NICK2 kernel:
El Sat, 28 Jul 2007 18:00:39 -0700, Bill Huey (hui) <[EMAIL PROTECTED]>
escribió:
> The scheduler could have and still can undertake good solid transformation,
> but getting folks to listen is another story which is why Con quit. CFS
> basically locks him and his ideas out, not just from a
On Sunday 29 July 2007 14:47:57 you wrote:
> Alistair John Strachan wrote:
> > On Sunday 29 July 2007 12:34:28 you wrote:
> > [snip]
> >
> >>> Doesn't help, I still get the same crashes. I tried 2.6.22 again and
> >>> it's rock solid by comparison.
> >>
> >> Do you mean, kvm-33 on top of 2.6.22,
On 07/29/2007 03:12 PM, Alan Cox wrote:
What are the tradeoffs here? What wants small chunks? Also, as far as
I'm aware Linux does not do things like up the granularity when it
notices it's swapping in heavily? That sounds sort of promising...
Small chunks means you get better efficiency of
From: "Nick Pasich" <[EMAIL PROTECTED]>
Here's the dmesg output ..
[...]
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c: LCR -
write to send_cmd_write_uart_register register 0x03
Jul 29 05:20:07 NICK2 kernel: drivers/usb/serial/io_edgeport.c:
SendCmdWriteUartReg - Not
On 07/29/2007 01:41 PM, [EMAIL PROTECTED] wrote:
And now you do it again :-) There is no conclusion -- just the
inescapable observation that swap-prefetch was (or may have been)
masking the problem of GNU locate being a program that noone in their
right mind should be using.
isn't your
Hello,
iMac G3 series.
$ make mrproper && make allmodconfig && make
results in this:
CC arch/powerpc/kernel/lparmap.s
AS arch/powerpc/kernel/head_64.o
lparmap.c: Assembler messages:
lparmap.c:84: Error: file number 1 already allocated
make[1]: ***
Hi
On 7/29/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> Hi Parag,
>
> On Friday 27 July 2007 10:43, Parag Warudkar wrote:
> > Ignore my previous whitespace damaged patch. This one should be good.
> >
> > tsdev.c warns about scheduled removal each time tsdev_open is called -
> > So even for a
> James should already have that patch queued for inclusion since last
> week.
OK thanks, I missed seeing it go by.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Borislav Petkov wrote:
Right, this was too easy to be true. I now did:
qemu -hda /dev/hda -snapshot
and booted from the hd using the installed grub and the same kernel and it
_didn't_ boot showing again "no setup signature found... "
Okay, so it's an algorithmic problem. This is quite
Alistair John Strachan wrote:
On Sunday 29 July 2007 12:34:28 you wrote:
[snip]
Doesn't help, I still get the same crashes. I tried 2.6.22 again and it's
rock solid by comparison.
Do you mean, kvm-33 on top of 2.6.22, or the kvm modules from 2.6.22?
Please describe your configuration
On Sunday 29 July 2007 12:34:28 you wrote:
[snip]
> > Doesn't help, I still get the same crashes. I tried 2.6.22 again and it's
> > rock solid by comparison.
>
> Do you mean, kvm-33 on top of 2.6.22, or the kvm modules from 2.6.22?
> Please describe your configuration *exactly*.
I'm using the
> Contrived thing and all, but what it does do is show exactly how bad seeking
> all over swap-space is. If you push it out before hitting enter, the time it
> takes easily grows past 10 minutes (with my 768M) versus sub-second (!) when
> it's all in to start with.
Think in "operations/second"
* Adrian Bunk ([EMAIL PROTECTED]) wrote:
> Considering the state of the arm26 port, I do hereby suggest to remove
> it from the Linx kernel since it's far from a usable state and doesn't
> seem to come back into a usable state.
>
> If anyone wants to work on getting this port back into a usable
Neil Horman wrote:
[...]
> + delimit = strrchr(helper_argv[0], '/');
> + if (delimit)
Trailing space.
> + delimit++;
> + else
> + delimit = helper_argv[0];
> + if (!strcmp(delimit, current->comm))
> +
Neil Horman wrote:
[...]
> + /* core limit size */
> + case 'c':
> + rc = snprintf(out_ptr, out_end - out_ptr,
> + "%lu",
> current->signal->rlim[RLIMIT_CORE].rlim_cur);
Trailing space.
Neil Horman wrote:
[...]
> + * Don't bother to check the RLIMIT_CORE value if core_pattern points
> + * to a pipe. Since we're not writing directly to the filesystem
> + * RLIMIT_CORE doesn't really apply, as no actual core file will be
> + * created unless the pipe reader
> Files are different. File content tends to be grouped
> in large related chunks, both logically in the file and
> on disk. Generally there is a lot more file data on a
> system than what fits in memory.
Binary paging patterns don't always look like that unfortunately although
I suspect we
Neil Horman wrote:
> On Sun, Jul 29, 2007 at 06:40:43PM +0800, Eugene Teo wrote:
>> Neil Horman wrote:
[...]
>> You may want to improve your patches with style-related changes, including
>> removing trailing spaces, using tabs instead of spaces, and defining pointers
>> like char *ptr instead of
Andi wrote:
> GNU sort uses a merge sort with temporary files on disk. Not sure
> how much it keeps in memory during that, but it's probably less
> than 150MB.
If I'm reading the source code for GNU sort correctly, then the
following snippet of shell code displays how much memory it uses
for its
Adam,
Here's the dmesg output ..
---( Nick )---
***
***
Jul 29 05:19:28 NICK2 kernel: drivers/usb/serial/io_edgeport.c: get_string -
On Sun, July 29, 2007 05:50, Dmitry Torokhov wrote:
> Hi Indan,
>
> On Friday 27 July 2007 19:28, Indan Zupancic wrote:
>> Hi,
>>
>> Not real feedback, just some nitpicks.
>>
>> On Tue, July 24, 2007 06:45, Dmitry Torokhov wrote:
>> > +static int input_defuzz_abs_event(int value, int old_val, int
On Sun, Jul 29, 2007 at 01:10:12PM +0100, Christoph Hellwig wrote:
> On Sun, Jul 29, 2007 at 01:50:40PM +0200, Adrian Bunk wrote:
> > Considering the state of the arm26 port, I do hereby suggest to remove
> > it from the Linx kernel since it's far from a usable state and doesn't
> > seem to come
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Introduce CONFIG_SUSPEND representing the ability to enter system sleep states,
such as the ACPI S3 state, and allow the user to choose SUSPEND and HIBERNATION
independently of each other.
Make HOTPLUG_CPU be selected automatically if SUSPEND or
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION to avoid confusion
(among other things, with CONFIG_SUSPEND introduced in the next patch).
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
arch/i386/Kconfig.debug |4
On Saturday, 28 July 2007 20:31, Linus Torvalds wrote:
>
> On Sat, 28 Jul 2007, Rafael J. Wysocki wrote:
> >
> > OK, I'll prepare a patch to introduce CONFIG_SUSPEND, but that will require
> > quite a bit of (compilation) testing on different architectures.
>
> Sure. I'm not too worried, the
On Sun, Jul 29, 2007 at 11:34:18AM +0200, Martin Pitt wrote:
> Hi Neil,
>
> Neil Horman [2007-07-28 13:21 -0400]:
> > Jeremy asked that I make a patch next week to address split_argv's
> > requirement
> > that the argc parameter be non-NULL. I'll be fixing that next week, and
> > what I
> >
On Sun, Jul 29, 2007 at 02:23:10PM +0530, Aneesh Kumar K.V wrote:
>
>
> Neil Horman wrote:
> >On Sat, Jul 28, 2007 at 06:17:25PM +0200, Martin Pitt wrote:
> >>Hi Neil,
> >>
> >>Neil Horman [2007-07-28 9:46 -0400]:
> I just want to mention a potential problem with this: If you first
>
On Sun, July 29, 2007 05:38, Dmitry Torokhov wrote:
> Hi Indan,
>
> On Friday 27 July 2007 18:25, Indan Zupancic wrote:
>> Sorry for the babbling, just wanted to say that I've tested these
>> patches and that they seem to fix real problems.
>>
>
> Thank you for testing the patches.
Unfortunately
On Sun, Jul 29, 2007 at 06:40:43PM +0800, Eugene Teo wrote:
> Neil Horman wrote:
> > Ok, here we go
> >
> > As promised, I'm reposting the core_pattern enhancements I've done over the
> > past
> > few days. These three patches replace and conintue the work contained in
> > the
> > following
On Sun, Jul 29, 2007 at 01:50:40PM +0200, Adrian Bunk wrote:
> Considering the state of the arm26 port, I do hereby suggest to remove
> it from the Linx kernel since it's far from a usable state and doesn't
> seem to come back into a usable state.
>
> If anyone wants to work on getting this
Lee Schermerhorn (via Andrew) wrote:
> +static inline void node_set_state(int node, enum node_states state)
> +{
> + __node_set(node, _states[state]);
> +}
> +
> +static inline void node_clear_state(int node, enum node_states state)
> +{
> + __node_clear(node, _states[state]);
> +}
Lee -
Considering the state of the arm26 port, I do hereby suggest to remove
it from the Linx kernel since it's far from a usable state and doesn't
seem to come back into a usable state.
If anyone wants to work on getting this port back into a usable state in
the forseeable future he should speak up
On Sun, 29 Jul 2007, Rene Herman wrote:
On 07/28/2007 11:00 PM, [EMAIL PROTECTED] wrote:
> many -mm users use it anyway? He himself said he's not convinced of
> usefulness having not seen it help for him (and notice that most
> developers are also users), turned it off due to it annoying
Robert Hancock wrote:
It's not entirely clear to me whether the kernel is doing any retries or
not. It likely should be, but somebody more familiar with the block
layer would likely have to answer whether it will be or not..
Would be pretty great to get answer of someone, who knows if the
Alistair John Strachan wrote:
On Sunday 29 July 2007 09:16:43 Avi Kivity wrote:
Alistair John Strachan wrote:
Hi,
I'm getting periodic oopses running KVM-33 on 2.6.23-rc1. Here is a
digital photo of the oops. Alarmingly, a lot of the time it triple faults
the machine and I don't get a
On Sunday 29 July 2007 09:16:43 Avi Kivity wrote:
> Alistair John Strachan wrote:
> > Hi,
> >
> > I'm getting periodic oopses running KVM-33 on 2.6.23-rc1. Here is a
> > digital photo of the oops. Alarmingly, a lot of the time it triple faults
> > the machine and I don't get a chance to grab it.
Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg:
> > I
> > actually also think that the communication between Ingo and Con could
> > have been better especially when Ingo decided to write CFS while Con
> > was still working hard on SD.
>
> You realize that Ingo posted his code for anyone to look
On Sat, Jul 28 2007, Roland Dreier wrote:
> The current stub definitions of bsg_register_queue() and
> bsg_unregister_queue() as macros leads to
>
> drivers/scsi/scsi_sysfs.c: In function 'scsi_sysfs_add_sdev':
> drivers/scsi/scsi_sysfs.c:718: warning: unused variable 'rq'
>
> because
Neil Horman wrote:
> Ok, here we go
>
> As promised, I'm reposting the core_pattern enhancements I've done over the
> past
> few days. These three patches replace and conintue the work contained in the
> following patches, and can replace them:
>
On Sun, Jul 29, 2007 at 10:24:02AM +0100, Xudong Guan wrote:
> Borislav Petkov wrote:
> > On Thu, Jul 26, 2007 at 09:31:54PM -0700, H. Peter Anvin wrote:
> > > If we can't reproduce the problem in simulation, that itself will tell
> > > us something very important. If we *can* reproduce it in
If a cpu is spinning in the kernel but still responding to interrupts,
pressing sysrq-y will show you where it's spinning.
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c
index 39cc318..1dda709 100644
--- a/drivers/char/sysrq.c
+++
> I
> actually also think that the communication between Ingo and Con could
> have been better especially when Ingo decided to write CFS while Con was
> still working hard on SD.
You realize that Ingo posted his code for anyone to look at/comment at
about 48 hours after he started to work on
On 07/28/2007 11:00 PM, [EMAIL PROTECTED] wrote:
many -mm users use it anyway? He himself said he's not convinced of
usefulness having not seen it help for him (and notice that most
developers are also users), turned it off due to it annoying him at
some point and hasn't seen a serious
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
> Take the race between the time_pps_setparams() syscall and a concurrent
> pps_event() from an interrupt for instance. From sys_time_pps_setparams,
> the parameters for an existing source are not modified / set atomically,
> which
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
>
> Ok, I've looked through (most of) the RFC and code now, and am only
> commenting on a design-level for now. Anyway, I didn't like the way
> you've significantly drifted from the RFC in several ways:
Please, read documentation
On Sat, Jul 28, 2007 at 05:11:17AM +0530, Satyam Sharma wrote:
>
> Take the race between the time_pps_setparams() syscall and a concurrent
> pps_event() from an interrupt for instance. From sys_time_pps_setparams,
> the parameters for an existing source are not modified / set atomically,
> which
On Sunday, 29 July 2007 08:53, Vojtech Pavlik wrote:
> On Mon, Jul 16, 2007 at 12:38:11AM +0200, Rafael J. Wysocki wrote:
>
> > > Or the user unplugs their flash drive after hibernation rather than
> > > before.
> > >
> > > Two things which I think would be nice to consider are:
> > >1)
Am Samstag 28 Juli 2007 schrieb Linus Torvalds:
> On Sat, 28 Jul 2007, Diego Calleja wrote:
> > El Sat, 28 Jul 2007 11:05:25 -0700 (PDT), Linus Torvalds
<[EMAIL PROTECTED]> escribió:
> > > So "modal" things are good for fixing behaviour in the short run.
> > > But they are a total disaster in the
Hi Neil,
Neil Horman [2007-07-28 13:21 -0400]:
> Jeremy asked that I make a patch next week to address split_argv's requirement
> that the argc parameter be non-NULL. I'll be fixing that next week, and what
> I
> can do is further enhance it such that it ignores spaces in quoted strings,
>
Linus Torvalds wrote:
The fact is, I've _always_ considered the desktop to be the most important
part. And I suspect that that actually is true for most kernel developers,
because quite frankly, that's what 99% of them ends up using. If a kernel
developer uses Windows for his day-to-day work,
On Sun, 29 Jul 2007, Willy Tarreau wrote:
> On Sun, Jul 29, 2007 at 11:26:00AM +0300, Ilpo Järvinen wrote:
> > On Sun, 29 Jul 2007, Willy Tarreau wrote:
> >
> > > On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
> > > > CLIENT = Linux 2.6.20.1-smp [Customer build]
> > > > SERVER
Borislav Petkov wrote:
> On Thu, Jul 26, 2007 at 09:31:54PM -0700, H. Peter Anvin wrote:
> > If we can't reproduce the problem in simulation, that itself will tell
> > us something very important. If we *can* reproduce it in simulation, it
> > will be vastly easier to debug.
>
> [EMAIL
On Sat, Jul 28, 2007 at 02:17:24AM +0530, Satyam Sharma wrote:
>
> I only glanced through the code, so could be wrong, but I noticed that
> the only global / shared data you have in there is a global "pps_source"
> array of pps_s structs. That's accessed / modified from the various
> syscalls
Am Samstag 28 Juli 2007 schrieb Linus Torvalds:
> On Sat, 28 Jul 2007, Jan Engelhardt wrote:
> > You cannot please everybody in the scheduler question, that is clear,
> > then why not offer dedicated scheduling alternatives (plugsched comes
> > to mind) and let them choose what pleases them most,
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Sun, 29 Jul 2007 11:26:00 +0300 (EEST)
> Is this reproducable? Can you somehow verify that the packets CLIENT is
> sending are indeed received by the SERVER...?
One possibility is drops due to checksum errors on the receiver, this
tends to pop up
On Sun, Jul 29, 2007 at 11:26:00AM +0300, Ilpo Järvinen wrote:
> On Sun, 29 Jul 2007, Willy Tarreau wrote:
>
> > On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
> > > CLIENT = Linux 2.6.20.1-smp [Customer build]
> > > SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS
Neil Horman wrote:
On Sat, Jul 28, 2007 at 06:17:25PM +0200, Martin Pitt wrote:
Hi Neil,
Neil Horman [2007-07-28 9:46 -0400]:
I just want to mention a potential problem with this: If you first
expand the macros (from pattern to corename) and then split
corename into an argv, then this
On Thu, Jul 26, 2007 at 09:31:54PM -0700, H. Peter Anvin wrote:
[added to cc: Chuck Ebbert]
> Borislav Petkov wrote:
> >>
> >> The absolute best would be if we could replicate this in simulation
> >> (Bochs or Qemu); this would make it very simple to debug. Would you be
> >> willing to try to do
Am Sonntag 29 Juli 2007 schrieb Jesper Juhl:
> On 29/07/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > On 7/29/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> > > Hello,
> > >
> > > This patch makes sure we don't dereference a NULL pointer in
> > >
Am Samstag 28 Juli 2007 schrieb Linus Torvalds:
> People are suggesting that you'd have a separate "desktop kernel".
> That's insane. It also shows total ignorance of maintainership, and
> reality. And I bet most of the people there haven't tested _either_
> scheduler, they just like making
On Jul 29 2007 08:45, Willy Tarreau wrote:
>On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
>> CLIENT = Linux 2.6.20.1-smp [Customer build]
>> SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4
>> (Nahant Update 5)]
>>
>> The problems start around time index
On Sun, 29 Jul 2007, Willy Tarreau wrote:
> On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
> > CLIENT = Linux 2.6.20.1-smp [Customer build]
> > SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4
> > (Nahant Update 5)]
> >
> > The problems start around time
On Sat, 28 Jul 2007 14:13:06 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Yoichi Yuasa wrote:
> > Hi,
> >
> > I got the following error on MIPS Cobalt.
> > MIPS Cobalt has the 0x1000 offset between resource and bus region.
> >
> > PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED]
Alistair John Strachan wrote:
Hi,
I'm getting periodic oopses running KVM-33 on 2.6.23-rc1. Here is a digital
photo of the oops. Alarmingly, a lot of the time it triple faults the machine
and I don't get a chance to grab it. This time I was lucky, though.
On 07/28/2007 01:21 PM, Alan Cox wrote:
It is. Prefetched pages can be dropped on the floor without additional
I/O.
Which is essentially free for most cases. In addition your disk access
may well have been in idle time (and should be for this sort of stuff)
Yes. The swap-prefetch patch
Related to my other bug report today, calling posix_fadvise (which uses
fadvise64) with the POSIX_FADV_NOREUSE flag does nothing. The pages are
not dropped behind.
I also tried call fadvise with POSIX_FADV_SEQUENTIAL first.
This is expected as the POSIX_FADV_NOREUSE is a no-op in the recent
Linux VM use-once mechanisms don't seem to work. Simple scenario like
streaming a file much greater than physical RAM size should be
identified to avoid trashing the page cache with useless data.
I know the VM cannot predict the future or assume anything about the
user's intent. But this
On Wed, 2007-25-07 at 17:09 +1000, Nick Piggin wrote:
> Eric St-Laurent wrote:
> > I test this on my main system, so patches with basic testing and
> > reasonable stability are preferred. I just want to avoid data corruption
> > bugs. FYI, I used to run the -rt tree most of the time.
>
> OK here
Hi,
My Dell Latitude D520 just dies with this BUG:
--8<--8<--8<--8<--
Jul 29 09:30:00 localhost kernel: [ cut here ]
Jul 29 09:30:00 localhost kernel: kernel BUG at mm/slab.c:2980!
Jul 29 09:30:00 localhost kernel: invalid opcode:
Heiko Carstens wrote:
This will not do the right thing. Semantics of smp_call_function_single()
changed recently. It now is supposed to call func() locally with irqs
disabled if cpu == smp_processor_id(). See i386/x86_64 and powerpc.
Unfortunately ia64 hasn't been changed yet, so it will behave
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Fri, 27 Jul 2007 16:41:22 +0200
> > Signed-off-by: Al Viro <[EMAIL PROTECTED]>
>
> Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Fri, 27 Jul 2007 16:41:26 +0200
> > Since nobody uses it after we convert it to host-endian,
> > no need to do that at all. At that point l2cap is endian-clean.
> >
> > Signed-off-by: Al Viro <[EMAIL PROTECTED]>
>
> Signed-off-by: Marcel Holtmann
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Fri, 27 Jul 2007 16:41:21 +0200
> > no code changes, just documenting existing types
> >
> > Signed-off-by: Al Viro <[EMAIL PROTECTED]>
>
> Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Fri, 27 Jul 2007 16:41:18 +0200
> > We loop through psm values, calling __l2cap_get_sock_by_addr(psm, ...)
> > until we get NULL; then we set ->psm of our socket to htobs(psm).
> > IOW, we find unused psm value and put it into our socket. So far,
On Fri, 27 Jul 2007 16:46:23 +0200 Maik Hampel <[EMAIL PROTECTED]> wrote:
> In case of read errors raid10d tries to print a nice error message,
> unfortunately using data from an already put bio.
>
> Signed-off-by: Maik Hampel <[EMAIL PROTECTED]>
>
> diff --git a/drivers/md/raid10.c
On Mon, Jul 16, 2007 at 12:38:11AM +0200, Rafael J. Wysocki wrote:
> > Or the user unplugs their flash drive after hibernation rather than before.
> >
> > Two things which I think would be nice to consider are:
> >1) Encryption - I'd actually prefer if my luks device did not
> >
Hi,
[CCing netdev as it's where people competent on the subject are]
On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
> CLIENT = Linux 2.6.20.1-smp [Customer build]
> SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4
> (Nahant Update 5)]
>
> The problems
Ingo Molnar wrote:
> Subject: sched: make cpu_clock() not use the rq clock
>
This subject doesn't make much sense to me. All this patch does is get
the rq's current time under irq_disable rather than spinlock, right?
J
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> it is enough to disable
CLIENT = Linux 2.6.20.1-smp [Customer build]
SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4 (Nahant
Update 5)]
The problems start around time index 09:21:39.860302 when the CLIENT issues a
TCP packet with SACK option set (seemingly for a data segment which has already
Ingo Molnar wrote:
Subject: sched: make cpu_clock() not use the rq clock
This subject doesn't make much sense to me. All this patch does is get
the rq's current time under irq_disable rather than spinlock, right?
J
From: Ingo Molnar [EMAIL PROTECTED]
it is enough to disable
CLIENT = Linux 2.6.20.1-smp [Customer build]
SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4 (Nahant
Update 5)]
The problems start around time index 09:21:39.860302 when the CLIENT issues a
TCP packet with SACK option set (seemingly for a data segment which has already
Hi,
[CCing netdev as it's where people competent on the subject are]
On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
CLIENT = Linux 2.6.20.1-smp [Customer build]
SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4
(Nahant Update 5)]
The problems start
On Mon, Jul 16, 2007 at 12:38:11AM +0200, Rafael J. Wysocki wrote:
Or the user unplugs their flash drive after hibernation rather than before.
Two things which I think would be nice to consider are:
1) Encryption - I'd actually prefer if my luks device did not
remember the
On Fri, 27 Jul 2007 16:46:23 +0200 Maik Hampel [EMAIL PROTECTED] wrote:
In case of read errors raid10d tries to print a nice error message,
unfortunately using data from an already put bio.
Signed-off-by: Maik Hampel [EMAIL PROTECTED]
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
From: Marcel Holtmann [EMAIL PROTECTED]
Date: Fri, 27 Jul 2007 16:41:18 +0200
We loop through psm values, calling __l2cap_get_sock_by_addr(psm, ...)
until we get NULL; then we set -psm of our socket to htobs(psm).
IOW, we find unused psm value and put it into our socket. So far, so
good,
From: Marcel Holtmann [EMAIL PROTECTED]
Date: Fri, 27 Jul 2007 16:41:21 +0200
no code changes, just documenting existing types
Signed-off-by: Al Viro [EMAIL PROTECTED]
Signed-off-by: Marcel Holtmann [EMAIL PROTECTED]
Applied.
-
To unsubscribe from this list: send the line unsubscribe
From: Marcel Holtmann [EMAIL PROTECTED]
Date: Fri, 27 Jul 2007 16:41:22 +0200
Signed-off-by: Al Viro [EMAIL PROTECTED]
Signed-off-by: Marcel Holtmann [EMAIL PROTECTED]
Applied.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
From: Marcel Holtmann [EMAIL PROTECTED]
Date: Fri, 27 Jul 2007 16:41:26 +0200
Since nobody uses it after we convert it to host-endian,
no need to do that at all. At that point l2cap is endian-clean.
Signed-off-by: Al Viro [EMAIL PROTECTED]
Signed-off-by: Marcel Holtmann [EMAIL
Heiko Carstens wrote:
This will not do the right thing. Semantics of smp_call_function_single()
changed recently. It now is supposed to call func() locally with irqs
disabled if cpu == smp_processor_id(). See i386/x86_64 and powerpc.
Unfortunately ia64 hasn't been changed yet, so it will behave
Hi,
My Dell Latitude D520 just dies with this BUG:
--8--8--8--8--
Jul 29 09:30:00 localhost kernel: [ cut here ]
Jul 29 09:30:00 localhost kernel: kernel BUG at mm/slab.c:2980!
Jul 29 09:30:00 localhost kernel: invalid opcode:
On Wed, 2007-25-07 at 17:09 +1000, Nick Piggin wrote:
Eric St-Laurent wrote:
I test this on my main system, so patches with basic testing and
reasonable stability are preferred. I just want to avoid data corruption
bugs. FYI, I used to run the -rt tree most of the time.
OK here is one
Linux VM use-once mechanisms don't seem to work. Simple scenario like
streaming a file much greater than physical RAM size should be
identified to avoid trashing the page cache with useless data.
I know the VM cannot predict the future or assume anything about the
user's intent. But this
Related to my other bug report today, calling posix_fadvise (which uses
fadvise64) with the POSIX_FADV_NOREUSE flag does nothing. The pages are
not dropped behind.
I also tried call fadvise with POSIX_FADV_SEQUENTIAL first.
This is expected as the POSIX_FADV_NOREUSE is a no-op in the recent
On 07/28/2007 01:21 PM, Alan Cox wrote:
It is. Prefetched pages can be dropped on the floor without additional
I/O.
Which is essentially free for most cases. In addition your disk access
may well have been in idle time (and should be for this sort of stuff)
Yes. The swap-prefetch patch
On Sat, 28 Jul 2007 14:13:06 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
Yoichi Yuasa wrote:
Hi,
I got the following error on MIPS Cobalt.
MIPS Cobalt has the 0x1000 offset between resource and bus region.
PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device
Alistair John Strachan wrote:
Hi,
I'm getting periodic oopses running KVM-33 on 2.6.23-rc1. Here is a digital
photo of the oops. Alarmingly, a lot of the time it triple faults the machine
and I don't get a chance to grab it. This time I was lucky, though.
On Sun, 29 Jul 2007, Willy Tarreau wrote:
On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
CLIENT = Linux 2.6.20.1-smp [Customer build]
SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4
(Nahant Update 5)]
The problems start around time index
301 - 400 of 764 matches
Mail list logo
