On Sun, 2006-11-26 at 11:48 -0800, Wink Saville wrote:
> Arjan van de Ven wrote:
> > it's the cost of a syscall (1000 cycles?) plus what it takes to get a
> > reasonable time estimate. Assuming your kernel has enough time support
> > AND your tsc is reasonably ok, it'll be using that. If it's NOT
On 11/26/06, Len Brown <[EMAIL PROTECTED]> wrote:
So the bigger question is why you need these workarounds in the first place.
in the LinuxBIOS, acpi support is there including acpi tables and dsdt
for amd chipset.
but for other chipset, I can not put dsdt there. becase we need one
clean room
On Mon, Nov 27, 2006 at 06:35:58AM +, Christoph Hellwig wrote:
> On Mon, Nov 27, 2006 at 03:16:48PM +0900, Akinobu Mita wrote:
> > The return value of dentry_open() shoud be checked by IS_ERR().
>
> first great work finding all these calling convetion mismatches.
>
> Do you have some tool to
On Mon, Nov 27, 2006 at 12:00:30PM +0900, you [Tejun Heo] wrote:
> Ville Herva wrote:
> >When ripping a cd with grip, I noticed the drive was not in DMA mode. I did
> >hdparm -d1 /dev/hdi. The grip process (it uses libcdda_paranoia.so and
> >libcdda_interface.so) hung, and attempt to kill it with
Aubrey wrote:
On 11/22/06, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
The lack of a MMU on your system makes it very hard not to rely on
higher order allocations, because even user-space allocs need to be
physically contiguous. But please take that into consideration when
writing software.
On Mon, Nov 27, 2006 at 03:16:48PM +0900, Akinobu Mita wrote:
> The return value of dentry_open() shoud be checked by IS_ERR().
first great work finding all these calling convetion mismatches.
Do you have some tool to find these?
I wonder whether we should have some form of sparse annotation to
The return value of dentry_open() shoud be checked by IS_ERR().
Cc: Stephen Smalley <[EMAIL PROTECTED]>
Cc: James Morris <[EMAIL PROTECTED]>
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
---
security/selinux/hooks.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index:
Andrew Morton wrote:
On Sun, 12 Nov 2006 17:30:24 -0500
Nick Orlov <[EMAIL PROTECTED]> wrote:
Andrew,
Somewhere in between 2.6.18-mm3 and 2.6.19-rc4-mm1 writev() got screwed.
It does not accept zero-length segments anymore.
Bad thing that it is extremely easy to trigger (even w/o explicit
On Mon, Nov 27, 2006 at 01:59:34AM +0100, Adrian Bunk wrote:
> NET_SCH_ATM doesn't need ipcommon.o
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> --- linux-2.6.19-rc6-mm1/net/atm/Makefile.old 2006-11-26 08:50:05.0
> +0100
> +++ linux-2.6.19-rc6-mm1/net/atm/Makefile
Am I mistaken or did this patch never make it into the kernel?
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0902.html
I had to apply that patch a short while ago to 2.6.12.4 to fix kernel
crashes with some web servers at my previous place of employment.
Just now getting around to
On Sun, Nov 26, 2006 at 02:35:03AM +0100, Adrian Bunk ([EMAIL PROTECTED]) wrote:
> CONFIG_W1_SLAVE_DS2433_CRC can be used directly, there's no reason for
> the indirection of defining a different variable in the Makefile.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
I will add apply this
"acpi=noirq" and "pci=noacpi" are not reliable in IOAPIC mode --
as, by definition, they skip the processing of the ACPI interrupt itself.
On some systems this happens to work, and on some systems it doesn't --
depends on if there was an override for the SCI or if it appears as
a standard PCI
Initialization synclink_gt forgot to unregister pci driver on error path.
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
---
drivers/char/synclink_gt.c |1 +
1 file changed, 1 insertion(+)
Index: work-fault-inject/drivers/char/synclink_gt.c
This patch checks the return value of platform_device_register_simple().
Cc: David Brownell <[EMAIL PROTECTED]>
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
---
drivers/spi/spi_butterfly.c |2 ++
1 file changed, 2 insertions(+)
Index: work-fault-inject/drivers/spi/spi_butterfly.c
The return value of crypto_alloc_hash() should be checked by
IS_ERR().
Cc: Dmitry Yusupov <[EMAIL PROTECTED]>
Cc: Alex Aizman <[EMAIL PROTECTED]>
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
---
drivers/scsi/iscsi_tcp.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index:
This patch refactors the ipc sysctl support so that it is
simpler, more readable, and prepares for fixing the bug
with the wrong values being returned in the sys_sysctl interface.
The function proc_do_ipc_string was misnamed as it never handled
strings. It's magic of when to work with strings
This patch introduces get_uts and put_uts (used later)
and removes most of the special cases for when UTS namespace is compiled in.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
kernel/sysctl.c | 128 +++
1 files changed, 26
The return value of crypto_alloc_blkcipher() should be checked by
IS_ERR().
Cc: Mike Halcrow <[EMAIL PROTECTED]>
Cc: Phillip Hellewell <[EMAIL PROTECTED]>
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
---
fs/ecryptfs/crypto.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index:
On Fri, Nov 24, 2006 at 09:21:53PM +0300, Oleg Nesterov wrote:
> Ok, synchronize_xxx() passed 1 hour rcutorture test on dual P-III.
>
> It behaves the same as srcu but optimized for writers. The fast path
> for synchronize_xxx() is mutex_lock() + atomic_read() + mutex_unlock().
> The slow path is
Currently there is a regression and the ipc sysctls
don't show up in the binary sysctl namespace.
This patch adds sysctl_ipc_data to read data/write from the
appropriate namespace and deliver it in the expected manner.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
kernel/sysctl.c |
The return value of create_write_pipe()/create_read_pipe() should be
checked by IS_ERR().
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
---
kernel/kmod.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
Index: work-fault-inject/kernel/kmod.c
The problem: When using sys_sysctl we don't read the proper values
for the variables exported from the uts namespace, nor do we do the
proper locking.
This patch introduces sysctl_uts_string which properly fetches the values
and does the proper locking.
Signed-off-by: Eric W. Biederman <[EMAIL
This patch checks register_filesystem() and kern_mount() return
values.
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
---
kernel/futex.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
Index: work-fault-inject/kernel/futex.c
The binary interface to the namespace sysctls was never implemented
resulting in some really weird things if you attempted to use
sys_sysctl to read your hostname for example.
This patch series simples the code a little and implements the binary
sysctl interface.
In testing this patch series I
kstrdup() returns NULL on error.
Cc: David Woodhouse <[EMAIL PROTECTED]>
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
---
kernel/auditfilter.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: work-fault-inject/kernel/auditfilter.c
On Sun, Nov 26, 2006 at 02:20:10PM -0800, Linus Torvalds wrote:
> So arguably, the result is _more_ like a normal C operation this way.
> Type-wise, the "ALIGN()" macro acts like any other C operation (ie if you
> feed it an "unsigned char", the end result is an "int" due to the normal C
> type
On Fri, Nov 24, 2006 at 12:49:08AM +0300, Oleg Nesterov wrote:
> On 11/23, Paul E. McKenney wrote:
> >
> >For general use, I believe that this has
> > difficulties with the sequence of events I sent out on November 20th, see:
> >
> >
paravirt: reorder functions to avoid unspecified behaviour
The paravirt ops introduce a 'weak' attribute onto memory_setup().
Code ordering leads to the following warnings on x86:
arch/i386/kernel/setup.c:651: warning: weak declaration of
`memory_setup' after first use
Running with 8GB of memory, dual Xeon system on a 2.6.18 kernel, the
following error occurs when the system finally exhausts
physical memory prior to using swap space (results in a reboot of the
system) :
Nov 26 04:10:00 gadugi syslogd 1.4.1: restart.
Nov 26 10:33:24 gadugi kernel: Non-Fatal
On 27 Nov 2006 01:22:21 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Sun, Nov 26, 2006 at 03:23:36PM -0800, Yinghai Lu wrote:
>
Are you sure it's correct? The drivers/pci pci= parsing
isn't early and there tend to be nasty ordering issues.
I can't see where it would go wrong here, but it
On Wed, Nov 15, 2006 at 11:22:23AM -0700, Berck E. Nash wrote:
> Tejun Heo wrote:
> >Hmmm.. Can you try with the attached patch applied? Also, please turn
> >on kernel config 'Kernel Hacking -> Show timing info on printks' and
> >report boot dmesg.
>
> Looks like you forgot to attach the
Dear Maurice Volaski,
Please update Areca Firmware version into 1.42.
Areca's firmware team found some problems on high capacity transfer.
Hope the weird phenomenon should disappear.
Areca had some experiences from its subsystem producers about vibration.
The vibration issue can lower your
gary.czek wrote:
Hi, I have problem with my notebook Fujitsu-Siemens V8010. It has Intel
ICH6M chipset with SATA Controller. And SATA II disk Fujitsu MHT2040BH
with NCQ. If there is request on disk, iowait time of CPU gets to 100%
and whole system gets totally unresponsible. For example apt
MODPOST
WARNING: drivers/acpi/processor.o - Section mismatch: reference to
.init.data: from .text between 'acpi_processor_power_init' (at offset
0x14de) and 'acpi_processor_power_exit'
AS arch/i386/boot/compressed/head.o
Turned on APCI and am now getting the above warning.
Did a
Ville Herva wrote:
When ripping a cd with grip, I noticed the drive was not in DMA mode. I did
hdparm -d1 /dev/hdi. The grip process (it uses libcdda_paranoia.so and
libcdda_interface.so) hung, and attempt to kill it with -KILL failed.
Eventually it died but remained as zombie:
Known problem
udev seems to be going nuts in 2.6.19-rc6-mm1, adding and removing
/dev/md0 and using a ton of CPU. This with the versions in both Fedora
Core 5 and 6. This doesn't happen in older kernels, the last one I
tested was 2.6.19-rc3-mmsomething. If I kill udevd and start it again it
seems fine then.
> This must be a bisection false positive. The patch in question is
> essentially a no-op for a UP kernel.
Testing alternately with
1) all -mm1 patches applied, and
2) all except sched-improve-migration-accuracy*.path applied,
confirms the misbehavior.
-
To unsubscribe from
On 11/22/06, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
Yes it does that, but there is no guarantee that those 50MB have a
single 1M contiguous region amongst them.
right ... the testcase posted is more to quickly illustrate the
problem ... the requested size doesnt really matter, what does
On Sunday 26 November 2006 2:53 pm, Alessandro Zummo wrote:
> On Sun, 26 Nov 2006 22:37:10 +0100
> "Joakim Tjernlund" <[EMAIL PROTECTED]> wrote:
>
> > > the concept of static numbers is quite old...
> >
> > Yes it is old, but is the old way unsupported now? I have an embedded target
> > which
NET_SCH_ATM doesn't need ipcommon.o
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.19-rc6-mm1/net/atm/Makefile.old 2006-11-26 08:50:05.0
+0100
+++ linux-2.6.19-rc6-mm1/net/atm/Makefile 2006-11-26 08:56:29.0
+0100
@@ -10,7 +10,6 @@
atm-$(subst
On Sun, Nov 26, 2006 at 04:29:00PM -0800, Linus Torvalds wrote:
> On Sun, 26 Nov 2006, Russell King wrote:
> > >
> > > Ralf, Russell, does this work for you guys?
> >
> > Not at all. It creates even more problems for me, with this circular
> > dependency:
>
> Ok. I just reverted it then.
>
>
On Sun, 26 Nov 2006, Russell King wrote:
> >
> > Ralf, Russell, does this work for you guys?
>
> Not at all. It creates even more problems for me, with this circular
> dependency:
Ok. I just reverted it then.
Pls verify that this is all good, and I didn't mess anything up due to the
On Sun, Nov 26, 2006 at 03:22:10PM -0800, Yinghai Lu wrote:
>
Added thanks
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
On Sun, Nov 26, 2006 at 03:24:32PM -0800, Yinghai Lu wrote:
>
Can you resend that one cc [EMAIL PROTECTED], linux-acpi@vger.kernel.org
please ?
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Sun, Nov 26, 2006 at 03:23:36PM -0800, Yinghai Lu wrote:
>
Are you sure it's correct? The drivers/pci pci= parsing
isn't early and there tend to be nasty ordering issues.
I can't see where it would go wrong here, but it probably
needs very careful double checking.
-Andi
-
To unsubscribe from
I've got a patch that fixes acpi_video_get_next_level in the ACPI video
driver. I sent it to linux-kernel, linux-acpi, and some people at
Intel. It's a very short and simple patch that fixes the brightness
hotkeys on my laptop, and probably others. (The function it fixes had
/* Fix me */
On Sun, Nov 26, 2006 at 03:06:10PM -0800, Linus Torvalds wrote:
> That said, Alexey did check it more than most patches like this get
> checked (ie checking allmodconfig on i386, x86_64, alpha, arm), so it's a
> bit unlucky that MIPS got bitten by this - it was not a badly tested
> patch per
I think I found a bug introduced in v2.6.18-g23541d2 (git-bisect).
The computer has a dual core amd64 with 1GB ram and 3GB swap space,
64 bit kernel and 32 bit userland.
What I did:
- run the mprime 'torture test' with the memory option set to 1500MB
On Saturday 21 October 2006 20:08, Ben Greear wrote:
> > > or shouldn't rpm notice the previous process is dead and
> > > clean it up itself?
> >
> > Sounds sensible to me and you, but in the past sensible ideas and
> > rpm maintainers haven't gone hand in hand.
> >
> Ahhh :)
Well said.
I still think using BUILD_BUG_ON() is unacceptable, especially given how
vague the error message was.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
diff --git a/include/asm-parisc/semaphore.h b/include/asm-parisc/semaphore.h
index c9ee41c..d45827a 100644
---
On Sun, Nov 26, 2006 at 10:49:28PM +, Ralf Baechle wrote:
> ee3ce191e8eaa4cc15c51a28b34143b36404c4f5 breaks MIPS completely:
>
Ack on parisc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[PATCH 3/3] x86: when acpi_noirq is set, use mptable instead of MADT
When using pci=noacpi, or apci=noirq, acpi_noirq is set. We should skip
acpi_process_madt. Because it will set acpi_lapic and acpi_ioapic, at last
mptable is skipped, but we need io apic routing table in mptable.
[PATCH 2/3] x86: remove duplicated parser for "pci=noacpi"
Remove "pci=noacpi" parse in acpi/boot.c, because it is duplicated
with that in pci/common.c.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/acpi/boot.c b/arch/i386/kernel/acpi/boot.c
index
[PATCH 1/3] x86_64: remove unused acpi_found_madt in mparse.
remove unused acpi_found_madt in mparse.c
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86_64/kernel/mpparse.c b/arch/x86_64/kernel/mpparse.c
index b147ab1..0807256 100644
--- a/arch/x86_64/kernel/mpparse.c
+++
On Sun, Nov 26, 2006 at 03:12:54PM -0800, Linus Torvalds wrote:
>
>
> On Sun, 26 Nov 2006, Linus Torvalds wrote:
> >
> > Does the obvious fix (to include in irqflags.h) fix it
> > for you?
>
> Btw, Alexey, why did you do _both a BUILD_BUG_ON and a "typecheck()"?
>
> If there are any broken
while i was testing LinuxBIOS with ACPI support but left dsdt out,
found if MADT is there, the MPTABLE will be skipped. and device can
not use irq routing in mptable.
Please check it
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Jens Axboe oracle.com> writes:
>
> On Tue, Nov 21 2006, Pavel Machek wrote:
> > Hi!
> >
> > > Well, the actual question is the following,
> > > I read about HDAPS on thinkWiki. But there is no known-to-work patch for
> > > 2.6.18 and above to enable queue-freezing/harddisk parking.
> > > After
On Sun, 26 Nov 2006, Linus Torvalds wrote:
>
> Does the obvious fix (to include in irqflags.h) fix it
> for you?
Btw, Alexey, why did you do _both a BUILD_BUG_ON and a "typecheck()"?
If there are any broken users, we shouldn't break the build, but a
_warning_ is certainly appropriate.
I
On Sun, Nov 26, 2006 at 11:05:16PM +, Russell King wrote:
> Ditto on ARM. This level of breakage is simply not acceptable soo
> close to a release, and needs the change reverting.
>
> Note that on ARM, "allmodconfig" is really meaningless since it only
> tests one configuration. Ditto for
On Sun, Nov 26, 2006 at 10:49:28PM +, Ralf Baechle wrote:
> ee3ce191e8eaa4cc15c51a28b34143b36404c4f5 breaks MIPS completely:
>
> In file included from include/linux/bitops.h:9,
> from include/linux/thread_info.h:20,
> from include/linux/preempt.h:9,
>
On Sun, 26 Nov 2006, Ralf Baechle wrote:
>
> That sort of patches really should go to /dev/null so short before a release.
Yeah, I don't think it was worth it.
That said, Alexey did check it more than most patches like this get
checked (ie checking allmodconfig on i386, x86_64, alpha, arm),
On Sun, 2006-11-26 at 19:52 +, Alistair John Strachan wrote:
> On Sunday 26 November 2006 18:07, Kasper Sandberg wrote:
> > On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> > > On Wed, 22 Nov 2006 15:29:02 +0100
> > >
> > > Kasper Sandberg <[EMAIL PROTECTED]> wrote:
> > > > it appears
On Sun, 26 Nov 2006 22:37:10 +0100
"Joakim Tjernlund" <[EMAIL PROTECTED]> wrote:
> > the concept of static numbers is quite old...
>
> Yes it is old, but is the old way unsupported now? I have an embedded target
> which is using the old static /dev directory, do I need to make
> it udev aware
ee3ce191e8eaa4cc15c51a28b34143b36404c4f5 breaks MIPS completely:
In file included from include/linux/bitops.h:9,
from include/linux/thread_info.h:20,
from include/linux/preempt.h:9,
from include/linux/spinlock.h:49,
from
On Sunday 26 November 2006 17:19, Dave Airlie wrote:
> On 11/27/06, Alan <[EMAIL PROTECTED]> wrote:
> > On Sun, 26 Nov 2006 09:18:41 +0100
> >
> > Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > > > The mode switch sequences for modern cards are a bit more hairy than
> > > > lists of I/O poking
On 11/20, Oleg Nesterov wrote:
>
> So, if we have global A == B == 0,
>
> CPU_0 CPU_1
>
> A = 1; B = 2;
> mb(); mb();
> b = B; a = A;
>
> It could happen that a == b == 0, yes? Isn't this contradicts with definition
> of mb?
I still
On Sun, 26 Nov 2006, Roland Dreier wrote:
>
> > +#define ALIGN(x,a)__ALIGN_MASK(x,(typeof(x))(a)-1)
> > +#define __ALIGN_MASK(x,mask) (((x)+(mask))&~(mask))
>
> Fine by me, but it loses the extra (typeof(x)) cast that Al wanted to
> make sure that the result of ALIGN() is
On 11/27/06, Alan <[EMAIL PROTECTED]> wrote:
On Sun, 26 Nov 2006 09:18:41 +0100
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > The mode switch sequences for modern cards are a bit more hairy than
> > lists of I/O poking unfortunately.
>
> for the Intel hw Keith doesn't seem to think it's all
Joakim Tjernlund wrote:
Is that the way it is supposed to be? How do I create a
static /dev/rtcN in my /dev
directory if the major number isn't fixed?
Maybe I am just missing something, feel free to correct me :)
udev ;)
the concept of static numbers is quite old...
Yes it is old, but is
> -Original Message-
> From: Alessandro Zummo [mailto:[EMAIL PROTECTED]
> Sent: den 26 november 2006 20:22
> To: Joakim Tjernlund
>
> On Sun, 26 Nov 2006 12:04:54 +0100
> "Joakim Tjernlund" <[EMAIL PROTECTED]> wrote:
>
> > Looking at rtc-dev.c I don't see a MARJOR number assigned
> to
On 11/25, Alan Stern wrote:
>
> Yes, you are right. The corrected routine (including your little
> optimization) looks like this:
>
> void synchronize_xxx(struct xxx_struct *sp)
> {
> int idx;
>
> mutex_lock(>mutex);
> spin_lock(>lock);
> idx = sp->completed & 0x1;
>
On Sun, 26 November 2006 12:26:08 -0800, Roland Dreier wrote:
>
> > +#define ALIGN(x,a)__ALIGN_MASK(x,(typeof(x))(a)-1)
> > +#define __ALIGN_MASK(x,mask) (((x)+(mask))&~(mask))
>
> Fine by me, but it loses the extra (typeof(x)) cast that Al wanted to
> make sure that the
Hi!
> > Hmm... how common are these machines? We are using unpatched kernel
> > for suse10.2... OTOH we only support machines from the whitelist, all
>
> I've always said IDE and software suspend are unsafe. The more work I do
> the more clearly this is/was the case.
Well, there's unsafe as in
On Wednesday 15 November 2006 22:48, Amul Shah wrote:
> This patch removes the statically allocated memory to NUMA node hash map
> in favor of a dynamically allocated memory to node hash map (it is cache
> aligned).
>
> This patch has the nice side effect in that it allows the hash map to
> grow
On Sat, Nov 25, 2006 at 07:11:48PM +, David Johnson wrote:
> I'm working on a kernel module and want to change sysctl values (specifically
> stop-a and printk) in response to a hardware event.
>
> Is there an accepted way of setting sysctl values within the kernel (I can't
> seem to find any
Rafael J. Wysocki wrote:
btw, I have some code almost ready for sata_nv to add proper
suspend/resume support. Unfortunately I have trouble testing it, since
STR doesn't work on my machine since, guess what - the video doesn't
come back! It doesn't even take the monitor out of standby mode.
> +#define ALIGN(x,a) __ALIGN_MASK(x,(typeof(x))(a)-1)
> +#define __ALIGN_MASK(x,mask)(((x)+(mask))&~(mask))
Fine by me, but it loses the extra (typeof(x)) cast that Al wanted to
make sure that the result of ALIGN() is not wider than x.
- R.
-
To unsubscribe from this list:
Vitaly Wool wrote:
> Hello Pierre,
>
> currently on SD/MMC card removal the system exhibits the following message
> (the platform is ARM Versatile):
>
> prev->state: 2 != TASK_RUNNING??
> mmcqd/762[CPU#0]: BUG in __schedule at linux-2.6/kernel/sched.c:3826
>
Hmm... I can't find any
The attached patch against 2.6.19-rc6-mm1 fixes some problems in sata_nv
with ATAPI devices on controllers running in ADMA mode. Some of the
logic in the nv_adma_bmdma_* functions was inverted causing a bunch of
warnings and caused those functions not to work properly. Also, when an
ATAPI
Sometimes the soft watchdog fires after we're done oopsing.
See http://projects.info-pull.com/mokb/MOKB-25-11-2006.html for an example.
The NMI watchdog could also fire, so tickle both watchdogs.
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
--- linux-2.6/arch/i386/kernel/traps.c~ 2006-11-26
On Sun, 26 Nov 2006, Andrew Morton wrote:
>
> I'd be inclined to merge it for 2.6.19. Is everyone OK with it?
I'd _much_ rather make it more readable while at it. Something like this
instead, which has just _one_ "typeof" cast, and at least to me makes it a
lot more obvious what is going on
> I'd be inclined to merge it for 2.6.19. Is everyone OK with it?
I'm OK with that -- your previous email made me thing you didn't want
to, but I think the risks are rather low, and there's a least a chance
that we'll fix some obscure regression.
-
To unsubscribe from this list: send the line
On Sunday 26 November 2006 18:07, Kasper Sandberg wrote:
> On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> > On Wed, 22 Nov 2006 15:29:02 +0100
> >
> > Kasper Sandberg <[EMAIL PROTECTED]> wrote:
> > > it appears some sort of bug has gotten into .19, in regards to x86
> > > emulation on
Arjan van de Ven wrote:
it's the cost of a syscall (1000 cycles?) plus what it takes to get a
reasonable time estimate. Assuming your kernel has enough time support
AND your tsc is reasonably ok, it'll be using that. If it's NOT using
that then that's a pretty good sign that you can't also use
Hi all,
I may have stumbled upon a bug (or is it a feature?). First off though,
I am reporting this based on my recollection - so my description might
not be 100% accurate (this happened about two months ago). Since I don't
have time to set up a verification scenario, I figured I'd just report
> Patch with the memset follows.
Added thanks
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Sunday 26 November 2006 02:02, Adrian Bunk wrote:
> One ARCH_DISCONTIGMEM_ENABLE option is enough.
Added thanks
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Sunday 26 November 2006 14:15, Olivier Galibert wrote:
> Ok, here you go, what about that? I'll be able to test it on i386 on
> monday, not before. It's hard to doa full 32bits install remotely :-)
Sorry, please don't put it all into a single patch. Do one patch
that just moves code, then
On Sunday 26 November 2006 07:47, Dave Jones wrote:
> Sometimes the soft watchdog fires after we're done oopsing.
> See http://projects.info-pull.com/mokb/MOKB-25-11-2006.html for an example.
>
> Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
>
> --- linux-2.6.18.noarch/arch/i386/kernel/traps.c~
On Sun, 26 Nov 2006 12:04:54 +0100
"Joakim Tjernlund" <[EMAIL PROTECTED]> wrote:
> Looking at rtc-dev.c I don't see a MARJOR number assigned to /dev/rtcN. Seems
> like
> it is dynamically allocated to whatever major number that is free.
> Is that the way it is supposed to be? How do I create a
Adrian Bunk <[EMAIL PROTECTED]> writes:
> It's still not used...
>
> So let's unexport it again until some driver that actually uses it shows up.
Fair enough.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Sun, 26 Nov 2006 11:10:23 -0800
Roland Dreier <[EMAIL PROTECTED]> wrote:
> Commit 4c8bd7ee ("Do not truncate to 'int' in ALIGN() macro.") was
> merged to fix the case of code like the following:
>
> unsigned long addr;
> unsigned int alignment;
> addr = ALIGN(addr,
> Changes this late in the piece rather hurt.
Fair enough. This was a really close call to me but let's leave it
for 2.6.19. I'll ask Linus to merge the patch below to fix amso1100.
I'm a little worried that other such uses might be lurking in the
tree but I guess no one has complained...
>
Commit 4c8bd7ee ("Do not truncate to 'int' in ALIGN() macro.") was
merged to fix the case of code like the following:
unsigned long addr;
unsigned int alignment;
addr = ALIGN(addr, alignment);
The original ALIGN macro calculated a mask as ~(alignment - 1), and
when
On Wed, 2006-11-22 at 15:25 -0800, Andrew Morton wrote:
> On Wed, 22 Nov 2006 15:29:02 +0100
> Kasper Sandberg <[EMAIL PROTECTED]> wrote:
>
> > it appears some sort of bug has gotten into .19, in regards to x86
> > emulation on x86_64.
> >
> > i have only tested with >=rc5, thw folling, as an
Hi,
I have a "hamlet xsataci" card[1], which is basically a PCI card with
both an Ali M5228 PATA controller and a M5281 SATA controller:
05:02.0 Mass storage controller: ALi Corporation ALi M5281 Serial ATA / RAID
Host Controller (rev a4)
05:02.1 Mass storage controller: ALi Corporation M5228
Hej,
we're a student group witch is working on a research project concerning
the ability to switch the cpu scheduler of the linux kernel at runtime.
We use Peter Williams Plugsched patch [1] to get an interface for the
different scheduler implementations. Some month ago we started to modify
the
Standardize the miniscule percentage of occurrences of "depends" in
Kconfig files to "depends on", and update kconfig-language.txt to
reflect that.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
This patch doesn't address the redundancy of "requires", nor does it
simplify the
i'm thinking that the kconfig structure doesn't really need to
support all three of these dependency directives for Kconfig files. a
quick occurrence count:
"depends on": 4421
"depends":45
"requires": 0
under the circumstances, why not just standardize on "depends on"
> i've released the 2.6.19-rc6-rt5 tree, which can be downloaded from the
Hi
this fixes issues like rmmod hanging and inodes leaking.
Karsten
--- fs/dcache.c~2006-11-21 11:25:11.0 +0100
+++ fs/dcache.c 2006-11-26 15:20:31.0 +0100
@@ -150,7 +150,7 @@ void
1 - 100 of 250 matches
Mail list logo
