Hi Jeff,
2.6.13- rc7-libata1.patch.bz2 was used.
A combined mode of ata_piix seems not to work.
Is the following patches correct?
diff -urN linux-2.6.13-rc7.orig/drivers/scsi/Kconfig
linux-2.6.13-rc7/drivers/scsi/Kconfig
--- linux-2.6.13-rc7.orig/drivers/scsi/Kconfig 2005-08-25 13:44:33.0
Danial Thom wrote:
--- Ben Greear <[EMAIL PROTECTED]> wrote:
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
* Steven Rostedt <[EMAIL PROTECTED]> 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 the sam
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> So, Ingo, what do you think of the changes so far? Do you feel that
> it is stable enough to send you an actual real patch. That way we can
> work together in cleaning it up and get all the other kinks out.
yeah, please send me a patch against 2.6
i have released the 2.6.13-rc7-rt1 tree, which can be downloaded from
the usual place:
http://redhat.com/~mingo/realtime-preempt/
this is a fixes-only release. Changes since 2.6.13-rc6-rt10:
- init_hrtimers() compilation fix (K.R. Foley)
- first phase p->pi_lock SMP speedup (Steven Rosted
* Darren Hart <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >i have released the 2.6.13-rc6-rt9 tree, which can be downloaded from
> >the usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
> >
>
> I'm looking into getting HRT and RT booting on a SUMMIT NUMA machine
> (cyclone
This patch brings the now out-of-date Documentation/filesystems/vfs.txt back
to life. Thanks to Carsten Otte, Trond Myklebust, and Anton Altaparmakov for
their help on updating this documentation.
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
vfs.txt | 435 +++
On Thu, Aug 25 2005, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > > BUG: scheduling with irqs disabled: libc6.postinst/0x2000/13229
> > > caller is ___down_mutex+0xe9/0x1a0
> > > [] schedule+0x59/0xf0 (8)
> > > [] ___down_mutex+0xe9/0x1a0 (28)
> > > [] cfq_exit_sing
I see the patch, or an equivalent, has been applied already.
Pete
On Wed, 2005-08-24 at 21:08 +0200, Jesper Juhl wrote:
> Since strtok() died in 2002 let's not use it - use strsep() instead which
> is the replacement function.
>
> Note: I've not been able to test this patch since I lack both ha
Danial Thom wrote:
--- Ben Greear <[EMAIL PROTECTED]> wrote:
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
On Wed, Aug 24 2005, Esben Nielsen wrote:
> 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
> > > [] schedu
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> > BUG: scheduling with irqs disabled: libc6.postinst/0x2000/13229
> > caller is ___down_mutex+0xe9/0x1a0
> > [] schedule+0x59/0xf0 (8)
> > [] ___down_mutex+0xe9/0x1a0 (28)
> > [] cfq_exit_single_io_context+0x22/0xa0 (84)
> > [] cfq_exit_io_context
--- Ben Greear <[EMAIL PROTECTED]> wrote:
> 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
This is subarch update for ES7000. I've modified platform check code and
removed unnecessary OEM table parsing for newer systems that don't use
OEM information during boot. Parsing the table in fact is causing problems,
and the platform doesn't get recognized.
The patch only affects the ES7000 s
* 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
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. Th
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 PR
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
part
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
+++ RC13-rc7-lance/drivers/net
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 -04
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
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 00:54:15.
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 PROTECT
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 RC13-rc
* 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
--- RC13-rc7-scc/arch/m68k
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. Fo
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 200
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-1
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
15:48:29
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 hardi
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
+++ RC
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
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.
Sig
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 http:
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 to
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
15:48:29.000
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
+++ RC13-rc7-isa_type/arch/m68k/kernel/setup.
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 -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 instruction
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
Li
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 K
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 noti
>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
>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 scri
> 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 t
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
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 early-us
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 becau
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
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 1
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 power
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 ac
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
lowpw
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/i38
> 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
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 alpha
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
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
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
--- linux-2.6.13
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 lik
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
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
to
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(-)
Index:
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 ar
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.
Signed-o
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 anyth
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
core
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 w
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 real
> 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 1
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_gettim
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 ha
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
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 proble
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
+++ b/drivers/
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 acpi-hotke
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 cp
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 fee
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 doc
[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 another
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 th
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&class=spd
and I see the following when acpi is enabled (haven't even tried
without):
# cat /proc/mtrr
reg00: base=0xd000 (3328MB), size= 256MB: uncacha
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.
Signed-
>>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.
>A
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 << sh
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 pret
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 c
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
> >
1 - 100 of 326 matches
Mail list logo
