On Mon, May 14, 2007 at 08:00:11PM +, Pavel Machek wrote:
> Hi!
>
> > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> >
> > > Following are two patches which have been sitting for some time in -mm.
> >
> > Where "some time" == "nearly six months".
> >
> > We need help considering, reviewing
From: Satyam Sharma <[EMAIL PROTECTED]>
Date: Thu, 17 May 2007 11:13:36 +0530 (IST)
> [PATCH] bluetooth: fix locking in hci_sock_dev_event()
>
> We presently use lock_sock() to acquire a lock on a socket in
> hci_sock_dev_event(), but this goes BUG because lock_sock()
> can sleep and we're
[PATCH] bluetooth: fix locking in hci_sock_dev_event()
We presently use lock_sock() to acquire a lock on a socket in
hci_sock_dev_event(), but this goes BUG because lock_sock()
can sleep and we're already holding a read-write spinlock at
that point. So, we must use the non-sleeping BH version,
Yeah, seems you've locked it down, :D. I've written 600GB of data now,
and anything is still fine.
Will let it run overnight, and fill the whole 11T. I'll post the result
tomorrow
Thanks a lot though.
Jeff
> -Original Message-
> From: Neil Brown [mailto:[EMAIL PROTECTED]
> Sent:
On Thursday May 17, [EMAIL PROTECTED] wrote:
>
> Uhm, I just noticed something.
> 'chunk' is unsigned long, and when it gets shifted up, we might lose
> bits. That could still happen with the 4*2.75T arrangement, but is
> much more likely in the 2*5.5T arrangement.
Actually, it cannot be a
This patch allows the removal of unused dentry entries in a partial
populated slab page. Very limited (yet) in what it can do for reclaim
but this catches bad cases in which we have a long list of partial
slabs with a few entries in each of them. We can free up the slabs
that have only unused
We use the parameter formerly used by the destructor to pass an optional
pointer to a kmem_cache_ops structure to kmem_cache_create.
kmem_cache_ops is created as empty. Later patches populate kmem_cache_ops.
Create a KMEM_CACHE_OPS macro that allows the specification of a the
kmem_cache_ops.
Targeted reclaim allows to target a single slab for reclaim. This is done by
calling
kmem_cache_vacate(page);
It will return 1 on success, 0 if the operation failed.
The vacate functionality is also used for slab shrinking. During the shrink
operation SLUB will generate a list sorted by the
Initial support for Slab defragmentation and targeted reclaim. The
functionality here is minimal. We establish a slab API to allow removal
or moving of objects between slabs.
The only user provided here is a dentry cache reclaim capability. This is
limited to the removal of unused dentries for
On Wed, May 16, 2007 at 02:58:22PM -0500, [EMAIL PROTECTED] wrote:
> greg
>
> CONFIG_SYSFS_DEPRECATED=Y
>
> check that we have
> rwxrwxrwx 1 root root 15 May 16 13:43 scanner-usbdev2.12 ->
> bus/usb/002/012
>
> in /dev directory after usb-scanner connection for kernel-2.6.20
> we
> What is the nature of the corruption? Is it data in a file
> that is wrong when you read it back, or does the filesystem
> metadata get corrupted?
The corruption is in fs metadata, jfs is completely destroied, after
Umount, fsck does not recogonize it as jfs anymore. Xfs gives kernel
From: sk b <[EMAIL PROTECTED]>
Date: Wed, 16 May 2007 22:56:22 -0600
> 3:if (!access_ok(VERIFY_READ,stp,sizeof(struct st)))
> 4:return;
> 5:if (!access_ok(VERIFY_WRITE,stp->u,sizeof(int)))
> 6:return;
This code would not exist in the kernel, the
On Wed, May 16, 2007 at 10:56:22PM -0600, sk b wrote:
>
> Hello,
>
> I'm wondering whether there is an exploitable TOCTTOU race condition in the
> way user pointers are handled in the kernel. Consider the following code:
>
> 1: struct st { int *u; };
> 2: void syscall(struct st * stp) {
> 3:
On Wednesday May 16, [EMAIL PROTECTED] wrote:
> On Thu, 17 May 2007, Neil Brown wrote:
>
> > On Thursday May 17, [EMAIL PROTECTED] wrote:
> >>
> >>> The only difference of any significance between the working
> >>> and non-working configurations is that in the non-working,
> >>> the component
On 5/17/07, Bharata B Rao <[EMAIL PROTECTED]> wrote:
From: Bharata B Rao <[EMAIL PROTECTED]>
namespace_sem is a rwsem. It is acquired as read sem at only one place(used
^^
Actually, this ...
by /proc/mounts, /proc//mounts
On Thu, May 17, 2007 at 10:20:41AM +0530, Bharata B Rao wrote:
> From: Bharata B Rao <[EMAIL PROTECTED]>
>
> namespace_sem is a rwsem. It is acquired as read sem at only one place(used
> by /proc/mounts, /proc//mounts and /proc//mountstats). In all other
> cases it is acquired as a write sem. So,
Hello,
I'm wondering whether there is an exploitable TOCTTOU race condition in the way
user pointers are handled in the kernel. Consider the following code:
1: struct st { int *u; };
2: void syscall(struct st * stp) {
3:if (!access_ok(VERIFY_READ,stp,sizeof(struct st)))
4:
On Thu, 17 May 2007, Neil Brown wrote:
On Thursday May 17, [EMAIL PROTECTED] wrote:
The only difference of any significance between the working
and non-working configurations is that in the non-working,
the component devices are larger than 2Gig, and hence have
sector offsets greater than 32
Linus Torvalds wrote:
>
> On Wed, 16 May 2007, H. Peter Anvin wrote:
>> It gets turned on by the code in arch/i386/kernel/cpu. It's just that
>> the new code that Andi added runs during setup, i.e. in real mode, so
>> *way* earlier than that.
>
> Ahh. Do we really need it that early?
The
From: Bharata B Rao <[EMAIL PROTECTED]>
namespace_sem is a rwsem. It is acquired as read sem at only one place(used
by /proc/mounts, /proc//mounts and /proc//mountstats). In all other
cases it is acquired as a write sem. So, as there is not more than one reader
for this sem, this can be a generic
Dave Jones wrote:
> Bob, does this patch make it boot again for you?
>
> Dave
>
> Some AMD K6's advertise machine check capability, but don't actually
> have an Intel compatible implementation. It also doesn't actually work,
> so don't advertise it as being present.
>
> Signed-off-by:
On Thursday May 17, [EMAIL PROTECTED] wrote:
> I tried the patch, same problem show up, but no bug_on report
>
> Is there any other things I can do?
>
What is the nature of the corruption? Is it data in a file that is
wrong when you read it back, or does the filesystem metadata get
corrupted?
On 5/16/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
This issue has actually been resolved, see the patch at:
http://lkml.org/lkml/2007/5/16/149
Ah, excellent. Thanks!
Ray
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Frank Sorenson wrote:
> After adding *lots* of early_printks, I see that it hangs in
> hpet_is_known(hdp) called from hpet_alloc(), so something in the hpet
> code is still buggy. Adding nohpet to the kernel command line allows it
> to boot
Martin Christoph wrote:
[1] Summary:
If i have some GREP_OPTIONS set (like -C1 or other) i get several errors
while trying to do "make modules".
[2] Full description:
With some GREP_OPTIONS set "make modules" drops several errors like that:
[EMAIL PROTECTED] /usr/src/linux # GREP_OPTIONS="-C1"
On 5/16/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Andy Whitcroft wrote:
> Getting this on both x86 and x86_64 boxes, they are the older boxen so
> likely older compilers:
Please give the gcc version number.
> CC arch/x86_64/boot/memory.o
> arch/i386/boot/memory.c: In function
On 5/17/07, Ray Lee <[EMAIL PROTECTED]> wrote:
Apologies for taking so long to get back to you -- I've been on the
road for the last week and have finally got to a point where I could
test the patch.
On 5/6/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> (Dropped Pavel, Rafael and linux-pm from
[1] Summary:
If i have some GREP_OPTIONS set (like -C1 or other) i get several errors
while trying to do "make modules".
[2] Full description:
With some GREP_OPTIONS set "make modules" drops several errors like that:
[EMAIL PROTECTED] /usr/src/linux # GREP_OPTIONS="-C1" make modules
CHK
On Wed, 16 May 2007, Rob Landley wrote:
> > But you need to detect if the kernel has proper SCSI device shutdown
> > support, because if it does not, you have to do a cache flush and spindown
> > on shutdown(8) if you can...
>
> Or (and this is just a thought), you could upgrade your kernel so it
On Wed, 16 May 2007, H. Peter Anvin wrote:
>
> It gets turned on by the code in arch/i386/kernel/cpu. It's just that
> the new code that Andi added runs during setup, i.e. in real mode, so
> *way* earlier than that.
Ahh. Do we really need it that early?
Now, it's easy enough to just turn off
> We already discussed this, this is not so important, but how about
>
> void recalc_sigpending_and_wake(struct task_struct *t)
> {
> int was_pending = signal_pending(t);
>
> if (recalc_sigpending_tsk(t) && !was_pending)
>
I tried the patch, same problem show up, but no bug_on report
Is there any other things I can do?
Jeff
> Yes, I meant 2T, and yes, the components are always over 2T.
> So I'm at a complete loss. The raid0 code follows the same
> paths and does the same things and uses 64bit arithmetic
Linus Torvalds wrote:
>
> On Thu, 17 May 2007, Christian wrote:
>
>> Linus Torvalds wrote:
>>> Can you check? The Nehemian (C3-2) should be model 9 or greater.
>> Yes, it's a Nehemiah
>
> Ok. If so, we should blacklist both MCYRIXIII and MVIAC3_2, I suspect.
>
>> lola:~ # cat /proc/cpuinfo
>>
On Wed, 16 May 2007, George Nychis wrote:
> I was wondering if any progress was made on the docking station support for
> new thinkpads,
> like the x60s ultradock. I'm looking for support for the CD/DVD burner on
> it. I tried
> enabling the most recent dock support in the kernel and still
On Wednesday 16 May 2007 8:58 pm, Henrique de Moraes Holschuh wrote:
> On Wed, 16 May 2007, Rob Landley wrote:
> > Ok, so the change is to get shutdown to _stop_ doing something stupid
> > (spinning down the disk without first flushing the cache), and the correct
> > thing for shutdown to do is
On Mon, 14 May 2007, Peter Zijlstra wrote:
>
> In the interest of creating a reserve based allocator; we need to make the
> slab
> allocator (*sigh*, all three) fair with respect to GFP flags.
>
> That is, we need to protect memory from being used by easier gfp flags than it
> was allocated
On Thursday May 17, [EMAIL PROTECTED] wrote:
>
> > The only difference of any significance between the working
> > and non-working configurations is that in the non-working,
> > the component devices are larger than 2Gig, and hence have
> > sector offsets greater than 32 bits.
>
> Do u mean
On Wed, May 16, 2007 at 11:31:16PM +0200, Jesper Juhl wrote:
> Hi,
>
> The Coverity checker found a memory leak in xfs_inactive().
> So, the code allocates a transaction, but in the case where 'truncate' is
> !=0 and xfs_itruncate_start(ip, XFS_ITRUNC_DEFINITE, 0); happens to return
> an
On system with huge amount of physical memory.
VFS cache and memory memmap may eat all available system memory under
4G, then system may fail to allocated swiotlb bounce buffer.
There was a fix in arch/x86_64/mm/numa.c, but that fix does not cover
sparsemem model.
This patch add fix to
On Thu, 17 May 2007, Christian wrote:
> Linus Torvalds wrote:
> > Can you check? The Nehemian (C3-2) should be model 9 or greater.
>
> Yes, it's a Nehemiah
Ok. If so, we should blacklist both MCYRIXIII and MVIAC3_2, I suspect.
> lola:~ # cat /proc/cpuinfo
> flags : fpu vme de pse
[PATCH]x86_64: early_print kernel console should send CRLF not LFCR
in
commit d358788f3f30113e49882187d794832905e42592
Author: Russell King <[EMAIL PROTECTED]>
Date: Mon Mar 20 20:00:09 2006 +
Glen Turner reported that writing LFCR rather than the more
On Wednesday 16 May 2007, Corey Minyard wrote:
>Russell King wrote:
>> On Sun, May 06, 2007 at 12:58:25PM -0400, Gene Heskett wrote:
>>> [long message snipped]
>>>
>>> Thanks for your patience Corey.
>>
>> So, in one sentence or preferably one word, did Corey's patch cause a
>> regression?
>
> The only difference of any significance between the working
> and non-working configurations is that in the non-working,
> the component devices are larger than 2Gig, and hence have
> sector offsets greater than 32 bits.
Do u mean 2T here?, but in both configuartion, the component devices
On Wednesday May 16, [EMAIL PROTECTED] wrote:
>
> Here is what I am doing to test:
>
> fdisk /dev/sda1 and /dev/sb1 to type fd/Linux raid auto
> mdadm --create /dev/md1 -c 128 -l 5 -n 3 /dev/sda1 /dev/sdb1 missing
> mke2fs -j -b 4096 -R stride=32 /dev/md1
> e2fsck -f /dev/md1
>
On Wed, May 16, 2007 at 09:41:33AM -0700, Andrew Morton wrote:
> On Wed, 16 May 2007 18:24:44 +0200 Michal Piotrowski <[EMAIL PROTECTED]>
> wrote:
>
> > Andrew Morton napisaÅ(a):
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc1/2.6.22-rc1-mm1/
> > >
> >
> >
Hey all,
I was wondering if any progress was made on the docking station support for new
thinkpads,
like the x60s ultradock. I'm looking for support for the CD/DVD burner on it.
I tried
enabling the most recent dock support in the kernel and still nothing.
(2.6.22-rc1)
Thanks!
George
-
To
Fix following kmalloc(0) message. patch is agaisnt 2.6.22-rc1-mm1.
==
BUG: at mm/slab.c:792 __find_general_cachep()
Call Trace:
[] show_stack+0x40/0xa0
sp=e14042227b00 bsp=e14042220f90
[] dump_stack+0x30/0x60
On Wed, 2007-05-16 at 21:47 -0400, Daniel Drake wrote:
> Hi,
>
> Did anything happen to the patch titled "radeonfb: add support for newer
> cards"?
> http://lwn.net/Articles/215965/
>
> Jimmy at http://bugs.gentoo.org/174063 has extended upon this with some
> further fixes based on code the in
H. Peter Anvin wrote:
>
> Andi added code to verify that we can actually execute on the processor
> before protected mode (so we can still get a message out through the
> BIOS.) That code presumably doesn't know of the MSR that needs to be
> touched.
>
> That code is in assembly in Andi's
This is a note to let you know that we have just queued up the patch titled
Subject: JFS: Fix race waking up jfsIO kernel thread
to the 2.6.21-stable tree. Its filename is
jfs-fix-race-waking-up-jfsio-kernel-thread.patch
A git repo of this tree can be found at
Hi,
Did anything happen to the patch titled "radeonfb: add support for newer
cards"?
http://lwn.net/Articles/215965/
Jimmy at http://bugs.gentoo.org/174063 has extended upon this with some
further fixes based on code the in X11 driver. The patches are on the
bug report.
Ben, where can the
Dave Jones wrote:
> The C3s all have cx8, but it needs to be enabled in an MSR first.
> (See arch/i386/kernel/cpu/centaur.c , search for CX8)
>
> Did we add code that uses cmpxchg8b before identify_cpu() gets run ?
> I've not been paying attention to .22rc (busy trying to beat .21 into shape
>
Linus Torvalds wrote:
> Can you check? The Nehemian (C3-2) should be model 9 or greater.
Yes, it's a Nehemiah
lola:~ # cat /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 9
model name : VIA Nehemiah
stepping: 8
cpu MHz :
Dave Jones wrote:
>
> The C3s all have cx8, but it needs to be enabled in an MSR first.
> (See arch/i386/kernel/cpu/centaur.c , search for CX8)
>
> Did we add code that uses cmpxchg8b before identify_cpu() gets run ?
> I've not been paying attention to .22rc (busy trying to beat .21 into shape
On Wednesday 16 May 2007 6:49 pm, Robert Schwebel wrote:
> Jeff,
>
> Any idea how this could happen? I'm trying to build 2.6.21 for ARCH=um, and
the
> linker stage explodes here:
2.6.21.1 built for me:
tar xvjf linux-2.6.21.1.tar.bz2 &&
cd linux-2.6.21.1 &&
cat > mini.conf << EOF
I have noticed that a few items in the i386 boot document have become a
bit incoherent and/or dated over the years. Attached is an attempt at
rewriting a few of the sections; the main things is a field-by-field
description for the setup header.
I would appreciate comments as to if this makes it
On Thu, 17 May 2007, Christian wrote:
>
> my small VIA C3_2 box does not boot with 2.6.22-rc1.
> It even does not uncompress the kernel.
>
> The configuration as M386 M486 works. But M586 + MVIAC3_2
> does not work.
Ahh, from the EPIA HOWTO:
13.2. Is the C3 Pentium compatible?
Daniel Drake wrote:
Joshua Hoblitt wrote:
I don't think this is quiet right either as Ed Sweetman has reported
that this issue doesn't occur on single socket/multi-core systems.
Where did he write that? In an off-list mail, Ed seemed to agree with
my patch.
Daniel
What i didn't agree
On Wed, 16 May 2007 15:57:39 -0400
Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
>
> [PATCH 2.6.21-rc1-mm1] add check_highest_zone to build_zonelists_in_zone_order
>
> We missed this in the "change zone order" series. We need to record
> the highest populated zone, just as build_zonelists_node()
On Wed, 16 May 2007, Rob Landley wrote:
> Ok, so the change is to get shutdown to _stop_ doing something stupid
> (spinning down the disk without first flushing the cache), and the correct
> thing for shutdown to do is keep its' mitts off the thing and let the kernel
> power down the darn
On Wed, May 16, 2007 at 06:44:53PM +0200, Tejun Heo wrote:
> + /* FIXME: GoVault needs 2s but we can't afford that without
> + * parallel probing. 800ms is enough for iVDR disk
> + * HHD424020F7SV00. Increase to 2secs when parallel probing
> + * is in place.
> + */
> +
On Wed, 2007-05-16 at 10:37 -0500, Anton Blanchard wrote:
> Hi Hugh,
>
> > It's interesting that compat_core_sys_select() shows this kmalloc(0)
> > failure but core_sys_select() does not. That's because core_sys_select()
> > avoids kmalloc by using a buffer on the stack for small allocations
Joshua Hoblitt wrote:
I don't think this is quiet right either as Ed Sweetman has reported
that this issue doesn't occur on single socket/multi-core systems.
Where did he write that? In an off-list mail, Ed seemed to agree with my
patch.
Daniel
-
To unsubscribe from this list: send the
On Wed, May 16, 2007 at 06:44:53PM +0200, Tejun Heo wrote:
> This patch is against the current libata-dev#upstream +
> pata_scc-fix-build-failure[1].
>
> [1] http://article.gmane.org/gmane.linux.kernel/528405
>
> Paul, please verify this fixes your problem. You can skip the
> pata_scc patch,
> I do not know why sk_buff->head would be null, or
> would be set in a racy kind of way, or why the rt patches
> would cause this. But the evidence implicates that.
Would it be possible that a locking bug in spidernet would cause it
under some circumstances to get a stale skb pointer ?
Ben.
On Wednesday May 16, [EMAIL PROTECTED] wrote:
> Here is the information of the created raid0. Hope it is enough.
Thanks.
Everything looks fine here.
The only difference of any significance between the working and
non-working configurations is that in the non-working, the component
devices are
H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>
>> H. Peter Anvin wrote:
>>
>>> Okay, I've established that this is a bug in the Qemu kernel loader: the
>>> Qemu loader puts zero in the loadflags, which is wrong no matter how you
>>> slice it.
>>>
>>> I have checked in a workaround in
On Thu, May 17, 2007 at 02:09:16AM +0200, Christian wrote:
> my small VIA C3_2 box does not boot with 2.6.22-rc1.
> It even does not uncompress the kernel.
>
> The configuration as M386 M486 works. But M586 + MVIAC3_2
> does not work.
>
> solution for me, cahnge arch/i386/Kconfig.cpu
>
On Wed, May 16, 2007 at 02:26:14PM -1000, Joshua Hoblitt wrote:
> I don't think this is quiet right either as Ed Sweetman has reported
> that this issue doesn't occur on single socket/multi-core systems.
I'm not sure why [*], because this should be preventing it..
if
Timur Tabi wrote:
> For example, if I want to add a new driver C that uses library B, I can
> just add this:
>
> C
> select B
>
> If I have to use "depends on", then I would have to change the Kconfig
> option for B like this:
>
> B
> depends on A || C
You mean, "B... serves A, C".
On Wed, 16 May 2007 16:40:59 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Wed, 16 May 2007, Andrew Morton wrote:
>
> > (I hope. Might have race windows in which the percpu_counter_sum() count is
> > inaccurate?)
>
> The question is how do these race windows affect the locking
(resending , Owa-san was cut from cc list!??)
Hi,
On Tue, May 15, 2007 at 08:09:02PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2007-05-15 at 17:47 +0900, Tsutomu OWA wrote:
> > I encountered the following error when doing netperf from other machine
> > to Celleb running RT kernel.
I don't think this is quiet right either as Ed Sweetman has reported
that this issue doesn't occur on single socket/multi-core systems.
-J
--
On Thu, May 17, 2007 at 12:50:50AM +0100, Daniel Drake wrote:
> powernow-k8 uses PSB BIOS tables to read frequency info on UP systems, but
> on SMP it
Timur Tabi wrote:
> Stefan Richter wrote:
>> "A... select B" is just a flavor of "A... depends on B",
...
> I think you mean "A... select B" is just a flavor of "B... depends on
> A".
No, A requires B's symbols.
--
Stefan Richter
-=-=-=== -=-= =---=
http://arcgraph.de/sr/
-
To unsubscribe
When I boot 2.6.22-rc1-mm1 under kvm, but forget to specify a root
filesystem, it panics as expected. However, when panicing, it gets a
GPF in delay_tsc, and then starts recursively panicing.
I don't really understand what's going on; the instruction it's faulting
on seems to be "pause" (ie,
Hi,
my small VIA C3_2 box does not boot with 2.6.22-rc1.
It even does not uncompress the kernel.
The configuration as M386 M486 works. But M586 + MVIAC3_2
does not work.
solution for me, cahnge arch/i386/Kconfig.cpu
--- arch/i386/Kconfig.cpu.before 2007-05-17 01:38:26.0 +0200
+++
On Thu, May 17, 2007 at 12:50:50AM +0100, Daniel Drake wrote:
> powernow-k8 uses PSB BIOS tables to read frequency info on UP systems, but
> on SMP it requires the acpi-processor driver. Kconfig should be updated
> accordingly to avoid the issues that users are running into.
>
>
On Wed, May 16, 2007 at 04:40:20PM -0700, Jeremy Fitzhardinge wrote:
> David Chinner wrote:
> > Jeremy has tentatively indicated that the patch has fixed the problem.
> > Have you seen any more problems since applying the patch, Jeremy?
> >
>
> No, it continues to seem sound with casual use; I
powernow-k8 uses PSB BIOS tables to read frequency info on UP systems, but
on SMP it requires the acpi-processor driver. Kconfig should be updated
accordingly to avoid the issues that users are running into.
http://bugzilla.kernel.org/show_bug.cgi?id=8075
On Wednesday 16 May 2007 9:49 am, Francesco Pretto wrote:
> 2007/5/16, Stephen Clark <[EMAIL PROTECTED]>:
> > >On Tuesday 15 May 2007 5:08 pm, Dave Jones wrote:
> > >
> > >I'm confused. Could someone please explain?
> > >
> > I agree. This didn't happen when I was just using the ide driver, why
>
On Wednesday 16 May 2007 7:41 am, Tejun Heo wrote:
> Hello,
>
> Rob Landley wrote:
> > Um, hang on. So libata can't reliably turn the system off without data
loss
> > and potential damage to hardware unless userspace goes through a special
song
> > and dance? And this is _not_ considered a
On Wednesday 16 May 2007 5:15 am, Francesco Pretto wrote:
> - everyone else:
> // continue to do nothing :-)
> reboot();
That would be cool, but the impression I got from
http://linux-ata.org/shutdown.html was that shutdown commands were supposed
to _add_ quiescing of drives in order to avoid
Ingo Molnar wrote:
* Peter Williams <[EMAIL PROTECTED]> wrote:
As usual, any sort of feedback, bugreport, fix and suggestion is more
than welcome,
Load balancing appears to be badly broken in this version. When I
started 4 hard spinners on my 2 CPU machine one ended up on one CPU
and the
On 05/16, Roland McGrath wrote:
>
> + * After recalculating TIF_SIGPENDING, we need to make sure the task wakes
> up.
> + * This is superfluous when called on current, the wakeup is a harmless
> no-op.
> + */
> +void recalc_sigpending_and_wake(struct task_struct *t)
> +{
> + if
On Wed, 16 May 2007, Andrew Morton wrote:
> (I hope. Might have race windows in which the percpu_counter_sum() count is
> inaccurate?)
The question is how do these race windows affect the locking scheme?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Wed, May 16, 2007 at 07:21:16AM -0500, Dave Kleikamp wrote:
> On Wed, 2007-05-16 at 13:16 +1000, David Chinner wrote:
> > On Wed, May 16, 2007 at 01:33:59AM +0530, Amit K. Arora wrote:
>
> > > Following changes were made to the previous version:
> > > 1) Added description before
David Chinner wrote:
> Jeremy has tentatively indicated that the patch has fixed the problem.
> Have you seen any more problems since applying the patch, Jeremy?
>
No, it continues to seem sound with casual use; I would have expected to
see the problem reoccur by now. I'd like to rerun the
Daniel Drake wrote:
Ed Sweetman wrote:
Like i mentioned off list, the problem here is that cpu freq modules
dont depend (Kconfig) on CONFIG_ACPI_PROCESSOR, yet they do.
Not really. Firstly, some of the cpufreq modules *do* depend on
CONFIG_ACPI_PROCESSOR. Secondly, the ones that don't have
Correction, does *this patch* do it for you?
-hpa
diff --git a/arch/i386/boot/setup.ld b/arch/i386/boot/setup.ld
index e9ca0c2..c9c5530 100644
--- a/arch/i386/boot/setup.ld
+++ b/arch/i386/boot/setup.ld
@@ -44,5 +44,5 @@ SECTIONS
/DISCARD/ : { *(.note*) }
- ASSERT(_end
On Wed, May 16, 2007 at 10:31:39PM +0200, Michal Piotrowski wrote:
> Hi all,
>
> Here is a list of some known regressions in 2.6.22-rc1.
>
> Feel free to add new regressions/remove fixed etc.
> http://kernelnewbies.org/known_regressions
>
> File systems
>
> Subject: 2.6.21-git10/11: files
On Sat, 12 May 2007 11:06:24 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On 12 May 2007 20:55:28 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > Andrew Morton <[EMAIL PROTECTED]> writes:
> >
> > > On Fri, 11 May 2007 10:07:17 -0700 (PDT)
> > > Christoph Lameter <[EMAIL PROTECTED]> wrote:
'ioc' should be deallocated if __copy_from_user fails (found by Coverity
- CID 1644).
Signed-off-by: Florin Malita <[EMAIL PROTECTED]>
---
spidev.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index c0a6dce..2464f34 100644
---
Mel Gorman wrote:
> LD arch/i386/boot/setup.elf
> ld:arch/i386/boot/setup.ld:47: syntax error
Does this patch fix it for you?
-hpa
diff --git a/arch/i386/boot/setup.ld b/arch/i386/boot/setup.ld
index e9ca0c2..c9c5530 100644
--- a/arch/i386/boot/setup.ld
+++
Hi,
|--==> Ingo Molnar writes:
IM> i'm pleased to announce the v2.6.20-rt2 kernel, which can be downloaded
IM> from the usual place:
IM> http://redhat.com/~mingo/realtime-preempt/
This new version of the patch solves the amd64/udev bug I reported
against previous releases:
Stefan Richter wrote:
"A... select B" is just a flavor of "A... depends on B", with the
additional instruction to the Kconfig UIs: Don't hide A if you can
silently switch on B.
I think you mean "A... select B" is just a flavor of "B... depends on A". There is one
minor difference between
On Wed, May 16, 2007 at 11:19:29AM +0100, David Howells wrote:
>
> However, page_mkwrite() isn't told which bit of the page is going to be
> written to. This means it has to ask prepare_write() to make sure the whole
> page is filled in. In other words, offset and to must be equal (in AFS I set
Hi,
In testing we were noticing that we were getting some intermittent
crashes in profile_tick() when dyntick was enabled.
The crashes were because the frame pointer per_cpuirq_regs value was
0. That code does a user_mode(get_irq_regs()). Currently regs is set
only upon real hardware entry
Ed Sweetman wrote:
Like i mentioned off list, the problem here is that cpu freq modules
dont depend (Kconfig) on CONFIG_ACPI_PROCESSOR, yet they do.
Not really. Firstly, some of the cpufreq modules *do* depend on
CONFIG_ACPI_PROCESSOR. Secondly, the ones that don't have an existing
On Wed, 16 May 2007, David Miller wrote:
> > I have just verified that this locking scheme is indeed correct. So you
> > can add
> >
> > Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
> >
> > if you wish to, and submit the patch to Andrew.
> I guess I don't get sent networking patches any
OK. I think the gap between you and me is the definition of term
*context*. If you go to Linux Kernel Development, 2nd Edition (ISBN
0-672-32720-1), Page 6, then you will read the following:
in Linux, ... each processor is doing one of three things at any
given moment:
1. In kernel-space,
1 - 100 of 1096 matches
Mail list logo
