On Sunday 13 May 2007 05:20, Jan Engelhardt wrote:
> On May 12 2007 20:20, Linus Torvalds wrote:
> >
> >Ok, the merge window has closed, and 2.6.22-rc1 is out there.
>
> I have hit a randconfig compile failure. .config attached.
>
> LD .tmp_vmlinux1
> drivers/built-in.o: In function `acpi_
From: Satyam Sharma <[EMAIL PROTECTED]>
Date: Thu, 17 May 2007 11:13:36 +0530 (IST)
> [PATCH] bluetooth: fix locking in hci_sock_dev_event()
BTW, your email client corrupted the patch spaces and tabs
a lot, I applied your patch by hand but I will not do that
next time. Please look into getting y
On Friday 11 May 2007 03:28:46 Thomas Gleixner wrote:
> Ok, that's consistent with earlier reports. The problem surfaces when
> one of the SMT-"cpus" goes idle. The problem goes away when you disable
> hyperthreading.
Yes with HT disabled in BIOS there is no local_softirq_pending messages. BTW
wh
David Howells wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
You can drop the lock, do the invalidation,
Hmmm... There's a danger of incurring a race by doing that. Consider two
processes both trying to write to a dirty page for which writeback will be
rejected:
(1) The first process get
Bernardo Innocenti (on Thu, 17 May 2007 02:36:21 -0400) wrote:
>Keith Owens wrote:
>
>> Before using MSR, you must first check that the cpu supports the
>> instruction, rd/wrmsr cause an oops on 486 or earlier. Also using an
>> invalid msr number causes an oops, so use rd/wrmsr_safe().
>
>I didn't
> From: Williams, Dan J
> On a closer look, it seems async_tx should be its own directory like
crypto...
> I'll post the incremental changes to the md-accel git tree for review.
>
Here is a copy of the patch added to the md-accel series
(git://lost.foo-projects.org/~dwillia2/git/iop md-accel-linu
Keith Owens wrote:
> Before using MSR, you must first check that the cpu supports the
> instruction, rd/wrmsr cause an oops on 486 or earlier. Also using an
> invalid msr number causes an oops, so use rd/wrmsr_safe().
I didn't bother implementing those checks because kdb recovers
nicely from GPF
Dave Jones wrote:
>
> agreed, though we'll still need something for .22 (I'm assuming your rework
> isn't intended for .22)
>
My suggestion would be to take out the CPU verification code for .22 and
merge the rewrite in .23.
-hpa
-
To unsubscribe from this list: send the line "unsubscri
On Wed, May 16 2007, Badari Pulavarty wrote:
> On Tue, 2007-05-15 at 19:50 +0200, Jens Axboe wrote:
> > On Tue, May 15 2007, Badari Pulavarty wrote:
> > > On Tue, 2007-05-15 at 19:20 +0200, Jens Axboe wrote:
> > > > On Tue, May 15 2007, Badari Pulavarty wrote:
> > > > > On Fri, 2007-05-11 at 15:51
On Wed, May 16, 2007 at 12:47:54PM -0700, Linus Torvalds wrote:
>
> On Wed, 16 May 2007, Hugh Dickins wrote:
>
> > > The other option of moving the bit into ->mapping hopefully avoids all
> > > the issues, and would probably be a little faster again on the P4, at the
> > > expense of being a more
After a suspend/resume cycle, the UART may have been reset into
low-speed mode -- either because it's actually been reset, or because
the firmware pokes at the old-style divisor registers. If we detected it
as a NS16550A SuperIO chip in the first place and set baud_base to
921600, then we should do
On Thu, 2007-05-17 at 15:12 +0900, Dongjun Shin wrote:
> The current trend of flash-based device is to hide the flash-specific details
> from the host OS. The flash memory is encapsulated in a package
> which contains a dedicated controller where a small piece of software (F/W or
> FTL)
> runs and
Bernardo Innocenti (on Tue, 15 May 2007 23:03:55 -0400) wrote:
>Jordan Crouse wrote:
>
>> Can you break this up with a : between the high dword and the low dword?
>> That makes it easier to parse when debugging.
>
>Good idea, but I used "_" instead because it's what AMD uses in their
>documentation
On Wed, May 16, 2007 at 08:16:11PM -0700, 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
On Wed, May 16, 2007 at 09:51:36PM -0700, H. Peter Anvin wrote:
> 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
>
Hello Oleg, Andrew,
Sure no problem Oleg, compiling now, reboot will follow with results.
Thank you both !
On Thu, 2007-05-17 at 02:55 +0400, Oleg Nesterov wrote:
> Zilvinas, could you try the patch below?
>
> It is a shot in the dark. I hope I'll suggest somethimg better tomorrow.
>
> Oleg.
>
On Wed, 2007-05-16 at 19:54 -0500, Kumar Gala wrote:
> On May 16, 2007, at 4:33 PM, Antonino A. Daplas wrote:
>
> > Move arch-specific bits of fb_mmap() to their respective
> > subdirectories
> >
> You don't need a version in asm-ppc since you have one in asm-
> powerpc. We are slowly phasing
On Wed, May 16, 2007 at 11:36:46PM -0500, Bob Tracy wrote:
> 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 actu
Hi Jiri,
> > > 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 more?
> > :-)
>
> We
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 alread
[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,
bh
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: Thurs
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 probl
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 dentr
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.
Cod
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 numb
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 now
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 d
> 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
Crash,
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 ker
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 devi
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 a
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 reason
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: Dave
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]
Mo
-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(&hd), so something in the hpet
> code is still buggy. Adding nohpet to the kernel command line allows it
> to boot correc
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 `detect
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 C
[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 inc
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)
> signal_wake_
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 wher
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
>> f
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 noth
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 k
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 wit
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 2T
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 erro
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 sparsemem
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 ts
[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
tr
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?
>
>>From
> 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 ar
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/
> > >
> >
> > Almost
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 un
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
sp=e140422
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 versio
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
http://www.kerne
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
> fo
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
CONFIG_MODE_SK
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 e
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 with
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 hardwa
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 (and
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 line
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
> 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 lar
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 (num_online
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".
How
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. PREEPT
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 requ
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 fro
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, rep;
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
+++ ar
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.
>
> http://bugzil
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
https://bugs.gentoo.org/show_bug.cgi?id=17
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 d
1 - 100 of 550 matches
Mail list logo
