* Arjan van de Ven:
>> No amount of carefulness will prevent vendors stick arbitrarily
>> damaging values of stack and mmap base randomisation, severely reducing
>> the usefullness of MAP_FIXED.
>
> MAP_FIXED is useful still. The only safe way is to use addresses you got
> from mmap(), eg you over
2007/2/1, bibo,mao <[EMAIL PROTECTED]>:
currently x86_64 kernel does not support efi, efi convention comply to
MS convention. On ia32 parameter is passed on stack, on x86_64 parameter
is passed by registers but that is different from x86_64 linux convention.
Is an x86_64 EFI firmware required t
Jon Masters has taken over upstream maintainership of module-init-tools from
Rusty, update MAINTAINERS file to reflect this change and to provide
information about the location of new releases and the mailing list.
Signed-off-by: Jon Masters <[EMAIL PROTECTED]>
---
MAINTAINERS |7 ---
1
On Wed, Jan 31, 2007 at 11:17:31PM -0800, Andrew Morton wrote:
> On Thu, 01 Feb 2007 01:28:59 -0500 Jon Masters <[EMAIL PROTECTED]> wrote:
> > I took over upstream maintainership of the module-init-tools package
> > from Rusty at the end of last year.
> Cool. A patch to the kernel's ./MAINTAINER
* Paul E. McKenney <[EMAIL PROTECTED]> wrote:
> Here is the RCU priority-boosting patch. Pretty close to the
> http://lkml.org/lkml/2007/1/24/295 version. This patch prevents
> preempted or blocked low-priority RCU readers from indefinitely
> stalling RCU grace periods.
thanks - i've applie
On Thu, 1 Feb 2007 08:10:36 + Jon Masters <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 31, 2007 at 11:17:31PM -0800, Andrew Morton wrote:
> > On Thu, 01 Feb 2007 01:28:59 -0500 Jon Masters <[EMAIL PROTECTED]> wrote:
> > > I took over upstream maintainership of the module-init-tools package
> > >
* Zach Brown <[EMAIL PROTECTED]> wrote:
> This patch introduces the notion of a 'fibril'. It's meant to be a
> lighter kernel thread. [...]
as per my other email, i dont really like this concept. This is the
killer:
> [...] There can be multiple of them in the process of executing for a
>
ping!
Pierre Ossman wrote:
> Ok... how about this baby instead. I've replaced the stack allocated
> request structure by one allocated with kmalloc() and reference counted
> using an atomic_t. I couldn't see anything else that was associated to
> the process, so I believe this should suffice.
>
>
Le Jeu 1 février 2007 00:44, Greg KH a écrit :
> On Wed, Jan 31, 2007 at 06:00:15PM -0500, Theodore Tso wrote:
>> More specifically, Dave said that it "seemed rude" to just take the
>> driver and send updates, but maybe the best way of dealing with
>> out-of-tree drivers like lirc is to treat the
I accidentally ran two qemu instances on the same ext3 fs, after that bad
things happened. After exiting the two qemus and running a new one, I got the
following oops:
root ~# ll /etc/mtab
/bin/ls: /etc/mtab: Input/output error
root ~# rm /etc/mtab
[ 147.213090] EXT3-fs warning (device hda): ext3
Andrew Morton wrote:
No, I was thinking of a record which explicitly mentions module-init-tools.
It's not a part of the kernel, but it is closely connected to it, and this is
useful information to have in ./MAINTAINERS.
Ah, now that makes more sense. I was thinking you were thinking of an
exi
On 2/1/07, Nicolas Mailhot <[EMAIL PROTECTED]> wrote:
Well, reengineering nvidia/ati DRM is rude to ati/nvidia, so was creating
tigon3, so was rewriting from scratch the GPL drivers some ATA vendors
published in the past, so was spurning the SATA/SAS stack adaptec
offered...
It is rude, but the
* Karsten Wiese <[EMAIL PROTECTED]> wrote:
> Serial port console is off here and the jiffies update fix doesn't
> make a noticeable difference.
ok, this eliminates my serial port theory.
and this means i'm having trouble reproducing this problem locally.
Maybe i tried it the wrong way: does i
Hello,
On Fri, Jan 26, 2007 at 09:49:54AM -0800, H. Peter Anvin wrote:
> >
> >I ran into compiler warnings with the perfmon code when I tried
> >using test() and __set_bit() on i386.
> >
> >For some reason, the i386 bitops functions use unsigned long * for
> >the address whereas x86-64/ia64 use v
Le Jeu 1 février 2007 10:03, Trent Waddington a écrit :
> On 2/1/07, Nicolas Mailhot <[EMAIL PROTECTED]> wrote:
>> Well, reengineering nvidia/ati DRM is rude to ati/nvidia, so was
>> creating
>> tigon3, so was rewriting from scratch the GPL drivers some ATA vendors
>> published in the past, so was
On 2/1/07, Nicolas Mailhot <[EMAIL PROTECTED]> wrote:
Not all of them.
It seems it's kosher to rewrite a corp GPL driver but not a "community" one.
As I said, Greg didn't say it was rude to write a new driver without consulting
the author of an existing driver.. corp *or* community.. so who sai
Hi Andrew,
here is the latest rework of the aio notification and listio support
patches with comments from Oleg Nesterov and you addressed.
Sébastien.
This set now consists in 7 patches:
1. rework-compat-sys-io-submit: cleanup the sys_io_submit() compat
layer,
makin
From: Sébastien Dugué <[EMAIL PROTECTED]>
Make good_sigevent() non-static and rename it
Move good_sigevent() from posix-timers.c to signal.c where it belongs,
clean it up, rename it to sigevent_find_task() to better describe what the
function does and make it non-static so tha
From: Sébastien Dugué <[EMAIL PROTECTED]>
compat_sys_io_submit() cleanup
Cleanup compat_sys_io_submit by duplicating some of the native syscall
logic in the compat layer and directly calling io_submit_one() instead
of fooling the syscall into thinking it is called from a nati
From: Bharata B Rao <[EMAIL PROTECTED]>
This patch provides POSIX listio support by means of a new system call.
long lio_submit(aio_context_t ctx_id, int mode, long nr,
struct iocb __user * __user *iocbpp, struct sigevent __user *event)
This system call is similar to the io_submit() sys
From: Sébastien Dugué <[EMAIL PROTECTED]>
AIO completion signal notification
The current 2.6 kernel does not support notification of user space via
an RT signal upon an asynchronous IO completion. The POSIX specification
states that when an AIO request completes, a signal
From: Sébastien Dugué <[EMAIL PROTECTED]>
Fix the double inclusion of linux/uio.h in linux/aio.h
aio.h |1 -
1 file changed, 1 deletion(-)
Signed-off-by: Sébastien Dugué <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc6-mm3/include/linux/aio.h
===
From: Sébastien Dugué <[EMAIL PROTECTED]>
Make __sigqueue_alloc() and __sigqueue_free() non static
Allow subsystems to directly call into __sigqueue_alloc() and __sigqueue_free.
This is used by the AIO signal notification patch.
include/linux/signal.h |3 +++
kernel/signal.
From: Sébastien Dugué <[EMAIL PROTECTED]>
Fix access_ok() checks in sys_io_submit() and
compat_sys_io_submit()
sys_io_submit() and compat_sys_io_submit() check for the number of
requests (nr) being positive, but the following access_ok() call us
unsubscribe linux-kernel
-
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 Tue, Jan 30, 2007 at 10:00:55AM +0900, Paul Mundt wrote:
> However, it has since been reposted:
>
> http://article.gmane.org/gmane.linux.kernel/485833
> http://article.gmane.org/gmane.linux.kernel/485834
> http://article.gmane.org/gmane.linux.kernel/485835
> http://article.gmane.org/gmane.linu
On Thursday 1 February 2007 00:39:14 you wrote:
> On Tue, 30 Jan 2007 21:30:29 +
> Simon Arlott <[EMAIL PROTECTED]> wrote:
>
> > +static int cxacru_proc_read(struct usbatm_data *usbatm_instance,
> > + struct atm_dev *atm_dev, loff_t * pos, char *page)
> > +{
> > + struct cxacru_data *insta
Lee Revell wrote:
On 1/31/07, Mark Lord <[EMAIL PROTECTED]> wrote:
I believe a BIG reason why lots of open-source drivers are out-of-tree
right now, is because lkml is perceived as being wayy too fussy
and petty about 80-column lines, brackets, etc.. for new code.
It's just not worth the ef
[ Same player shoot again. Fix address. ]
Ingo Molnar wrote:
John wrote:
John Stultz wrote:
Also do check the -rt tree as Ingo suggested. I mis-read your earlier
email and thought you were running it.
I've been pulling my hair over a related issue for the past two days.
(I think I may be
> I don't understand how this is supposed to work. Consider
>
> CPU1 CPU2
>
> atomic_inc(&dp->pde_users);
> if (dp->proc_fops)
> de->proc_fops = NULL;
> use_proc_fops <= BOOM
> if (
Nick Piggin <[EMAIL PROTECTED]> wrote:
> > + * Determine whether some value is a power of two, where zero is
> > + * *not* considered a power of two.
> > + */
>
> Why the qualifier? Zero *is* not a power of 2, is it?
The qualifier is worth leaving in the comment, just so that people who want to
Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> +#define is_power_of_4(x) is_power_of_2(x) && (ffs(x) & 1))
If this is such a commonly implemented op, it should probably be implemented
globally too.
I also wonder if there's some better way of implementing it than this, but I
can't think of on
On Thu, 1 Feb 2007, David Howells wrote:
>
> Robert P. J. Day <[EMAIL PROTECTED]> wrote:
>
> > +#define is_power_of_4(x) is_power_of_2(x) && (ffs(x) & 1))
>
> If this is such a commonly implemented op, it should probably be implemented
> globally too.
there are only two checks of the form "is_p
On Wed, Jan 31, 2007 at 11:23:39AM -0800, Zach Brown wrote:
> On Jan 31, 2007, at 9:21 AM, Andi Kleen wrote:
>
> >On Wednesday 31 January 2007 18:15, Zach Brown wrote:
> >>
> >>On Jan 31, 2007, at 12:58 AM, Andi Kleen wrote:
> >>
> >>>Do you have any numbers how this compares cycle wise to just do
Fix a race in the initialization of HPET, which might result in a
5 minute lockup on boot.
Signed-off-by: Jiri Bohac <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc5/arch/x86_64/kernel/apic.c
===
--- linux-2.6.20-rc5.orig/arch/x86_64/ker
TSC-based x86_64 timekeeping implementation
===
by Vojtech Pavlik and Jiri Bohac
This implementation allows the current time to be approximated by reading the
CPU's TSC even on SMP machines with unsynchronised TSCs. This allows us to
have a very fast gettime
VXTIME_HPET will be replaced by a more generic "Master Timer"
Signed-off-by: Jiri Bohac <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc5/arch/x86_64/kernel/time.c
===
--- linux-2.6.20-rc5.orig/arch/x86_64/kernel/time.c
+++ linux-2.6.20-rc5
VXTIME_PMTMR will be replaced by a more generic "Master Timer"
Signed-off-by: Jiri Bohac <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc5/arch/x86_64/kernel/apic.c
===
--- linux-2.6.20-rc5.orig/arch/x86_64/kernel/apic.c
+++ linux-2.6.20-r
TSC is either synchronized by design or not reliable
to be used for anything, let alone timekeeping.
Signed-off-by: Jiri Bohac <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc5/arch/x86_64/kernel/smpboot.c
===
--- linux-2.6.20-rc5.orig/arc
Master Timer (MT) is a reliable, monotonic, constantly growing 64 bit timer. At
present, PM timer or HPET can be used as the Master Timer.
None of them is 64 bit (HPET migt be, but not always), so we access them
through the get_master_timer64() and update_master_timer64() functions
that take care
time_update_mt_guess() is the core of the TSC->MT approximation magic.
Called periodically from the LAPIC timer interrupt handler, it fine-tunes
all the per-CPU offsets and ratios needed by guess_mt() to approximate the
MT using any processor's TSC.
We also need to update these from the cpufreq
Make use of the whole Master Timer infrastructure in gettimeofday,
monotonic_clock, etc.
Also make the vsyscall version of gettimeofday use the guess_mt() if
possible.
Signed-off-by: Jiri Bohac <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc5/arch/x86_64/kernel/time.c
===
Hello
On Wednesday 31 January 2007 10:02, Adrian Bunk wrote:
> On Tue, Jan 30, 2007 at 06:36:48PM -0800, Linus Torvalds wrote:
> >
> >
> > On Tue, 30 Jan 2007, Mark Lord wrote:
> > >
> > > I believe our featherless leader said he though it was an ancient bug,
> > > exasperated by something that
On Wed, 2007-01-31 at 22:20 -0600, Robert Hancock wrote:
> It seems pretty unlikely that telling a hard drive to seek past its
> capacity would cause it to damage itself, that would be some pretty
> moronic firmware. Though, you never know - if it's true, let me know
> what kind of drives these
The TSC-based Master Timer approximation code will need a couple of
per-CPU offsets and coefficients to approximate the value of a hardware
"Master Timer" based on the value of TSC on whichever CPU it will be
running.
We want to be able to do these approximations in a vsyscall, so we need
all this
We need to:
- initialize the RDTSCP instruction if available
- decide which hardware timer to use as MT (PM or HPET)
- decide what level of TSC->MT approximation to use
- none (as slow as the hardware MT can get) -- "notsc" option
- strictly monotonic (can't be done in a vsyscall) -- defau
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> This implementation allows the current time to be approximated by
> reading the CPU's TSC even on SMP machines with unsynchronised TSCs.
> This allows us to have a very fast gettimeofday() vsyscall on all SMP
> machines supporting the RDTSCP ins
>
> -unsigned int cpu_khz;/* TSC clocks /
> usec, not used here */
> +unsigned int cpu_khz;/* TSC clocks / usec, not used here */
> +static s64 mt_per_tick; /* master timer ticks per jiffie */
> +static u64 __mt; /
> +extern void time_initialize_cpu(void);
Never put externs into .c files. Multiple occurrences.
> +void time_initialize_cpu(void *info)
> +{
> + unsigned long flags;
> + int cpu = smp_processor_id();
Are you sure this can never preempt?
> + /* FIXME: what speed does the cpu real
On Thursday 01 February 2007 11:00, [EMAIL PROTECTED] wrote:
> + case VXTIME_TSC:
> + rdtscll(tsc);
Where is the CPU synchronization?
> + cpu = smp_processor_id();
> + rdtscll(t);
Also no synchronization. It's slower, but needed.
> unsigned long long s
On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
>
> Inter-CPU monotonicity can not, however, be guaranteed in a vsyscall, so
> vsyscall is not used by default.
Only for unsynchronized machines I hope
> Still, the syscall version of gettimeofday is
> a lot faster using the TSC app
On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
> struct vxtime_data {
> + union {
> + struct {
> + u64 tsc_slope; /* TSC to MT coefficient */
> + u64 tsc_slope_avg; /* average tsc_slope */
> + u
On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
> VXTIME_PMTMR will be replaced by a more generic "Master Timer"
This means we have no fallback if something goes wrong with the Master timer?
A little risky.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
> TSC is either synchronized by design or not reliable
> to be used for anything, let alone timekeeping.
In my tree this is already done better by a patch from Ingo.
Check if they look synchronized and don't use TSC if they are not.
-An
On Thursday 01 February 2007 11:00, [EMAIL PROTECTED] wrote:
> Index: linux-2.6.20-rc5/arch/x86_64/kernel/apic.c
> ===
> --- linux-2.6.20-rc5.orig/arch/x86_64/kernel/apic.c
> +++ linux-2.6.20-rc5/arch/x86_64/kernel/apic.c
> @@ -63,6 +
On Thu, Feb 01, 2007 at 10:33:40AM +0800, Aubrey Li wrote:
> On 2/1/07, Alan <[EMAIL PROTECTED]> wrote:
> >What code is running on that console at the time. Most likely that user
> >code is also saving/restoring terminal settings so overwrite yours
> >
>
> I implemented the serial driver by myself
On 2/1/07, Russell King <[EMAIL PROTECTED]> wrote:
On Thu, Feb 01, 2007 at 10:33:40AM +0800, Aubrey Li wrote:
> On 2/1/07, Alan <[EMAIL PROTECTED]> wrote:
> >What code is running on that console at the time. Most likely that user
> >code is also saving/restoring terminal settings so overwrite you
On 2/1/07, Tosoni <[EMAIL PROTECTED]> wrote:
If I understand Alan'answer correctly:
You appear to use a *shell* on that console. The shell gets your ENTER key
and in the succeeding processing the shell resets the crtscts flag to what
the shell thinks is right for him.
The shell must make some t
Am Donnerstag, 1. Februar 2007 09:01 schrieb Ingo Molnar:
>
> and this means i'm having trouble reproducing this problem locally.
> Maybe i tried it the wrong way: does it only occur with suspend-to-disk,
> or suspend-to-ram too? Does it need ACPI suspend-to-disk, or
> software-suspend?
Haven'
Am Donnerstag, 1. Februar 2007 11:44 schrieb Karsten Wiese:
> I think the wait is caused by an interrupt starting somewhere under
> sysdev_resume(void).
> possibly lapic timer interrupt? Will try to trace that.
Some evidence:
[EMAIL PROTECTED] Desktop]# echo reboot > /sys/power/disk
[EMAIL PROTECT
On Thu, Feb 01, 2007 at 06:09:24PM +0800, Aubrey Li wrote:
> On 2/1/07, Russell King <[EMAIL PROTECTED]> wrote:
> >On Thu, Feb 01, 2007 at 10:33:40AM +0800, Aubrey Li wrote:
> >> On 2/1/07, Alan <[EMAIL PROTECTED]> wrote:
> >> >What code is running on that console at the time. Most likely that user
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > Must it be able to sleep?
>
> Not as David was using it
It absolutely *must* be able to sleep. It has to wait for FS-Cache to finish
writing the page to the cache before letting the PTE be made writable.
David
-
To unsubscribe from this list: send th
On Jan 31 2007 18:59, Lee Revell wrote:
> On 1/31/07, Theodore Tso <[EMAIL PROTECTED]> wrote:
>>
>> More specifically, Dave said that it "seemed rude" to just take the
>> driver and send updates, but maybe the best way of dealing with
>> out-of-tree drivers like lirc is to treat the out-of-tree dr
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Inter-CPU monotonicity can not, however, be guaranteed in a vsyscall,
> so vsyscall is not used by default. [...]
note that this is not actually the case. My patch below, ontop of -mm,
implements a fully monotonic gettimeofday as an optional vsy
On Thu, Feb 01, 2007 at 12:20:59PM +0100, Andi Kleen wrote:
> I think a better way to do this would be to define a new
> CLOCK_THREAD_MONOTONOUS
> (or better name) timer for clock_gettime().
>
> [and my currently stalled vdso patches that implement clock_gettime
> as a vsyscall]
>
> Then also a
On Thursday 01 February 2007 12:53, Andrea Arcangeli wrote:
> On Thu, Feb 01, 2007 at 12:20:59PM +0100, Andi Kleen wrote:
> > I think a better way to do this would be to define a new
> > CLOCK_THREAD_MONOTONOUS
> > (or better name) timer for clock_gettime().
> >
> > [and my currently stalled vds
On Thursday 01 February 2007 12:46, Ingo Molnar wrote:
>
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > Inter-CPU monotonicity can not, however, be guaranteed in a vsyscall,
> > so vsyscall is not used by default. [...]
>
> note that this is not actually the case. My patch below, ontop
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > The 'price' paid for it is lower resolution - but it's still good
> > for those benchmarking TPC-C runs - and /alot/ simpler. It's also
> > quite a bit faster than any TSC based vgettimeofday, because it
> > doesnt have to do an RDTSC (or RDTSCP) ins
On Thursday 01 February 2007 12:46, Ingo Molnar wrote:
>
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > Inter-CPU monotonicity can not, however, be guaranteed in a vsyscall,
> > so vsyscall is not used by default. [...]
>
> note that this is not actually the case. My patch below, ontop
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> The big strategic problem is how to marry your patchkit to John
> Stultz's clocksources work which is also competing for merge. Any
> thoughts on that?
the only sane thing would be to do it ontop of -mm: the stuff in -mm,
barring some catastrophy, is
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > The 'price' paid for it is lower resolution - but it's still good
> > for those benchmarking TPC-C runs - and /alot/ simpler.
>
> BTW another comment: I was told that at least one of the big databases
> wants ms resolution here. So to make your schem
On Thu, 1 Feb 2007, David Howells wrote:
> Robert P. J. Day <[EMAIL PROTECTED]> wrote:
>
> > +#define is_power_of_4(x) is_power_of_2(x) && (ffs(x) & 1))
>
> If this is such a commonly implemented op, it should probably be implemented
> globally too.
>
> I also wonder if there's some better way
On Thursday 01 February 2007 13:24, Ingo Molnar wrote:
> if resolution is an issue then i can improve this thing to be based off
> a separate /optional/ hrtimer, thus if it's enabled it could enable 1000
> Hz (and not 1024 Hz) update for the variable. The update resolution
> could be tuned via
Hi!
> If we prove that Windows doesn't use the second either then it means
> they enumerate processors via the DSDT -- which means bringing up
> the ACPI interpreter before bringing up SMP -- and that would require
> a significant change to Linux boot sequence...
Well, as we can do cpu hotplug t
On Thu, Feb 01, 2007 at 01:02:41PM +0100, Andi Kleen wrote:
> I don't think so because having per process state in a vsyscall
> is quite costly. You would need to allocate at least one more
> page to each process, which I think would be excessive.
You would need one page per cpu and to check a cha
Hi Pierre!
I have two 2GB capacity SD card (Kingston, noname). When i put either
of them to a card reader, kernel recognize, but "see" only 1GB
capacity, and when i try to access, FAT filesystem paniced.
dmesg:
[snip]
[ 216.408000] usb 4-3: new high speed USB device using ehci_hcd and
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Zach Brown <[EMAIL PROTECTED]> wrote:
>
> > This patch introduces the notion of a 'fibril'. It's meant to be a
> > lighter kernel thread. [...]
>
> as per my other email, i dont really like this concept. This is the
> killer:
let me clarify this:
Kobajashi Zaghi wrote:
> Hi Pierre!
>
> I have two 2GB capacity SD card (Kingston, noname). When i put either
> of them to a card reader, kernel recognize, but "see" only 1GB
> capacity, and when i try to access, FAT filesystem paniced.
>
Your device is not a MMC/SD bridge, so I'm the wrong pers
a) registers.h is really needed there
b) include of asm-generic/termios should be under __KERNEL__
c) includes of asm-generic/{memory_model,page} should be under
__KERNEL (nothing in there that would work in userland)
d) a lot of stuff in ptrace.h should be under __KERNEL__.
Signed-off-by: Al Viro
kexec: Avoid migration of already disabled irqs (ia64)
This patch fixes up ia64 kexec support for HP rx2620 hardware. It does this
by skipping migration of already disabled irqs. This is most likely a problem
on other ia64 platforms as well, but I've only been able to reproduce it on
one machine
On Thu, Feb 01, 2007 at 12:13:31PM +0100, Andi Kleen wrote:
> On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
> > VXTIME_PMTMR will be replaced by a more generic "Master Timer"
>
> This means we have no fallback if something goes wrong with the Master timer?
>
> A little risky.
No,
On 31 Jan 2007 11:08:14 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
Greg KH <[EMAIL PROTECTED]> writes:
>
> What? Throw a fresh-faced newbie instantly into the tar-pit of despair
> that floppy.c is? Do you want everyone just to run screaming from
> kernel development never to be seen again?
On Thursday 01 February 2007 14:13, Jiri Bohac wrote:
> On Thu, Feb 01, 2007 at 12:13:31PM +0100, Andi Kleen wrote:
> > On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
> > > VXTIME_PMTMR will be replaced by a more generic "Master Timer"
> >
> > This means we have no fallback if someth
On Thu, Feb 01, 2007 at 12:14:23PM +0100, Andi Kleen wrote:
> On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
> > TSC is either synchronized by design or not reliable
> > to be used for anything, let alone timekeeping.
>
> In my tree this is already done better by a patch from Ingo.
>
kexec: Fix CONFIG_SMP=n compilation (ia64)
This patch makes it possible to compile kexec for ia64 without SMP support.
Signed-off-by: Magnus Damm <[EMAIL PROTECTED]>
---
Applies on top of 2.6.20-rc7.
arch/ia64/kernel/crash.c | 11 +++
arch/ia64/kernel/machine_kexec.c |2
On Thu, Feb 01, 2007 at 02:02:34PM +0100, Ingo Molnar wrote:
> what i dont really like /the particular/ concept above - the
> introduction of 'fibrils' as a hard distinction of kernel threads. They
> are /almost/ kernel threads, but still by being different they create
> alot of duplication and
On 01/02/07, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
On 31 Jan 2007 11:08:14 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Greg KH <[EMAIL PROTECTED]> writes:
> >
> > What? Throw a fresh-faced newbie instantly into the tar-pit of despair
> > that floppy.c is? Do you want everyone
On Thu, Feb 01, 2007 at 12:22:55PM +0100, Andi Kleen wrote:
> >
> > -unsigned int cpu_khz; /* TSC clocks /
> > usec, not used here */
> > +unsigned int cpu_khz; /* TSC clocks / usec, not used here */
> > +static s64 mt_per_tick;/* mas
Fix misspelled "spin_lock_irqrestore" to read
"spin_unlock_irqrestore" instead.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 4c698a7..25f7cf4 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -1956,7 +1956,7 @
> Ok. I've finally figured out what is going on. The code is race free but the
> programmer was an
> idiot.
Hi,
Could this IRQ problem account for this bug as well, please? Or is yours
strictly a 2.6.19.x
issue?
http://bugzilla.kernel.org/show_bug.cgi?id=7847
I have a dual P4 Xeon box (HT ena
On Thu, Feb 01, 2007 at 12:26:33PM +0100, Andi Kleen wrote:
>
> > +extern void time_initialize_cpu(void);
>
> Never put externs into .c files. Multiple occurrences.
Ok, will fix it, sorry.
> > +void time_initialize_cpu(void *info)
> > +{
> > + unsigned long flags;
> > + int cpu = smp_proces
On 1/7/07, Daniel Walker <[EMAIL PROTECTED]> wrote:
(forgot to CC LKML)
The options,
CONFIG_CFAG12864B=y
CONFIG_CFAG12864B_RATE=20
causes a crash at boot in 2.6.20-rc3-mm1. I don't have the hardware
associated with the options. It looks like it just doesn't have guards
to detect if the hardwar
On Thu, Feb 01, 2007 at 12:28:50PM +0100, Andi Kleen wrote:
> On Thursday 01 February 2007 11:00, [EMAIL PROTECTED] wrote:
> > +inline u64 mt_to_nsec(u64 mt)
> > +{
> > + u64 ret;
> > + ret = ((mt & 0xff) * vxtime.mt_q) >> 32;
> > + mt >>= 24;
> > + ret += ((mt & 0xff) * vxtime.mt_
i386 boot/compressed/relocs checks for absolute symbols and warns about
unexpected ones. If you build with modversions, you get ~2500 warnings
about __crc_. These suckers are really absolute symbols - we
do _not_ want to modify them on relocation.
They are generated by genksyms - EXPORT_... gen
... and having it __init is a bad idea.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
arch/i386/mach-default/setup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/i386/mach-default/setup.c b/arch/i386/mach-default/setup.c
index c511705..cc2f519 100644
--- a/arch
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
fs/nfsd/nfsfh.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
index 98338a5..c59d6fb 100644
--- a/fs/nfsd/nfsfh.c
+++ b/fs/nfsd/nfsfh.c
@@ -269,7 +269,7 @@ fh_verify(struct svc_rqst *rqstp
a) sun4d_boot_one_cpu() should be __cpuinit (called only from
__cpuinit __cpu_up(), for one thing, leads to calls of __cpuinit
functions for another).
b) got externs in arch/sparc/kernel/smp.c to match reality.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
arch/sparc/kernel/smp.c |8 +
a) cleanup_module() should be __exit
b) externs should match reality
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/ide/ide.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/ide/ide.c b/drivers/ide/ide.c
index 3b334af..6c9bd51 100644
--- a/drivers/
missing helper used by arch/i386/mm/highmem.c, which is pulled
into build on that configuration.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
include/asm-um/pgtable.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/asm-um/pgtable.h b/include/asm-um/pgta
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
kernel/fork.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index fc723e5..d57118d 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1313,7 +1313,7 @@ noinline struct pt_regs * __devinit __at
1 - 100 of 384 matches
Mail list logo
