Neil Horman <[EMAIL PROTECTED]> writes:
> Recently a kdump bug was discovered in which a system would hang inside
> calibrate_delay during the booting of the kdump kernel. This was caused by
> the
> fact that the jiffies counter was not being incremented during timer
> calibration. The root
Exactly constant timing in every iteration:
cycles: out 667, in 305
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Celeron (Coppermine)
stepping: 3
cpu MHz : 497.582
cache size : 128 KB
fdiv_bug: no
Would you like to submit the Driver Test Cases to LTP ? Or, if you have
your Driver test cases written in C, we can port to LTP and have it
inside the LTP package.
You can also check out the following links for more info, and can always
ping me for anything:
On Dec 12, 2007 7:31 AM, Rene Herman <[EMAIL PROTECTED]> wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to port
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial
On Tue 11-12-07 15:43:10, Andrew Morton wrote:
> On Tue, 11 Dec 2007 14:43:19 +0100
> Jan Kara <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > attached patch makes add_dquot_ref() quite faster if used on a life
> > filesystem. It has survived some testing on my machine but there could be
> >
On 12/12/2007 12:31 AM, Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and
> run the attached program? This is about testing how long I/O port access
model name : Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz
cycles: out 6490, in
Patch looks good, it seems a merge conflict of
commit 19bc5133dae9562e8824ef101464061f9854c1d8
was resolved the wrong way.
@Mauro:
Any objections against a later path that changes the exports to the
general "immediately after the function" convention?
It would have avoided at least two such bugs
On Wed, 5 Dec 2007 11:27:27 +0100 [EMAIL PROTECTED] wrote:
> Fixes wrong netmos 9855 serial port configuration.
>
> Generated on 20071205 against v2.6.21
>
> Signed-off-by: Christian Pellegrin <[EMAIL PROTECTED]>
> ---
> drivers/parport/parport_serial.c |4 ++--
> 1 files changed, 2
>-Original Message-
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>Sent: Dienstag, 11. Dezember 2007 15:53
>In the second use-case (tracing, profiling, call coverage metrics), we
>could live without zero-copy, as long as the buffer could be
>made "large
>enough". The current 4000
Kiyoshi Ueda wrote:
> This patch converts xsysace to use blk_end_request interfaces.
> Related 'uptodate' arguments are converted to 'error'.
>
> xsysace is a little bit different from "normal" drivers.
> xsysace driver has a state machine in it.
> It calls end_that_request_first() and
Can someone explain me that?
Dec 12 00:24:15 santorini kernel: Unable to handle kernel NULL pointer
dereference at virtual address
Dec 12 00:24:15 santorini kernel: printing eip:
Dec 12 00:24:15 santorini kernel: c0190182
Dec 12 00:24:15 santorini kernel: *pde = 1b62b001
Dec 12 00:24:15
$ for i in `seq 5`; do ./port80; sleep 1; done
cycles: out 5260, in 2372
cycles: out 5260, in 2384
cycles: out 5260, in 2323
cycles: out 5270, in 2382
cycles: out 5259, in 2323
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model
* Harvey Harrison <[EMAIL PROTECTED]> wrote:
> Now that x86 uses regparm(3) by default, we can get rid of the
> FASTCALL() macro. This gets rid of it in all linux/include header
> files.
i suspect this patch is for Andrew and -mm.
i've picked your other, x86 unification patches up into
* Dhaval Giani <[EMAIL PROTECTED]> wrote:
> > Hm, how about describing the units here? Can you put "10" in each
> > file and everyone will get the same share? 100? 1? 1024 seems
> > like an odd "share" number. Unless there is some other document you
> > wish to refer people to do help
On Wed, 5 Dec 2007 11:26:45 +0100 [EMAIL PROTECTED] wrote:
> This patch adds support for the MAX3100 SPI UART.
>
Doesn't compile on x86_64:
drivers/serial/max3100.c: In function 'startup':
drivers/serial/max3100.c:706: error: 'IRQT_FALLING' undeclared (first use in
this function)
On Dec 12, 2007 5:17 PM, Oliver Falk <[EMAIL PROTECTED]> wrote:
> Can someone explain me that?
>
> Dec 12 00:24:15 santorini kernel: Unable to handle kernel NULL pointer
> dereference at virtual address
> Dec 12 00:24:15 santorini kernel: printing eip:
> Dec 12 00:24:15 santorini kernel:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> 2.6.24-rc4-git5, got this cpufreq crash on x86 64-bit, during 'make
> randconfig' random bootup testing:
hm, does not seem to be easily reproducible. I tried 10 bootups and 2 of
them failed.
Ingo
--
To unsubscribe from this list: send the
On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to port
> 0x80 takes. It measures in CPU cycles so CPU speed is
On Tue, Dec 11 2007 at 18:33 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
>> OK, thanks. I'll assume that James and Hannes have this in hand (or will
>> have, by mid-week) and I won't do anything here.
>
> Just to confirm what I
On Mon, 03 Dec 2007 17:59:59 + Steve Hardy <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Here is a patch against 2.6.23.9 which adds support for the
> Burr-Brown/Texas-Instruments
> ADS7828 12-bit 8-channel A-D converter.
>
> The chip is used for voltage monitoring on the COTS processor card I am
>
On Wed, 2007-12-12 at 00:31 +0100, Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to port
> 0x80 takes. It measures in CPU cycles so CPU speed is crucial in
* Kevin Hilman <[EMAIL PROTECTED]> wrote:
> Add unlocked version for use by irq_chip.set_type handlers which may
> wish to change handler to level or edge handler when IRQ type is
> changed.
>
> The normal set_irq_handler() call cannot be used because it tries to
> take irq_desc.lock which
min_sched_granularity_ns, max_sched_granularity_ns, min_wakeup_granularity_ns
and max_wakeup_granularity_ns are declared "unsigned long".
This is incorrect since proc_dointvec_minmax() expects plain "int" guard values.
This bug only triggers on big endian 64 bit arches.
Signed-off-by: Eric
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> hm. Could be some platform thing. Strange. It might be worth checking
> around that ioremap, make sure that the value which it returned is the one
> which is being used in the function-which-hangs, etc.
OK, not difficult to try. (This is x86,
The ->cap fields of struct acpi_video_device and struct acpi_video_bus
are 1B each, not 4B. The oversized memset()'s corrupted the subsequent
list_head fields. This resulted in silent corruption without
CONFIG_DEBUG_LIST and BUG's with it. This patch uses sizeof() to pass
the proper bounds to the
On Tue, Dec 11, 2007 at 05:08:59PM -0700, Bjorn Helgaas wrote:
> On Tuesday 11 December 2007 01:52:55 pm Borislav Petkov wrote:
> > From what i can roughly tell so far it seems like an resource conflict
> > between acpi and
> > the pnp requested regions in your patch which result in the
On 14:47 Mon 10 Dec , Evgeniy Polyakov wrote:
>
> Algorithms used in distributed storage.
> Mirror and linear mapping code.
Hi, i've finally take a look on your DST solution.
It seems what your current implementation will not work on nonstandard
devices for example software raid0.
other
On Wed, 12 Dec 2007 08:56:44 + (GMT) Chris Rankin <[EMAIL PROTECTED]> wrote:
> --- Andrew Morton <[EMAIL PROTECTED]> wrote:
> > It might be interesting to see what value of `i' is causing it to fall over.
>
> I tried unrolling the loop, but a single byte read for i = 0 is enough to
> lock
* Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch fixes the following section mismatches with
> CONFIG_HOTPLUG=n, CONFIG_HOTPLUG_CPU=y:
thanks, applied.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Dhaval Giani <[EMAIL PROTECTED]> wrote:
>
> > > Hm, how about describing the units here? Can you put "10" in each
> > > file and everyone will get the same share? 100? 1? 1024 seems
> > > like an odd "share" number. Unless there is some
On Wed, Dec 12, 2007 at 12:12:47PM +0300, Dmitry Monakhov ([EMAIL PROTECTED])
wrote:
> On 14:47 Mon 10 Dec , Evgeniy Polyakov wrote:
> >
> > Algorithms used in distributed storage.
> > Mirror and linear mapping code.
> Hi, i've finally take a look on your DST solution.
> It seems what your
On 12/12/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> 2.6.24-rc4-git5, got this cpufreq crash on x86 64-bit, during 'make
> randconfig' random bootup testing:
Ingo, since you already scripted this, maybe you can add
"modprobe everything/rmmod everything" test after successful bootup.
It will
Dear all,
I noticed that on my macbook pro1,1 the bluetooth device is gone after
suspend to ram, i.e.
/usr/sbin/hciconfig -a
normally lists hci0:Type: USB ...
but after suspend does nothing.
Here it does not help to remove the modules and to reload them. Also the
driver reloads without
On Fri, 30 Nov 2007 15:02:43 -0500 Adam Jackson <[EMAIL PROTECTED]> wrote:
> These types define the size of data read from /dev/apm_bios. They
> should not be hidden behind #ifdef __KERNEL__.
Missing info: what are the consequences of this fix? What id broken when
it it not applied?
> ---
>
On Thu, 29 Nov 2007 17:02:22 +0100 Jesper Nilsson <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This patchset contains the differences to add support for the EtraxFS and
> ARTPEC-3 CPUs, both of the CRISv32 family. Both chips can now be compiled
> with minimal configs.
>
> To compile you'll need the
Hi,
I'd like to let you now that my boxes are running a 32-bit kernel, so
the 64-bit-uncleanliness shouldn't apply to my boxes; however,
http://www.miquels.cistron.nl/linux/dpt_i2o-64bit-2.6.23.patch
fixed the issue on my testbox.
I took a clean 2.6.23, applied patch, recompiled the kernel,
Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile
> and run the attached program? This is about testing how long I/O port
> access to port 0x80 takes. It measures in CPU cycles so CPU speed is
> crucial in reporting.
$ cat /proc/cpuinfo
* Eric Dumazet <[EMAIL PROTECTED]> wrote:
> min_sched_granularity_ns, max_sched_granularity_ns,
> min_wakeup_granularity_ns and max_wakeup_granularity_ns are declared
> "unsigned long".
>
> This is incorrect since proc_dointvec_minmax() expects plain "int"
> guard values.
>
> This bug only
* Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> On 12/12/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > 2.6.24-rc4-git5, got this cpufreq crash on x86 64-bit, during 'make
> > randconfig' random bootup testing:
>
> Ingo, since you already scripted this, maybe you can add "modprobe
>
On Wed, 2007-12-12 at 00:20 -0500, Shane wrote:
> In 2.6.24-rc5+, I hit this problem with videobuf_read_start
> not being exported. Patch attached, only compile tested.
>
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CALLscripts/checksyscalls.sh
> CHK
Borislav Petkov wrote:
On Tue, Dec 11, 2007 at 05:08:59PM -0700, Bjorn Helgaas wrote:
On Tuesday 11 December 2007 01:52:55 pm Borislav Petkov wrote:
From what i can roughly tell so far it seems like an resource conflict between
acpi and
the pnp requested regions in your patch which
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > the scariest bit is the adding of cpu_clock() to kernel/printk.c so
> > late in the game, and the anti-recursion code i did there. Maybe
> > because this only affects CONFIG_PRINTK_TIME we could try it even
> > for v2.6.24.
>
> Printk recursion I
Linus,
Please pull from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
master
For the following:
- Re-adds lock safe videobuf_read_start
Cheers,
Mauro.
---
drivers/media/video/videobuf-core.c | 14 +-
1 files changed, 13 insertions(+), 1
Em Qua, 2007-12-12 às 00:20 -0500, Shane escreveu:
> In 2.6.24-rc5+, I hit this problem with videobuf_read_start
> not being exported. Patch attached, only compile tested.
>
> CHK include/linux/version.h
> CHK include/linux/utsrelease.h
> CALLscripts/checksyscalls.sh
> CHK
> Any objections against a later path that changes the exports to the
> general "immediately after the function" convention?
No objections. Please generate against "devel" branch on my -git, since
I did a patch fixing most CodingStyle issues reported by checkpatch.pl.
Several files under /media
- BIO flags bio->bi_rw and REQ flags req->cmd_flags no longer match.
Remove comments and do a proper translation between the 2 systems.
(Please look in ll_rw_blk.c/blk_rq_bio_prep() below if we need more flags)
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
block/ll_rw_blk.c
* Metzger, Markus T <[EMAIL PROTECTED]> wrote:
> Andi suggested to make this a sysctl.
that's just as arbitrary ...
> Would it be safe to drop the artificial limit and let the limit be the
> available memory?
no, that would be a DoS :-/
mlock() is rlimit controlled and is available to
On Fri, 30 Nov 2007 13:59:57 +0100 Jesper Nilsson <[EMAIL PROTECTED]> wrote:
> @@ -360,7 +247,7 @@ do_page_fault(unsigned long address, struct pt_regs *regs,
> up_read(>mmap_sem);
> printk("VM: killing process %s\n", tsk->comm);
> if (user_mode(regs))
> -
On Fri, 30 Nov 2007 15:54:01 +0100 Jesper Nilsson <[EMAIL PROTECTED]> wrote:
> +int
> +i2c_write(unsigned char theSlave, void *data, size_t nbytes)
> +{
> + int error, cntr = 3;
> + unsigned char bytes_wrote = 0;
> + unsigned char value;
> + unsigned long flags;
> +
> +
On Dec 12, 2007 9:48 AM, Jiri Slaby <[EMAIL PROTECTED]> wrote:
> On 12/12/2007 12:31 AM, Rene Herman wrote:
> > Good day.
> >
> > Would some people on x86 (both 32 and 64) be kind enough to compile and
> > run the attached program? This is about testing how long I/O port access
model name :
On Mon, 3 Dec 2007 10:54:15 +0100 Jesper Nilsson <[EMAIL PROTECTED]> wrote:
> - /* Parameter to ret_from_sys_call. 0 is don't restart the syscall. */
> + /* Paramater to ret_from_sys_call. 0 is don't restart the syscall. */
"Parameter".
--
To unsubscribe from this list: send the line
On Thu, 29 Nov 2007 17:03:41 +0100 Jesper Nilsson <[EMAIL PROTECTED]> wrote:
> Adds gpio and nandflash handling for Artpec-3.
>
> ...
>
> +static volatile unsigned long *data_out[NUM_PORTS] = {
all these volatiles really shouldn't be here.
> +static void
> +gpio_set_alarm(struct gpio_private
On Dec 12, 2007 10:16 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> What was wrong with it?
>
Hi,
on loading only one serial port was present and it wasn't working.
After looking in the data sheet I realized that the base address was
wrong. For further reference here is lspci and relevant
On Thu, 29 Nov 2007 17:23:14 +0100 Jesper Nilsson <[EMAIL PROTECTED]> wrote:
> +static void serial_cris_set_mctrl(struct uart_port *port, unsigned int mctrl)
> +{
> + struct uart_cris_port *up = (struct uart_cris_port *)port;
use container_of() here
> +static irqreturn_t
On Fri, 30 Nov 2007 16:22:50 +0100 Jesper Nilsson <[EMAIL PROTECTED]> wrote:
> +#ifdef CONFIG_DEBUG_BUGVERBOSE
> +void
> +handle_BUG(struct pt_regs *regs)
> {
> - asm volatile("setf m");
> + struct bug_frame f;
> + unsigned char c;
> + unsigned long irp = regs->irp;
> +
> + if
On Fri, 30 Nov 2007 17:46:11 +0100 Jesper Nilsson <[EMAIL PROTECTED]> wrote:
> arch/cris/arch-v32/kernel/fasttimer.c | 519
I'm suspecting that most of the inlines which this patch retains are
deoptimising the code.
This file still seems to use two-spaces for
On Wed, 12 Dec 2007 11:58:41 +0100 Anders Henke <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'd like to let you now that my boxes are running a 32-bit kernel, so
> the 64-bit-uncleanliness shouldn't apply to my boxes; however,
>
> http://www.miquels.cistron.nl/linux/dpt_i2o-64bit-2.6.23.patch
>
>
On Wed, Dec 12 2007, Boaz Harrosh wrote:
> On Tue, Dec 11 2007 at 18:33 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
> > On Mon, 2007-11-26 at 22:15 -0800, Andrew Morton wrote:
> >> OK, thanks. I'll assume that James and Hannes have this in hand (or will
> >> have, by mid-week) and I won't
William Lee Irwin III writes:
> The ->cap fields of struct acpi_video_device and struct acpi_video_bus
> are 1B each, not 4B. The oversized memset()'s corrupted the subsequent
> list_head fields. This resulted in silent corruption without
> CONFIG_DEBUG_LIST and BUG's with it. This patch uses
Am Mittwoch, 12. Dezember 2007 11:31:57 schrieb Soeren Sonnenburg:
> Dear all,
>
> I noticed that on my macbook pro1,1 the bluetooth device is gone after
> suspend to ram, i.e.
Is this a regression?
Does it work if you unload hci_usb before you suspend?
If so, please recompile with
Hi,
thank you for your extensive review, I will fix and resubmitt. Anyway
I learned an important lesson: checkpatch.pl will be my best friend.
Sorry I haven't read about it earlier.
Just a question:
>
> > +/*
> > + *
> > + * Copyright (C) 2007 Christian Pellegrin
> > + *
> > + * This program
El Wed, 12 Dec 2007 01:16:06 +0100
Rene Herman <[EMAIL PROTECTED]> escribió:
> On 12-12-07 01:09, Alejandro Riveira Fernández wrote:
[...]
>
> Great, thanks much for reporting. Sort of interesting in itself that without
> -O2 you do still get correct results on 64-bit but for some other time.
Here are a variety of machines:
600 MHz PIII (Katmai), 440BX chipset, 82371AB/EB/MB PIIX4 ISA bridge:
cycles: out 794, in 348
cycles: out 791, in 348
cycles: out 791, in 349
cycles: out 791, in 348
cycles: out 791, in 348
433 MHz Celeron (Mendocino), 440 BX chipset, same ISA bridge:
cycles: out
On Mon, 3 Dec 2007 11:16:25 +0100 Jesper Nilsson <[EMAIL PROTECTED]> wrote:
> - Shorten include paths for machine dependent header files.
> - Add volatile to hardeware register pointers.
> - Add spinlocks around critical region.
> - Expand macros for handling of leds.
>
> ...
>
> struct
Hi!
We have strange problem with Celeron on i810 mainboards here: machine
reproducibly hangs in test 8 from memtest, and randomly hangs running
linux. (Problem is not bad RAM, not bad powersupply, and not related
to powersaving).
It seems that heavy memory traffic just makes it hang, as soon as
On Tue, 4 Dec 2007 17:25:45 +0100 Jesper Nilsson <[EMAIL PROTECTED]> wrote:
> +#ifdef CONFIG_CPU_FREQ
> + cpufreq_register_notifier(_time_freq_notifier_block,
> + CPUFREQ_TRANSITION_NOTIFIER);
> #endif
include/linux/cpufreq.h has
#ifdef CONFIG_CPU_FREQ
...
#else /*
On Thu, 29 Nov 2007 10:42:49 +0900 "Joonwoo Park" <[EMAIL PROTECTED]> wrote:
> 2007/11/29, Zhu Yi <[EMAIL PROTECTED]>:
> >
> > Good catch. But it will be better if you add it into
> > iwl_cancel_deferred_work().
> >
>
> Thanks.
> I agree with you.
> Actually, I considered it, but I was afraid
On Wed, Dec 12, 2007 at 12:48:09PM +0100, Mikael Pettersson wrote:
> IMO the memset(ptr, 0, sizeof(*ptr)) idiom is both safer
> and avoids having to write an uninteresting type name.
How about this, then?
The ->cap fields of struct acpi_video_device and struct acpi_video_bus
are 1B each, not 4B.
On Wed, Dec 12, 2007 at 09:03:14AM -0200, Mauro Carvalho Chehab wrote:
>...
> I'm afraid that this wouldn't avoid this bug, however.
>
> The removal of the EXPORT_SYMBOL_GPL seemed to be the intention of
> Brandon, since he renamed the function, removing the locks. I think he
> didn't noticed
On Tue, Dec 11 2007, Kiyoshi Ueda wrote:
> Hi Jens, Boaz,
>
> The following is the updated patch-set for blk_end_request().
> I have done some interface/implementation changes based on
> feedbacks/discussions since the previous version.
> (Although this patch-set was made on top of 2.6.24-rc4, I
William Lee Irwin III writes:
> On Wed, Dec 12, 2007 at 12:48:09PM +0100, Mikael Pettersson wrote:
> > IMO the memset(ptr, 0, sizeof(*ptr)) idiom is both safer
> > and avoids having to write an uninteresting type name.
>
> How about this, then?
Looks good.
Acked-by: Mikael Pettersson
On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
> Good day.
>
> Would some people on x86 (both 32 and 64) be kind enough to compile and run
> the attached program? This is about testing how long I/O port access to
> port 0x80 takes. It measures in CPU cycles so CPU speed is crucial
Joachim Fenkes wrote:
Roland Dreier <[EMAIL PROTECTED]> wrote on 10.12.2007 22:47:37:
It's an optional device feature, so this should be OK
(although the iSER driver currently seems to depend on a device
supporting FMRs, which is probably going to be a problem with iWARP
support in the future
>-Original Message-
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>Sent: Mittwoch, 12. Dezember 2007 12:04
>> Would it be safe to drop the artificial limit and let the
>limit be the
>> available memory?
>
>no, that would be a DoS :-/
How about:
for (;;) {
int pid = fork();
On 12 Dec 2007 06:20:49 -0500
[EMAIL PROTECTED] wrote:
> With -O2, the cycle counts come out (before division) as
> out: 0xFFEA6F4F
> in: 0xFCE68BB6
> I think the "A" constraint doesn't work quite the same in
> 64-bit code. The compiler seems to be using %rdx rather than
>
On Tue, 2007-12-11 at 17:40 -0500, Kiyoshi Ueda wrote:
> This patch adds 2 new interfaces for request completion:
> o blk_end_request() : called without queue lock
> o __blk_end_request() : called with queue lock held
>
> blk_end_request takes 'error' as an argument instead of 'uptodate',
Hi,
Oleksandr Natalenko <[EMAIL PROTECTED]> writes:
> And... Linus, why do yo make mistakes in headers of announces :)? Not first
> time.
This is the effect of a plugin for the Linus-bot written in Lisp. It's
an output-scrambler that makes him act more human.
Hannes
--
To unsubscribe
On Tue, 2007-12-11 at 17:11 -0500, Jie Chen wrote:
> Ingo Molnar wrote:
> > * Jie Chen <[EMAIL PROTECTED]> wrote:
> >
> >> The following is pthread_sync output for 2.6.21.7-cfs-v24 #1 SMP
> >> kernel.
> >
> >> 2 threads:
> >
> >> PARALLEL time = 11.106580 microseconds +/- 0.002460
> >>
On Tue, 2007-12-11 at 17:52 -0500, Kiyoshi Ueda wrote:
> This patch converts scsi mid-layer to use blk_end_request interfaces.
> Related 'uptodate' arguments are converted to 'error'.
>
> As a result, the interface of internal function, scsi_end_request(),
> is changed.
This looks fine, as far
> -Message d'origine-
> De : Dhaval Giani [mailto:[EMAIL PROTECTED]
>
> On Tue, Dec 11, 2007 at 10:06:53PM +0100, Ingo Molnar wrote:
> >
> > * Fortier,Vincent [Montreal] <[EMAIL PROTECTED]> wrote:
> >
> > > > That has changed from /sys/kernel/uids//cpu_share
> > >
> > > Here is my
Can anyone help with this ? This seems to be a true SMP bug - the same
kernel on another UP machine is working fine (although different h/w).
Seems like stress (find for example) can easily trigger this. Does it
look like i have a bad filesystem ? Can anyone help me figure out which
one ? The
On Wed, 2007-12-12 at 03:38 -0800, Andrew Morton wrote:
> On Wed, 12 Dec 2007 11:58:41 +0100 Anders Henke <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I'd like to let you now that my boxes are running a 32-bit kernel, so
> > the 64-bit-uncleanliness shouldn't apply to my boxes; however,
> >
> >
On 12-12-07 13:59, linux-os (Dick Johnson) wrote:
On Tue, 11 Dec 2007, [utf-8] Alejandro Riveira Fern?ndez wrote:
On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:
cycles: out 1844674407370808, in 1844674407369087
It is not constant but variations are not significant afaics
It
On Wed, 12 Dec 2007, Rene Herman wrote:
> On 12-12-07 13:59, linux-os (Dick Johnson) wrote:
>
>> On Tue, 11 Dec 2007, [utf-8] Alejandro Riveira Fern?ndez wrote:
>
>>> On my AMD 3800 X2 (2000MHz) ULi M1697 2.6.24-rc5 i get:
>>>
>>> cycles: out 1844674407370808, in 1844674407369087
>>>
>>> It is
On Tue, 11 Dec 2007, David P. Reed wrote:
> 1) I found in a book, the Undocumented PC, that I have lying around that
> the "pause" recommended for some old adapter chips on the ISA bus was 1
> usec. The book carefully points out on various models of PCs how many
> short jumps are required to
Hi Linus,
Please pull the i2c subsystem fixes for Linux 2.6.24 from:
git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
Documentation/i2c/summary| 45 +++--
drivers/i2c/busses/i2c-davinci.c |4 +-
drivers/i2c/busses/i2c-gpio.c|1 +
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] De la part de
> Fortier,Vincent [Montreal]
>
> > -Message d'origine-
> > De : Dhaval Giani [mailto:[EMAIL PROTECTED]
> >
> > On Tue, Dec 11, 2007 at 10:06:53PM +0100, Ingo Molnar wrote:
> > >
> > > *
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Hello *,
maybe it's my bad. Most probably! Even in that case I'd need someone to
point out the mistake to me!
I'm currently (trying) to write a transparent proxy application, using
libipq to capture packets + iptables' redirect mechanism.
The
ACK, patch looks good. Thanks for composing this patch. Glad to hear of
successful test results.
Sincerely -- Mark Salyzyn
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Miquel
> van Smoorenburg
. . .
>
> I just recompiled 2.6.23.9 with the 64
On Wed, Dec 12, 2007 at 03:17:13AM -0800, Andrew Morton wrote:
> On Fri, 30 Nov 2007 13:59:57 +0100 Jesper Nilsson <[EMAIL PROTECTED]> wrote:
>
> > @@ -360,7 +247,7 @@ do_page_fault(unsigned long address, struct pt_regs
> > *regs,
> > up_read(>mmap_sem);
> > printk("VM: killing process
Toralf Förster wrote:
> Hello,
>
> the build with the attached .config failed, make ends with:
> ...
> GZIParch/x86/boot/compressed/vmlinux.bin.gz
> LD arch/x86/boot/compressed/piggy.o
> LD arch/x86/boot/compressed/vmlinux
> OBJCOPY arch/x86/boot/vmlinux.bin
> HOSTCC
On Wed, Dec 12, 2007 at 07:57:33AM -0500, Fortier,Vincent [Montreal] wrote:
> > -Message d'origine-
> > De : Dhaval Giani [mailto:[EMAIL PROTECTED]
> >
> > On Tue, Dec 11, 2007 at 10:06:53PM +0100, Ingo Molnar wrote:
> > >
> > > * Fortier,Vincent [Montreal] <[EMAIL PROTECTED]> wrote:
>
Am 12.12.2007 schrieb Miquel van Smoorenburg:
> On Wed, 2007-12-12 at 03:38 -0800, Andrew Morton wrote:
> > On Wed, 12 Dec 2007 11:58:41 +0100 Anders Henke <[EMAIL PROTECTED]> wrote:
> >
> > > Hi,
> > >
> > > I'd like to let you now that my boxes are running a 32-bit kernel, so
> > > the
On Wed, Dec 12, 2007 at 02:28:42PM +0100, Adrian Bunk wrote:
> On Wed, Dec 12, 2007 at 02:52:12AM -0800, Andrew Morton wrote:
> > On Thu, 29 Nov 2007 17:02:22 +0100 Jesper Nilsson <[EMAIL PROTECTED]> wrote:
> > > The changes are also available in the export2 branch at
> > >
> > >
On Wed, Dec 12, 2007 at 02:52:12AM -0800, Andrew Morton wrote:
> > ...
> > The changes are also available in the export2 branch at
> >
> > git://www.jni.nu/axis.git
> >
>
> I don't think there's much point in me merging these. Please ask Linus to
> pull that tree once the 2.6.25 merge window
On Wed, Dec 12, 2007 at 02:52:12AM -0800, Andrew Morton wrote:
> On Thu, 29 Nov 2007 17:02:22 +0100 Jesper Nilsson <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > This patchset contains the differences to add support for the EtraxFS and
> > ARTPEC-3 CPUs, both of the CRISv32 family. Both chips can
On Tue, 11 Dec 2007, Krzysztof Oledzki wrote:
On Wed, 5 Dec 2007, Krzysztof Oledzki wrote:
On Wed, 5 Dec 2007, [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9182
--- Comment #20 from [EMAIL PROTECTED] 2007-12-05 13:37 ---
Please monitor the "Dirty:"
Hi Stephen,
On Oct 23, 2007 2:55 PM, Stephen Hemminger
<[EMAIL PROTECTED]> wrote:
> +static void mail_led_set(struct led_classdev *led,
> +enum led_brightness value)
> +{
> + struct apanel *ap = container_of(led, struct apanel, mail_led);
> + if (value)
> +
Am 12.12.2007 schrieb Andrew Morton:
> On Wed, 12 Dec 2007 11:58:41 +0100 Anders Henke <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I'd like to let you now that my boxes are running a 32-bit kernel, so
> > the 64-bit-uncleanliness shouldn't apply to my boxes; however,
> >
> >
> + htcfg = read_pci_config(num, slot, func, 0x68);
> + if (htcfg & (1 << 18)) {
> + printk(KERN_INFO "Detected use of extended apic ids on
> hypertransport bus\n");
> + if ((htcfg & (1 << 17)) == 0) {
> + printk(KERN_INFO "Enabling
601 - 700 of 1182 matches
Mail list logo
