* 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 tree.
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
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
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 pretty
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.
Anyhow,
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.
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-S2Mclass=spd
and I see the following when acpi is enabled (haven't even tried
without):
# cat /proc/mtrr
reg00: base=0xd000 (3328MB), size= 256MB:
[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
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
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.
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
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
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 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
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
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
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
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
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(-)
Index:
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
On 8/24/05, Jim Ramsay [EMAIL PROTECTED] wrote:
On 8/24/05, Lukasz Kosewski [EMAIL PROTECTED] wrote:
On 8/24/05, Stefan Richter [EMAIL PROTECTED] wrote:
Timers appear to operate in an atomic context, so timers should not be
allowed to call scsi_remove_device, which eventually schedules.
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 gave
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
---
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 anything
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
mean
the
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
+++ linux-2.6.13-rc6-root/arch/i386/power/cpu.c
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
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
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
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
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 Libsmbios
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 because
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
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. There is
nothing
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
Hi,
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 shift);
This doesn't seem to make sense with the above. Could you
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 the
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
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
make the
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 shift);
This
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 the
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
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
+++
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
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 convert
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 like:
xtime +
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
Hi,
This is my second go at giving you my comments. The first time the email
got lost due to a connection crash. )-: Anyway, its great to see this
updated!
On Wed, 24 Aug 2005, Pekka Enberg wrote:
This patch brings the now out-of-date Documentation/filesystems/vfs.txt back
to life. Thanks
This simple patch provides a fix for a locking issue found in the online
resizing code. The problem actually happened while trying to resize the
filesystem trough the resize=xxx option in a remount.
Signed-off-by: Glauber de Oliveira Costa [EMAIL PROTECTED]
diff -up
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
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 to have n
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
Paul Jackson wrote:
Dinakar wrote:
Can we hold on to this patch for a while, as I reported yesterday,
Sure - though I guess it's Linus or Andrew who will have to do
the holding.
I sent it off contingent on the approval of yourself, Hawkes and Nick.
I get the feeling that the problem
On Wednesday 24 August 2005 10:53 am, Kumar Gala wrote:
Removed IA64 architecture specific users of asm/segment.h and
asm-ia64/segment.h itself
I posted a similar patch a month ago, but I only removed the
arch/ia64 includes of asm/segment.h.
There are still a few drivers that include
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 asm/segment.h references.
Once they have all gone, then a patch can remove the files.
If you are
Nick wrote:
I get the feeling that exclusive cpusets should just be
completely disabled for 2.6.13
No no - not disable exclusive cpusets - disable using them to try
to define sched domains.
That is, I hope you mean that Dinakar's patch that uses cpu_exclusive
cpusets to define sched domains
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 asm/segment.h references.
Once they have all
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. After
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
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 real
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 they should
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
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 or
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 carefully decide
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
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 K
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
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 instruction to flush
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 fine
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 quite slow.
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
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
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
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
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
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.
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 ... question
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
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
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 2005-06-17
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
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
---
* 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
found
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
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
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
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 PROTECTED]
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
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
+++
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
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. That
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
* 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 to [EMAIL
This patch contains the following small cleanups:
- make two needlessly global functions static
- drm_sysfs.c: every file should #include the header with the prototypes
of the global functions it is offering
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
501 - 600 of 641 matches
Mail list logo
