* K.R. Foley <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> Without the attached patch 2.6.13-rc6-rt15 won't compile for me with
> CONFIG_HIGH_RES_TIMERS not configured.
thanks, applied.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Paul Jackson writes:
> ... however ... question for Paul M. ... what version of gcc did this fail
> on?
The gcc-4.0.2 in Debian/ppc sid, which is biarch.
> I finally got my crosstools setup working for me again, and building
> a powerpc64 using gcc-3.4.0 on my Intel PC box does _not_ fail.
pulled from m68k CVS; ADBREQ_RAW is used in arch/m68k/mac/misc.c, but its
declaration had not been propagated to Linus' tree yet. Related chunk in
drivers/macintosh/adb.c also pulled in; even though the file is shared with
ppc, behaviour is changed only for m68k.
Signed-off-by: Al Viro <[EMAIL
oktagon_esp is described as modular. However, drivers/scsi/Makefile doesn't
handle it right - it's multi-object module, with one of the parts being
built from .S. Current makefile tries to declare each part a module of
its own; that not only wouldn't work (oktagon_io.o doesn't have the right
result of comma operator is not an lvalue
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC13-rc7-mac8390/drivers/net/atarilance.c
RC13-rc7-lance/drivers/net/atarilance.c
--- RC13-rc7-mac8390/drivers/net/atarilance.c 2005-06-17 15:48:29.0
-0400
+++
mac won't build without non-modular FONTS, which requires non-modular
FB and FRAMEBUFFER_CONSOLE
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC13-rc7-82596/arch/m68k/Kconfig RC13-rc7-mac-fonts/arch/m68k/Kconfig
--- RC13-rc7-82596/arch/m68k/Kconfig2005-08-10 10:37:46.0
too permissive constraint on mulu.l - the first argument should not be
an a-register. Fixed by replacing "g" with "dm"; with older gcc we got
lucky and it had never attempted mulu.l %a0, %d1:%d0. These days it
does, with predictable objections from as(1).
Signed-off-by: Al Viro <[EMAIL
driver is non-modular
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC13-rc7-oktagon/drivers/net/Kconfig
RC13-rc7-82596/drivers/net/Kconfig
--- RC13-rc7-oktagon/drivers/net/Kconfig2005-08-24 01:58:29.0
-0400
+++ RC13-rc7-82596/drivers/net/Kconfig 2005-08-25
partially pulled from m68k CVS; switches m68k handling of thread flags to
usual bitmap, which allows to unify most of the thread flag helpers. After
that only task_thread_info(), stack_end() and setup_thread_info() are
conditional on __HAVE_THREAD_FUNCTIONS.
Signed-off-by: Al Viro <[EMAIL
a) added embedded thread_info [m68k processor.h]
b) added missing symbols in asm-offsets.c
c) task_thread_info() and freinds in asm-m68k/thread_info.h
d) made m68k thread_info.h included by m68k processor.h, not the
other way round.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN
* James Morris ([EMAIL PROTECTED]) wrote:
> On Wed, 24 Aug 2005, Chris Wright wrote:
>
> > This is based on Kurt's original work. The net effect is that
> > LSM hooks are called conditionally, and in all cases capabilities
> > provide the defaults. I've done some basic performance testing, and
gcc4 is less forgiving and wants memory inputs to be real lvalues; variable
added and value stored in it explicitly before doing __asm__.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC13-rc7-scc/arch/m68k/mac/misc.c
RC13-rc7-m68k-reset/arch/m68k/mac/misc.c
---
new helper - task_thread_info(task). On platforms that have thread_info
allocated separately (i.e. in default case) it simply returns
task->thread_info m68k wants (and for good reasons) to embed its thread_info
into task_struct. So it will (in later patch) have task_thread_info() of
its own.
cast is not an lvalue
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC13-rc7-atyfb-typo/drivers/net/mac8390.c
RC13-rc7-mac8390/drivers/net/mac8390.c
--- RC13-rc7-atyfb-typo/drivers/net/mac8390.c 2005-06-17 15:48:29.0
-0400
+++ RC13-rc7-mac8390/drivers/net/mac8390.c
atyfb_par misspelled as aty_par, fortunately in m68k-only part of driver
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC13-rc7-amigaints/drivers/video/aty/atyfb_base.c
RC13-rc7-atyfb-typo/drivers/video/aty/atyfb_base.c
--- RC13-rc7-amigaints/drivers/video/aty/atyfb_base.c
extern declaration before the static one
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC13-rc7-82596-apricot/drivers/char/scc.h
RC13-rc7-scc/drivers/char/scc.h
--- RC13-rc7-82596-apricot/drivers/char/scc.h 2005-06-17 15:48:29.0
-0400
+++ RC13-rc7-scc/drivers/char/scc.h
extern declaration of static object removed from header
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC13-rc7-dmasound-extern/include/asm-m68k/sun3ints.h
RC13-rc7-sun3ints/include/asm-m68k/sun3ints.h
--- RC13-rc7-dmasound-extern/include/asm-m68k/sun3ints.h2005-06-17
a) in smp_lock.h #include of sched.h and spinlock.h moved under
#ifdef CONFIG_LOCK_KERNEL.
b) interrupt.h now explicitly pulls sched.h (not via smp_lock.h from
hardirq.h as it used to)
c) in two more places we need changes to compensate for (a) - one place in
arch/sparc needs string.h now and
ifdefs around variable declaration would better match those around its uses...
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC13-rc7-lance/drivers/net/82596.c
RC13-rc7-82596-apricot/drivers/net/82596.c
--- RC13-rc7-lance/drivers/net/82596.c 2005-08-10 10:37:49.0 -0400
+++
A day or two ago, Paul M. wrote:
> Compiling -rc7 for ppc64 using pSeries_defconfig I get this compile
> error:
Not that the following really matters ... I've already sent in a fix,
based on your analysis, followed by Nick's suggestion that we don't do
it this way anyway.
... however ...
encapsulates the rest of arch-dependent operations with thread_info access.
Two new helpers - setup_thread_info() and end_of_stack(). For normal
case the former consists of copying thread_info of parent to new thread_info
and the latter returns pointer immediately past the end of thread_info.
Bah... I can't count, apparently. That one is 4/5, the next is
5/5. My apologies - cut'n'waste damage while editing patchset description..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
sound/oss/dmasound/dmasound_atari.c has static expand_bal
sound/oss/dmasound/dmasound_q40.c has static expand_bal
sound/oss/dmasound/dmasound_awacs.c has non-static expand_bal
sound/oss/dmasound/trans_16.c uses expand_bal from dmasound_awacs.c
all 4 include dmasound.h; extern for expand_bal used
extern declaration of static object removed from header
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC13-rc7-sun3_pgtable/include/asm-m68k/amigaints.h
RC13-rc7-amigaints/include/asm-m68k/amigaints.h
--- RC13-rc7-sun3_pgtable/include/asm-m68k/amigaints.h 2005-06-17
result of typecast is not an lvalue. Part of those are fixed in m68k
CVS.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC13-rc7/sound/oss/dmasound/dmasound_atari.c
RC13-rc7-dmasound-lvalues/sound/oss/dmasound/dmasound_atari.c
--- RC13-rc7/sound/oss/dmasound/dmasound_atari.c
missing export on m68k
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC13-rc7-m68k-mul/arch/m68k/kernel/setup.c
RC13-rc7-isa_type/arch/m68k/kernel/setup.c
--- RC13-rc7-m68k-mul/arch/m68k/kernel/setup.c 2005-06-17 15:48:29.0
-0400
+++
function arguments can not be inline, TYVM...
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
diff -urN RC13-rc7-sun3ints/include/asm-m68k/sun3_pgtable.h
RC13-rc7-sun3_pgtable/include/asm-m68k/sun3_pgtable.h
--- RC13-rc7-sun3ints/include/asm-m68k/sun3_pgtable.h 2005-06-17
15:48:29.0
From: Andi Kleen <[EMAIL PROTECTED]>
> > Hi,
> >
> > The following patch does not use MMX regsiters so that we don't have
> > to worry about save/restore the FPU/MMX states.
> >
> > What do you think?
>
> Performance will probably be bad on K7 Athlons - those have a microcoded
> movnti which is
On Wed, Aug 24, 2005 at 09:08:53PM +0200, Jesper Juhl wrote:
> Convert strtok() use to strsep() in usr/gen_init_cpio.c
>
> I've compile tested this patch and it compiles fine.
> I build a 2.6.13-rc6-mm2 kernel with the patch applied without problems, and
> the resulting kernel boots and runs just
From: Hirokazu Takahashi <[EMAIL PROTECTED]>
> > The following patch does not use MMX regsiters so that we don't have
> > to worry about save/restore the FPU/MMX states.
> >
> > What do you think?
>
> I think __copy_user_zeroing_intel_nocache() should be followed by sfence
> or mfence
Danial Thom wrote:
I think the concensus is that 2.6 has made trade
offs that lower raw throughput, which is what a
networking device needs. So as a router or
network appliance, 2.6 seems less suitable. A raw
bridging test on a 2.0Ghz operton system:
FreeBSD 4.9: Drops no packets at 900K pps
Horst wrote:
> > - if ('\n' == *type) {
> > + if (!*type || '\n' == *type) {
>
> Redundant. If *type == '\n', it is certainly != 0.
No - I don't think redundant, at least not this change in isolation.
Perhaps redundant in light of subsequent code lines, as Jesper notes in
his
Could anyone inform which will be a good guide to start learning the linux
kernel programming.
--
Shwetha V
Software Engineer - Networks Business Unit
Sasken Communication Technologies Ltd.
Gold Hill Square, Hosur Road, Bangalore.
Ph: +91-80-25355501 Ext: 5799
Web: www.sasken.com
"Srinivas
On Wed, 24 Aug 2005, Chris Wright wrote:
> This is based on Kurt's original work. The net effect is that
> LSM hooks are called conditionally, and in all cases capabilities
> provide the defaults. I've done some basic performance testing, and
> found nothing surprising.
Do you mean nothing
>Also, tar should be an option instead of cpio for the archiver,
>because tar is more widely used.
>>pretty much everyone will have cpio and it's format is much
>>simpler/cleaner to deal with
>>if we want vastly more complex early-userspace semantics i think we
>>need to
>It uses 50% of total memory for tmpfs, but it would be nice to have
>an option (tmpfs_size=90% etc.) that you could pass to the kernel.
>>that's just because of the tmpfs default; you can remount to change
>>that if it's not suitable once your up and running in your
>>init-scripts
Hi,
I didn't see much informations about this.
It's not possible to "make {,menu}config" and even to compile a 2.6.12
kernel if there is no or partially installed Gettext on the system.
Full Gettext is *required* to launch the kbuild scripts since the
modifications to add i18n to the config
> Date: Fri, 19 Aug 2005 08:39:25 -0600
> From: "William Morrow" <[EMAIL PROTECTED]>
> Subject: [PATCH] for acpi S1 power cycle resume problems
>
>
> Hi
> I was told that if I had a patch to submit for a baseline change that
> this was the place to do it.
In this case that works fine. Normally
Meelis Roos <[EMAIL PROTECTED]> writes:
>>> It does not hang, it just powers off like on halt.
>>
>> Ok. Then at least in part the kernel behavior is either
>> intersecting with a BIOS bug, a bad reboot script that calls halt instead,
>> or a driver that is scribbling on the wrong register.
On Tue, Aug 23, 2005 at 05:16:05PM -0400, [EMAIL PROTECTED] wrote:
> Also, tar should be an option instead of cpio for the archiver,
> because tar is more widely used.
pretty much everyone will have cpio and it's format is much
simpler/cleaner to deal with
if we want vastly more complex
On Wed, Aug 24, 2005 at 06:41:26PM -0400, [EMAIL PROTECTED] wrote:
> I tried it with kernel 2.6.13-rc5 and it seems to work.
it should yes
> It uses 50% of total memory for tmpfs, but it would be nice to have
> an option (tmpfs_size=90% etc.) that you could pass to the kernel.
that's just
On Wed, Aug 24, 2005 at 09:00:21PM -0500, Doug Warzecha wrote:
[...]
> +Dell OpenManage requires this driver on the following Dell PowerEdge systems:
> +300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC, 650, 1655MC,
> +700, and 750. Other Dell software such as the open source
A sysfs interface for PowerOP that allows operating points to be created
and activated from userspace.
The platform-specific backend provides the code to read and write sysfs
attributes for each power parameter; the core sysfs interface has no
knowledge of the struct powerop_point contents. This
A PowerOP sysfs UI backend for OMAP1 platforms, adding sysfs attributes
and show/store functions that correspond to the platform power
parameters.
An example usage on an OMAP1510 Innovator which does not have voltage
scaling and ignoring the DSP:
# echo -n 168-168-84 > /sys/powerop/new # DPLL
PowerOP is a system power parameter management API submitted for
discussion. PowerOP writes and reads power "operating points",
comprised of arbitrary values, called power parameters, that correspond
to registers, clocks, dividers, voltage regulators, etc. that may be
modified to set a basic
Hello everyone,
The system I am working on is a single processor Athlon. In the kernel I
need to detect a cache miss (L1/L2) and trigger an event/function
(inside the kernel). Now we have performance counters for
detecting/counting cache misses. Among the various tools/patches
available for
PowerOP support for OMAP1 platforms. Currently handles these power
parameters:
dpllmult DPLL_CTL reg PLL MULT bits
dplldiv DPLL_CTL reg PLL DIV bits
armdiv ARM_CKCTL reg ARMDIV bits
dspdiv ARM_CKCTL reg DSPDIV bits
tcdivARM_CKCTL reg TCDIV bits
On Wed, 2005-08-24 at 10:50 +0200, Pavel Machek wrote:
> Hi!
>
> > > > diff -puN arch/i386/power/cpu.c~mcheck_resume arch/i386/power/cpu.c
> > > > --- linux-2.6.13-rc6/arch/i386/power/cpu.c~mcheck_resume
> > > > 2005-08-23 09:32:13.054008584 +0800
> > > > +++
> Wrong. Reference:
>
> http://www.phy.duke.edu/~rgb/General/c_book/c_book/chapter8/sequen
> ce_points.html
>
> Cheers,
> Dick Johnson
That discussion is wrong. The form of the argument is simply invalid.
Just because an optimization could break things in some cases doesnt
Andrew, All,
This patch cleans up a commonly repeated set of changes to the NTP
state variables by adding two helper inline functions:
ntp_clear(): Clears the ntp state variables
ntp_synced(): Returns 1 if the system is synced with a time server.
This was compile tested for
On Wed, 2005-08-24 at 18:44 -0700, George Anzinger wrote:
> > Ok, so your forcing gettimeofday to be interval aware, so its applying
> > different fixed NTP adjustments to different chunks of the current
> > interval. The issue of course is if you're using fixed adjustments, is
> > that you have
On Wed, 24 Aug 2005, Daniel Walker wrote:
>
> I got a report of a possible softlockup with setiathome, the trace
> wasn't a little garbled though . I'm not sure the checking is working
> correctly . But if it is maybe these spot need some performance
> analysis . Didn't you changes catch
This patch adds the Dell Systems Management Base Driver with sysfs support.
This driver has been tested with Dell OpenManage.
Signed-off-by: Doug Warzecha <[EMAIL PROTECTED]>
---
diff -uprN linux-2.6.13-rc6.orig/Documentation/dcdbas.txt
linux-2.6.13-rc6/Documentation/dcdbas.txt
---
john stultz wrote:
On Wed, 2005-08-24 at 16:46 -0700, George Anzinger wrote:
john stultz wrote:
On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote:
Roman Zippel wrote:
Hi,
On Tue, 23 Aug 2005, john stultz wrote:
I'm assuming gettimeofday()/clock_gettime() looks something
On Wed, 2005-08-24 at 21:13 -0400, Steven Rostedt wrote:
> Well, after turning off hrtimers, I keep getting one bug. A possible
> soft lockup with the ext3 code. But this didn't seem to be caused by the
> changes I made. So just to be sure, I ran my test on the vanilla
> 2.6.13-rc6-rt11 and it
john stultz wrote:
On Wed, 2005-08-24 at 17:24 -0700, George Anzinger wrote:
CLOCK_TICK_RATE is used by the kernel to compute LATCH, TICK_NSEC and
tick_nsec. This latter is used to update xtime each tick. TICK_NSEC is
then used to compute (at compile time) the conversion constants needed
Call security hooks conditionally if the security_op is filled out.
Branches can be more efficient than the unconditional indirect function
call. Inspired by patch from Kurt Garloff <[EMAIL PROTECTED]>.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
include/linux/security.h | 825
Now that capability functions are default, rootplug no longer needs to
manually add them to its security_ops.
Cc: Greg Kroah <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
security/root_plug.c | 14 +-
1 files changed, 1 insertion(+), 13 deletions(-)
This is based on Kurt's original work. The net effect is that
LSM hooks are called conditionally, and in all cases capabilities
provide the defaults. I've done some basic performance testing, and
found nothing surprising. I'm interested to see numbers from others
before I push this up. These
Collapse security stubs so that the def'n is done in one spot with ifdef
in function body rather than two separately defined functions.
Patch from Kurt Garloff <[EMAIL PROTECTED]>, and slightly altered by me to
make all ifdef sites consistent and move the prototype decl's to a sane
spot.
If a kernel is compiled with CONFIG_SECURITY to enable LSM, the
default behaviour changes unless the admin loads capability.
This is undesirable. This patch makes capability the default.
capability can still be compiled as module and be loaded as LSM.
If loaded as primary LSM, it won't change
Now that all security hook inline stubs conditionally call to module and
do proper default action as fallback, all the old no-op default hooks can
be removed. Similarly, the verify() bits which populated empty slots with
default hooks is no longer needed. A few hooks are called from security
Well, after turning off hrtimers, I keep getting one bug. A possible
soft lockup with the ext3 code. But this didn't seem to be caused by the
changes I made. So just to be sure, I ran my test on the vanilla
2.6.13-rc6-rt11 and it gave the same bug too. So, it looks like my
changes are now at par
Hi list,
If I understand correctly, packets sent to the all-ones
broadcast address only go out through a single interface.
My question is threefold:
1. Why doesn't Linux send 255.255.255.255 packages through
all network interfaces? (I realize that this is
probably not a Linux-specific
Nick wrote:
> and that it looks like what I was thinking about.
Ok - I almost have my crosstool installation healthy again.
I will actually see to it that my patch builds this time for
whatever arch's I can test on, and send this simple disabling
of sched domain mangling from cpuset-land as a
> I think what I'd like to see is that when a slot gets isolated and the
> driver doesn't have recovery code, the kernel calls the driver's
> unplug function and generates a hotplug event to udev. Ideally this
> would be a variant of the remove event which would say "and by the
> way, please try
Hi,
On Wed, 24 Aug 2005, john stultz wrote:
> Ok, well, I'm still at a loss for understanding how this avoids my
> concern about time inconsistencies.
Let's take a simple example to demonstrate the difference between system
time and reference time.
NTP tells us to update the reference time by
On Wed, 2005-08-24 at 16:46 -0700, George Anzinger wrote:
> john stultz wrote:
> > On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote:
> >
> >>Roman Zippel wrote:
> >>
> >>>Hi,
> >>>
> >>>On Tue, 23 Aug 2005, john stultz wrote:
> >>>
> >>>
> >>>
> I'm assuming
David Woodhouse wrote:
> If it's mandatory that we actually call the signal handler, then we need
> to play tricks like sigsuspend() does to leave the old signal mask on
> the stack frame. That's a bit painful atm because do_signal is different
> between architectures.
It is necessary that the
On Wed, 2005-08-24 at 17:24 -0700, George Anzinger wrote:
> CLOCK_TICK_RATE is used by the kernel to compute LATCH, TICK_NSEC and
> tick_nsec. This latter is used to update xtime each tick. TICK_NSEC is
> then used to compute (at compile time) the conversion constants needed
> to
CLOCK_TICK_RATE is used by the kernel to compute LATCH, TICK_NSEC and
tick_nsec. This latter is used to update xtime each tick. TICK_NSEC is
then used to compute (at compile time) the conversion constants needed
to convert to/from jiffies from/to timespec and timeval (and others).
The
This changes the Sun Gem Ether driver's tx ring buffer
length to the proper constant. Currently TX_RING_SIZE
and RX_RING_SIZE are equal, so no malfunction occurs.
Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
--- a/drivers/net/sungem.h 2005-08-19 14:35:50.0 -0700
+++
root:sleipner:~# modprobe hotkey
FATAL: Error inserting hotkey
(/lib/modules/2.6.13-rc7/kernel/drivers/acpi/hotkey.ko): No such device
Not that I care, but it at least loaded in -rc6 and created the
/proc/acpi/hotkey directory with its content.
When the revolution comes, the author of
Ray Fucillo wrote:
I am seeing process creation time increase linearly with the size of the
shared memory segment that the parent touches. The attached forktest.c
is a very simple user program that illustrates this behavior, which I
have tested on various kernel versions from 2.4 through 2.6.
Paul Jackson wrote:
So long as the cpuset code stops making any calls to partition_sched_domains()
whatsoever, then we should be back where we were in 2.6.12, so far as the
scheduler is concerned - right?
That's right - sorry I just meant disabling the dynamic sched
domains behaviour of the
Linas Vepstas writes:
> The meta-issue that I'd like to reach consensus on first is whether
> there should be any hot-plug recovery attempted at all. Removing
> hot-plug-recovery support will make many of the issues you raise
> to be moot.
Yes, this probably the thorniest issue we have.
My
Wilkerson, Bryan P wrote:
Is there an equivalent kernel boot option for kgdbwait in
2.6.13-rc4-mm1? I grep'd the kernel source but didn't find kgdbwait.
Is there any documentation other than the source for the flavor of KGDB
that is included in the akpm kernel patch?
The patch has some
[Resend...forgot to send to lkml]
We are currently reserving one byte more than actually needed
by the flash device and overlapping into the next I/O expansion
bus window. This a) causes us to allocate an extra page of VM due
to ARM ioremap() alignment code and b) could cause problems
if
john stultz wrote:
On Tue, 2005-08-23 at 17:29 -0700, George Anzinger wrote:
Roman Zippel wrote:
Hi,
On Tue, 23 Aug 2005, john stultz wrote:
I'm assuming gettimeofday()/clock_gettime() looks something like:
xtime + (get_cycles()-last_update)*(mult+ntp_adj)>>shift
Where did you get
Hi,
I tested 2.6.13-rc7 on nice server motherboard with 16GB of RAM ;)
http://www.msicomputer.com/product/p_spec.asp?model=E7520_Master-S2M=spd
and I see the following when acpi is enabled (haven't even tried
without):
# cat /proc/mtrr
reg00: base=0xd000 (3328MB), size= 256MB: uncachable,
GCC 4 emits more DWARF debugging information than before and there is now a
.debug_loc section as well. This causes "make buildcheck" to fail.
Rather than just add that one to the special case list, I used a regexp to
ignore any .debug_ANYTHING sections in case more show up in the future.
>>On Wed, Aug 24, 2005 at 04:52:37PM -0400, Wakko Warner wrote:
>>Care to send me the patch?
>Heh. Not really as I don't really know if people should be using it
>in it's current state --- the shmem init is very very hacky and I have
>other changes I've not had a chance to do.
On Wed, 2005-08-24 at 21:49 +0200, Roman Zippel wrote:
> On Wed, 24 Aug 2005, john stultz wrote:
>
> > from your example:
> > > // at init: system_update = update_cycles * mult;
> > > system_time += system_update;
> >
> > and:
> > > error = system_time - (xtime.tv_nsec <<
Hello,
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
>
> Hullo.
>
> I really wanted to release a 2.6.13, but there's been enough changes
> while we've been waiting for other issues to resolve that I think it's
> best to do a -rc7 first.
>
> Most of the -rc7 changes are
Ravikiran G Thirumalai a écrit :
Following patch moves a few static 'read mostly' variables to the
.data.read_mostly section. Typically these are vector - irq tables,
boot_cpu_data, node_maps etc., which are initialized once and read from
often and rarely written to. Please include.
Good
Hi Mauro,
> > I2C_DEVNAME and i2c_clientname were introduced in 2.5.68 [1] to help
> > media/video driver authors who wanted their code to be compatible
> > with both Linux 2.4 and 2.6. The cause of the incompatibility has
> > gone since [2], so I think we can get rid of them, as they tend to
> >
Version 6 of the ARM architecture introduces the concept of 16MB pages
(supersections) and 36-bit (40-bit actually, but nobody uses this)
physical addresses. 36-bit addressed memory and I/O and ARMv6 can
only be mapped using supersections and the requirement on these is
that both virtual and
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> Done. Looks like you want empty_zero_page write protected too. That
> seems like a fine idea to me unless something really wants to do atomic
> 64-bit reads on it.
Thanks, I added this set (minus the 3/5, which I already have) to the
virt-2.6
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
>
> >* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> >
> >
> >>--- linux-2.6.13.orig/arch/i386/mm/init.c 2005-08-24
> >>09:31:05.0 -0700
> >>+++ linux-2.6.13/arch/i386/mm/init.c2005-08-24 09:31:31.0
>
Following patch moves a few static 'read mostly' variables to the
.data.read_mostly section. Typically these are vector - irq tables,
boot_cpu_data, node_maps etc., which are initialized once and read from
often and rarely written to. Please include.
Thanks,
Kiran
Patch to mark variables
Jens Axboe wrote:
Ok, I'll give you some hints to get you started... What you really want
to do, is:
- Insert a park request at the front of the queue
- On completion callback on that request, freeze the block queue and
schedule it for unfreeze after a given time
Am attaching a first
Chris Wright wrote:
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
--- linux-2.6.13.orig/arch/i386/mm/init.c 2005-08-24 09:31:05.0
-0700
+++ linux-2.6.13/arch/i386/mm/init.c2005-08-24 09:31:31.0 -0700
@@ -79,6 +79,7 @@ static pte_t * __init one_page_table_ini
{
Chris Wright wrote:
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
Chris Wright wrote:
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
--- linux-2.6.13.orig/arch/i386/mm/init.c 2005-08-24
09:31:05.0 -0700
+++ linux-2.6.13/arch/i386/mm/init.c2005-08-24
Hi Marcelo,
> All of these seem to be cleanups/cosmetic enhancements rather than
> real bugfixes, except the ML address update.
Patches 1/5, 3/5 and 4/5 are typo fixes in documentation and comments.
5/5 however qualifies as (minor) bug fix IMHO, as missing newlines in
log messages will cause the
>> I'll apply this for ia64 w/o the deletion.
This is now in my test tree. I will send to Linus soon after
2.6.13 is released.
>I've posted a patch before this to remove all non-architecture users
>of asm/segment.h.
>
>http://www.ussg.iu.edu/hypermail/linux/kernel/0508.3/0099.html
Good.
On Aug 24, 2005, at 3:19 PM, Luck, Tony wrote:
There are still a few drivers that include asm/segment.h, so
I don't think we should remove asm/segment.h itself just yet.
Agreed. The sequence should be to send patches to get rid of
all "#include " references.
Once they have all gone, then
On Wed, 24 Aug 2005, Jens Axboe wrote:
> On Wed, Aug 24 2005, Lee Revell wrote:
> > Just found this in dmesg.
> >
> > BUG: scheduling with irqs disabled: libc6.postinst/0x2000/13229
> > caller is ___down_mutex+0xe9/0x1a0
> > [] schedule+0x59/0xf0 (8)
> > [] ___down_mutex+0xe9/0x1a0 (28)
>
On Aug 24, 2005, at 4:50 PM, Alan Cox wrote:
On Mer, 2005-08-24 at 11:43 -0500, Kumar Gala wrote:
The following set of patches removes the use and existence of
asm/segment.h from the architecture ports
You've broken various things by doing this because some driver code
rightly or wrongly
On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:
> On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote:
> > Most of the remaining stuff is for
> > m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
> > and if Geert ACKs them, we will be _very_ close to
On Mer, 2005-08-24 at 14:43 +0200, moreau francis wrote:
> I'm currently trying to write a USB driver for Linux. The device must be
> configured by writing some values into the same register but I want to be
> sure that the writing order is respected by either the compiler and the cpu.
The Linux
1 - 100 of 641 matches
Mail list logo
