Am Montag, den 04.04.2005, 00:45 -0500 schrieb Dmitry Torokhov:
> Hi Kenan,
>
[..]
> > If I do "echo -n 50 > resolution" "0xe8 0x01" is sent. I don't know if
> > this is correct for "usual" PS/2-devices but for the lifebook it's
> > wrong.
> >
> > For the lifebook the parameters are as followin
* Paul Jackson <[EMAIL PROTECTED]> wrote:
> Would be a good idea to rename 'cpu_distance()' to something more
> specific, like 'cpu_dist_ndx()', and reserve the generic name
> 'cpu_distance()' for later use to return a scaled integer distance,
> rather like 'node_distance()' does now. [...]
a
* Paul Jackson <[EMAIL PROTECTED]> wrote:
> Nick wrote:
> > In a sense, the information *is* already there - in node_distance.
> > What I think should be done is probably to use node_distance when
> > calculating costs, ...
>
> Hmmm ... perhaps I'm confused, but this sure sounds like the alterna
Nick wrote:
> In a sense, the information *is* already there - in node_distance.
> What I think should be done is probably to use node_distance when
> calculating costs, ...
Hmmm ... perhaps I'm confused, but this sure sounds like the alternative
implementation of cpu_distance using node_distance
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > a numa scheduler domain at the top level and cache_hot_time will be
> > set to 0 in that case on smp box. Though this will be a mutt point
> > with recent patch from Suresh Siddha for removing the extra bogus
> > scheduler domains.
> > http://mar
* Chen, Kenneth W <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote on Sunday, April 03, 2005 7:30 AM
> > how close are these numbers to the real worst-case migration costs on
> > that box?
>
> I booted your latest patch on a 4-way SMP box (1.5 GHz, 9MB ia64). This
> is what it produces. I think t
===
Input: serport - avoid calling serio_interrupt or serio_write_wakeup
on unregistered port. Also fix memory leak which could happen
if serport was left unused by moving serio allocation down to
serport_ldisc_re
===
Input: ALPS needs to be reset for detection to work reliably when
reconnecting.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
alps.c |2 ++
1 files changed, 2 insertions(+)
Index: dtor/drivers/input/mouse/alps
===
Input: move serio port's id attributes into separate subdirectory:
..devices/serioX/id_type -> ..devices/serioX/id/type
..devices/serioX/id_proto -> ..devices/serioX/id/proto
Signed-off-by: Dmitry Torokhov <[EMAIL
===
Input: serio - do not attempt to immediately disconnect port if
resume failed, let kseriod take care of it. Otherwise we
may attempt to unregister associated input devices which
will generate hotplug events wh
Hi Vojtech,
I have some patches that I would like to get in before 2.6.12 is out:
01-serio-resume-fix.patch
- do not attempt to disconnect port in resume handler if reconect
failed - let kseriod handle it. This fixes problem with swsusp
resuming devices before writing the image. If reco
On Sun, 2005-04-03 at 20:55 -0700, Paul Jackson wrote:
> But if we knew the CPU hierarchy in more detail, and if we had some
> other use for that detail (we don't that I know), then I take it from
> your comment that we should be reluctant to push those details into the
> sched domains. Put them
Dear all,
I try to modify inet_sendmsg() and inet_recvmsg().
To defer the time to notify a receiver, I use a timer for the problem.
But it causes "Scheduling in interrupt" error.
Is there any method to reform it?
Thank you for tour help
MingChieh Chang,
Taiwan
Scheduling in interrupt
invalid
Ingo wrote:
> There's no other place to push them
One could make a place, if the need arose.
> but trying and benchmarking it is necessary to tell for sure.
Hard to argue with that ... ;).
--
I won't rest till it's the best ...
Programmer, Linux Scalability
* Paul Jackson <[EMAIL PROTECTED]> wrote:
> Ingo, if I understood correctly, suggested pushing any necessary
> detail of the CPU hierarchy into the scheduler domains, so that his
> latest work tuning migration costs could pick it up from there.
>
> It makes good sense for the migration cost es
Hi,
On Mon, 2005-04-04 at 13:28, Nathan Lynch wrote:
> On Mon, Apr 04, 2005 at 10:07:02AM +0800, Li Shaohua wrote:
> > Clean up all CPU states including its runqueue and idle thread,
> > so we can use boot time code without any changes.
> > Note this makes /sys/devices/system/cpu/cpux/online unwor
Hi Kenan,
On Sunday 03 April 2005 14:49, Kenan Esau wrote:
> Patches 1-3 are fine.
>
Thank you very much for testing the patches. Based on the feedback I
received I am goping to drop that DMI patch - does not save enough to
justify the ifdefs...
> Protocol switching via sysfs works too but if I
On ppc, we emulate instructions that cause alignment exceptions. If
we are single-stepping an instruction and it causes an alignment
exception, we will currently do the next instruction as well before
taking the single-step exception. This patch fixes that, so we take
the single-step exception af
If we should happen to get an altivec assist exception while executing
in the kernel, we will currently try to handle it and fail, and end up
oopsing with (apparently) a segfault. (An altivec assist exception
occurs for floating-point altivec instructions with denormalized
inputs or outputs if the
Dear all,
I try to modify inet_sendmsg() and inet_recvmsg().
To defer the time to notify a receiver, I use a timer for the problem.
But it causes "Scheduling in interrupt" error.
Is there any method to reform it?
Thank you for tour help
Scheduling in interrupt
invalid operand:
CPU:0
EI
On Mon, Apr 04, 2005 at 10:07:02AM +0800, Li Shaohua wrote:
> Clean up all CPU states including its runqueue and idle thread,
> so we can use boot time code without any changes.
> Note this makes /sys/devices/system/cpu/cpux/online unworkable.
In what sense does it make the online attribute unwor
subscribe
-
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/
Currently the procedure in the ppc32 kernel that synchronizes the
timebase registers across an SMP powermac system does so by setting
both timebases to zero. That is OK at boot but causes problems if
done later. So that we can do hotplug CPU on these machines, this
patch changes the code so it re
Dear all,
I try to modify inet_sendmsg() and inet_recvmsg().
To defer the time to notify a receiver, I use a timer for the problem.
But it causes "Scheduling in interrupt" error.
Is there any method to reform it?
Thank you for tour help
Error:
Scheduling in interrupt
invalid operand:
CPU:
Andy wrote:
> Not that I really know what I'm talking about here, but this sounds
> highly parallelizable.
I doubt it. If we are testing the cost of a migration between CPUs
alpha and beta, and at the same time testing betweeen CPUs gamma and
delta, then often there will be some hardware that is
On Sunday 03 April 2005 23:43, Beast wrote:
>Hi Gene,
>Is this posting for me?
Yes it was.
>Gene Heskett wrote:
>> I also don't play Sender Confirmation games, particularly when the
>> confirmation message is in html only.
>
>AFAIK, I never set any confirm receipt or sending html format to the
>
$B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B
$B"#"#"#!!(B $B"#"#"#(B $B"#(B $B"#(B $B!!"#"#"#(B
$B"#"#"#(B $B"#(B
$B"#"#(B $B"#(B$B"#"#(B $B!!"#(B$B"#(B
$B"#(B$B"#(B $B"#(B
Paul Jackson wrote:
Ok - that flies, or at least walks. It took 53 seconds to
compute this cost matrix.
Not that I really know what I'm talking about here, but this sounds
highly parallelizable. It seems like you could do N/2 measurements at a
time, so this should be O(N) to compute the matrix
On Sun, 3 Apr 2005, Dave Airlie wrote:
> On a standard FC3 with selinux enabled, booting the latest -bk breaks
> all my outgoing TCP connections at a guess due to this patch.. this
> probably isn't something that people really want to happen.. or maybe
> Fedora can release an updated policy to dea
Mark wrote:
> Probably all Linux binary drivers *are* compiled using GPL'd header files,
> and thus are themselves subject to the GPL.
I doubt that there is a consensus that simply compiling something with
a GPL header necessarily and always subjects it to the GPL. See your lawyer.
--
The code that went into arch/ppc/kernel/signal.c recently to handle
process freezing seems to contain a dubious assumption: that a process
that calls do_signal when PF_FREEZE is set will have entered the
kernel because of a system call. This patch removes that assumption.
Signed-off-by: Paul Mack
Paul wrote:
> I should push in the direction of improving the
> SN2 sched domain hierarchy.
Nick wrote:
> I'd just be a bit careful about this.
Good point - thanks.
I will - be careful. I have no delusions that I know what would be an
"improvement" to the scheduler - if anything.
Ingo, if I un
On Fri, Apr 01, 2005 at 02:46:53PM +0200, Mikael Pettersson wrote:
> Andrew Morton writes:
> > David Gibson <[EMAIL PROTECTED]> wrote:
> > >
> > > On Thu, Mar 31, 2005 at 03:11:29PM -0800, Andrew Morton wrote:
> > > > Mikael Pettersson <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Here's a 3
Sam Ravnborg wrote:
On Thu, Mar 31, 2005 at 12:02:13PM -0800, Randy.Dunlap wrote:
Other than "sounds good," are there some comments on:
a. leaving IrDA and Bluetooth subsystem (with drivers) where they
are, which is under "Network options and protocols"
(I really don't want to split the
Dag Arne Osvik <[EMAIL PROTECTED]> wrote:
>
>>... and with such name 99% will assume (at least at the first reading)
>>that it _is_ 32bits. We have more than enough portability bugs as it
>>is, no need to invite more by bad names.
>
> Agreed. The way I see it there are two reasonable options. O
On Sun, Apr 03, 2005 at 01:38:33PM -0400, Kyle Moffett wrote:
> Also, the intermodule stuff is slated for removal, as soon as MTD and
> such are fixed; the interface has been deprecated for a while.
Actually 'just' mtd now iirc. agpgart was the penultimate user which
got fixed a few months back
On Mon, 2005-04-04 at 10:48, Andrew Morton wrote:
> Li Shaohua <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, 2005-04-04 at 10:37, Andrew Morton wrote:
> > > Li Shaohua <[EMAIL PROTECTED]> wrote:
> > > >
> > > > The patches are against 2.6.11-rc1 with Zwane's CPU hotplug patch in -mm
> > > > tree.
> >
Li Shaohua <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2005-04-04 at 10:37, Andrew Morton wrote:
> > Li Shaohua <[EMAIL PROTECTED]> wrote:
> > >
> > > The patches are against 2.6.11-rc1 with Zwane's CPU hotplug patch in -mm
> > > tree.
> >
> > Should I merge that thing into mainline? It seems that a
On Mon, 2005-04-04 at 10:37, Andrew Morton wrote:
> Li Shaohua <[EMAIL PROTECTED]> wrote:
> >
> > The patches are against 2.6.11-rc1 with Zwane's CPU hotplug patch in -mm
> > tree.
>
> Should I merge that thing into mainline? It seems that a few people are
> needing it.
I'd like to listen to som
Li Shaohua <[EMAIL PROTECTED]> wrote:
>
> The patches are against 2.6.11-rc1 with Zwane's CPU hotplug patch in -mm
> tree.
Should I merge that thing into mainline? It seems that a few people are
needing it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Herzlichen Glückwünsch.
Sie sind einer der glücklichen Menschen denen wir folgendes Super-Angebot
unterbreiten können:
Spielen Sie mit beim Casino Royal Las Vegas und freuen Sie sich auf bis zu
500 $ Extra
beim ersten Kauf von Chips!!
Ja Sie lesen richtig - bei Ihrem ersten Chipkauf geben wir ihne
(I'm not currently subscribed to the kernel mailing list, please CC any
replies to my account.)
I've been trying hibernate on my Sony Vaio R505E using Software Suspend.
I'm using the following command:
echo -n "disk" > /sys/power/state
The basic suspend/resume seems to be working now (after many
Boot a CPU at runtime and use it to support S3 SMP.
Thanks,
Shaohua
---
linux-2.6.11-root/arch/i386/kernel/smpboot.c | 79 +++
linux-2.6.11-root/include/asm-i386/smp.h |4 +
linux-2.6.11-root/kernel/power/main.c| 30 ++
3 files changed, 104 in
Clean up all CPU states including its runqueue and idle thread,
so we can use boot time code without any changes.
Note this makes /sys/devices/system/cpu/cpux/online unworkable.
Thanks,
Shaohua
---
linux-2.6.11-root/arch/i386/kernel/cpu/common.c | 12
linux-2.6.11-root/arch/i386/kernel/
Trival patch for CPU hotplug. In CPU identify part, only did cleanup for intel
CPUs. Need do for other CPUs if they support S3 SMP.
Thanks,
Shaohua
---
linux-2.6.11-root/arch/i386/kernel/apic.c| 14 +++
linux-2.6.11-root/arch/i386/kernel/cpu/common.c | 30 ++
Add kconfig for IA32 S3 SMP.
Thanks,
Shaohua
---
linux-2.6.11-root/kernel/power/Kconfig |7 +++
1 files changed, 7 insertions(+)
diff -puN kernel/power/Kconfig~smp_s3_kconfig kernel/power/Kconfig
--- linux-2.6.11/kernel/power/Kconfig~smp_s3_kconfig2005-03-31
10:49:57.156487160 +08
Paul Jackson wrote:
Ingo wrote:
if you create a sched-domains hierarchy (based on the SLIT tables, or in
whatever other way) that matches the CPU hierarchy then you'll
automatically get the proper distances detected.
Yes - agreed. I should push in the direction of improving the
SN2 sched domain
Make sibling map init per-cpu. Hotplug CPU may change the map at runtime.
cpuhotplug semaphore should be used to protect the map.
Thanks,
Shaohua
---
linux-2.6.11-root/arch/i386/kernel/smpboot.c | 56 +--
1 files changed, 29 insertions(+), 27 deletions(-)
diff -puN
Hi,
The following 6 patches try to add suspend-to-ram (or S3) SMP support
for IA32. It's for support HT based system suspend/resume currently and
most of the code are also useful for physical CPU hotplug.
In a SMP system, after S3 resume, the BP is starting to execute the ACPI
wakeup address just
Make SEP init per-cpu, so is hotplug safe.
Thanks,
Shaohua
---
linux-2.6.11-root/arch/i386/kernel/smpboot.c |6 ++
linux-2.6.11-root/arch/i386/kernel/sysenter.c | 10 ++
linux-2.6.11-root/arch/i386/mach-voyager/voyager_smp.c |6 ++
3 files changed,
Siddha, Suresh B wrote on Friday, April 01, 2005 8:05 PM
> On Sat, Apr 02, 2005 at 01:11:20PM +1000, Nick Piggin wrote:
> > How important is this? Any application to real workloads? Even if
> > not, I agree it would be nice to improve this more. I don't know
> > if I really like this approach - I g
final:
- 2.4.30-rc4 was released as 2.4.30 with no changes.
Summary of changes from v2.4.30-rc3 to v2.4.30-rc4
Herbert Xu:
o [NETLINK] Fix bogus mc_list deletion
Marcelo Tosatti:
o Cset exclude: [EMAIL PROTECTED]|ChangeSet|20050226095914|25750
Linus Torvalds wrote:
>
>
> On Fri, 1 Apr 2005, Chen, Kenneth W wrote:
>>
>> Paul, you definitely want to check this out on your large numa box. I
>> booted a kernel with this patch on a 32-way numa box and it took a long
>> time to produce the cost matrix.
>
> Is there anything fundamen
Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> I run into OOM problem again on 2.6.12-rc1. I run some(20) fsx tests on
> 2.6.12-rc1 kernel(and 2.6.11-mm4) on ext3 filesystem, after about 10
> hours the system hit OOM, and OOM keep killing processes one by one. I
> could reproduce this problem very
Ingo Molnar wrote on Sunday, April 03, 2005 7:30 AM
> how close are these numbers to the real worst-case migration costs on
> that box?
I booted your latest patch on a 4-way SMP box (1.5 GHz, 9MB ia64). This
is what it produces. I think the estimate is excellent.
[00]: -10.4(0) 10.4(0) 1
Greetings,
(Please CC responses as I am not subscribed to the list. Thanks!)
I've recently started experiencing the following problem on one of my
Linux servers:
allocation failed: out of vmalloc space - use vmalloc= to increase
size.
allocation failed: out of vmalloc space - use vmalloc= to inc
Wij hebben geheel nieuw in ons aanbod edel horloges opgenomen.
Wij hebben bijna alle fantastische modelle voor u, die u zich maar wensen
kunt.
Alles van Bulgari, Cartier tot Chopard en Omega en Gucci uurwerken is te
verkrijgen.
Gesorteerd naar mannen en vrouwen uurwerken, of als geschenkbox is er o
Ingo Molnar wrote on Saturday, April 02, 2005 11:04 PM
> the default on ia64 (32MB) was way too large and caused the search to
> start from 64MB. That can take a _long_ time.
>
> i've attached a new patch with your changes included, and a couple of
> new things added:
>
> - removed the 32MB max_ca
Andrew Morton a écrit :
It appears that we might have jumped from flagged_taskfile into something
at 0xdf6d1211, which is rather odd.
You have two different low-level IDE drivers configured. Which one is
driving that filesystem? VIA or Promise?
hdg is connected to my Promise PDC20268 (Ultra100 T
On Mon, Apr 04, 2005 at 12:48:04AM +0200, Dag Arne Osvik wrote:
> Andreas Schwab wrote:
>
> >Dag Arne Osvik <[EMAIL PROTECTED]> writes:
> >
> >
> >
> >>Yes, but wouldn't it be much better to avoid code like the following,
> >>which may also be wrong (in terms of speed)?
> >>
> >>#ifdef CONFIG_64
On Sun, Apr 03, 2005 at 07:58:10PM +0200, |TEcHNO| wrote:
> Hi,
>
> As told, I tested it w/o nvidia module loaded, here's what I found:
> 1. It now doesn't hang on scanning for devices.
> 2. It now hangs on acquiring preview, logs will follow.
>...
> Apr 3 15:54:27 techno kernel: Unable to handle
Hi Viro,
(B
(BThank you for your replay.
(B
(B> > Stack traceback for pid 2130
(B> > 0xf717f1b0 21301 1 0 R
(B> 0xf717f400 *irqbalance
(B> > ESP EIP Function (args)
(B> > 0xf75bfe38 0xc02d04b2 _spin_lock+0x2e (0xf7441a80)
(B> > 0xf75bff34 0xc015667c file_m
Zan Lynx wrote:
That does not really make sense, as the driver model code could be used
for ndiswrapper, for example. That would not make the Windows net
drivers derived code of the Linux kernel. ndiswrapper, yes it would be.
Binary driver blobs, no.
The Windows net drivers are not (we believe) c
On dim, 2005-04-03 at 18:01 +0200, Juergen Kreileder wrote:
> Esben Stien <[EMAIL PROTECTED]> writes:
>
> > Jeremy Nickurak <[EMAIL PROTECTED]> writes:
> >
> >> I'm playing with this under 2.6.11.4
> >
> > I got 2.6.12-rc1
> >
> >> The vertical cruise control buttons work properly, with the
> >>
Triffid Hunter wrote:
try turning off your internal modem in bios until someone works out
whats going on here
* It's one of those modern bios, no way of configuring that.
* It seems to me that it detects only 1 card with 1 only codec which is
the sound card (sound works if i avoid the null pointe
Grzegorz Kulewski wrote:
On Mon, 4 Apr 2005, Dag Arne Osvik wrote:
(...) And, at least in theory, long may even provide less than 32 bits.
Are you sure?
My copy of famous C book by B. W. Kernighan and D. Ritchie says that
sizeof(short) <= sizeof(int) <= sizeof(long)
and
sizeof(short) >= 16,
sizeof
Ingo wrote:
> how close are these numbers to the real worst-case migration costs on
> that box? What are the cache sizes and what is their hierarchies?
> ...
> is there any workload that shows the same scheduling related performance
> regressions, other than Ken's $1m+ benchmark kit?
I'll have
On Mon, 4 Apr 2005, Dag Arne Osvik wrote:
(...) And, at least in
theory, long may even provide less than 32 bits.
Are you sure?
My copy of famous C book by B. W. Kernighan and D. Ritchie says that
sizeof(short) <= sizeof(int) <= sizeof(long)
and
sizeof(short) >= 16,
sizeof(int) >= 16,
sizeof(long)
Ingo wrote:
> if you create a sched-domains hierarchy (based on the SLIT tables, or in
> whatever other way) that matches the CPU hierarchy then you'll
> automatically get the proper distances detected.
Yes - agreed. I should push in the direction of improving the
SN2 sched domain hierarchy.
On Mon, 2005-04-04 at 04:22 +0530, Arun Srinivas wrote:
> Thanks. yes, a reschedule may not take place after a ms, if the currently
> running task cannot be preempted by another task.
>
> (1) But, can a reschedule happen within a millisec (or once a process is
> scheduled can schedule() be calle
On Mon, Apr 04, 2005 at 12:48:04AM +0200, Dag Arne Osvik wrote:
> unsigned long happens to coincide with uint_fast32_t for x86 and x86-64,
> but there's no guarantee that it will on other architectures. And, at
> least in theory, long may even provide less than 32 bits.
To port on such platform
Al Viro wrote:
On Sun, Apr 03, 2005 at 02:30:11PM +0200, Dag Arne Osvik wrote:
Yes, but wouldn't it be much better to avoid code like the following,
which may also be wrong (in terms of speed)?
#ifdef CONFIG_64BIT // or maybe CONFIG_X86_64?
#define fast_u32 u64
#else
#define fast_u32 u32
#end
Hi!
> it is only suspend2ram which stopped working after 2.6.11-mm4 (at least
> in 2.6.12-rc1-mm3,4).
>
> Concerning tests with minimal kernel config: I guess since it *was*
> working there should not be a change necessary -- but well, from
> 2.6.11-mm2 to 2.6.11-mm4 I had to stop hotplug/usb to
Hi!
> > Okay, you obviously have easy access to usb development trees...
> > Do you think you could just take this patch as a basis and fix
> > remaining u32 vs pm-message-t in usb? --p
>
> Fixing the "sparse -Wbitwise" messages, and addressing some other
> behavior changes/bugs that crept in,
Thanks. yes, a reschedule may not take place after a ms, if the currently
running task cannot be preempted by another task.
(1) But, can a reschedule happen within a millisec (or once a process is
scheduled can schedule() be called before the next millisec.) ?
2) Also in case argument (1) is no
From: Steven Rostedt <[EMAIL PROTECTED]>
To: Jesper Juhl <[EMAIL PROTECTED]>
CC: Arun Srinivas <[EMAIL PROTECTED]>,LKML
Subject: Re: sched /HT processor
Date: Sun, 03 Apr 2005 11:31:03 -0400
On Sun, 2005-04-03 at 13:17 +0200, Jesper Juhl wrote:
>
> A reschedule can happen once every ms,
Andreas Schwab wrote:
Dag Arne Osvik <[EMAIL PROTECTED]> writes:
Yes, but wouldn't it be much better to avoid code like the following,
which may also be wrong (in terms of speed)?
#ifdef CONFIG_64BIT // or maybe CONFIG_X86_64?
#define fast_u32 u64
#else
#define fast_u32 u32
#endif
How ab
On Fre, 01 Apr 2005, Pavel Machek wrote:
> > I suspends fine, but never resumes. No CapsLock, no sysrq, no network is
> > working. Nothing in the log files. Is there anything which may cause
> > these troubles when compiled into the kernel and not loaded as module?
> > (as it was with my usb stuff
Ingo wrote:
> if_ there is a significant hierarchy between CPUs it
> should be represented via a matching sched-domains hierarchy,
Agreed.
I'll see how the sched domains hierarchy looks on a bigger SN2 systems.
If the CPU hierarchy is not reflected in the sched-domain hierarchy any
better there,
On Sünndag 03 April 2005 20:50, Paul E. McKenney wrote:
> I couldn't find any way to suppress the "deprecated" warning that is
> generated by the "&sym" in the last line of the __EXPORT_SYMBOL()
> macro. Anyone know a way of doing this? There doesn't seem to me
> to be any point to giving the war
On Apr 03, 2005, at 16:25, Kenneth Johansson wrote:
But is this not exactly what Dag Arne Osvik was trying to do ??
uint_fast32_t means that we want at least 32 bits but it's OK with
more if that happens to be faster on this particular architecture.
The problem was that the C99 standard types are n
Mathieu Bérard <[EMAIL PROTECTED]> wrote:
>
> Hi,
> I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4.
> (Everyting run smoothly using 2.6.11-mm1)
> It seems to be related with mounting a reiserfs3 filesystem.
It looks more like an IDE bug.
> ReiserFS: hdg1: checking transaction
On Sun, 3 Apr 2005 12:21:01 -0300
Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> wrote:
> Em Sat, Apr 02, 2005 at 01:46:03PM -0600, James Bottomley escreveu:
> > Well, this is a brown paper bag for someone. The new protocol
>
> /me using such bag now :(
>
> Thanks a lot for the fix.
>
> David, P
On Sun, Apr 03, 2005 at 12:57:28PM -0700, Joel Becker wrote:
> I humbly submit configfs. With configfs, a configfs
> ...
> Patch is against 2.6.12-rc1-bk3.
Updated for bk5 and the new backing_dev capabilites mask:
http://oss.oracle.com/~jlbec/files/configfs/2.6.12-rc1-bk5/con
On Sun, 2005-04-03 at 21:23 +0200, Renate Meijer wrote:
> On Apr 3, 2005, at 2:30 PM, Dag Arne Osvik wrote:
>
> > Stephen Rothwell wrote:
> >
> >> On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> I've been working on a new DES implementation for Linux,
Jeremy Nickurak <[EMAIL PROTECTED]> writes:
> On Tue, 2005-03-08 at 21:52 +0100, Vojtech Pavlik wrote:
> > The problem is that the mouse really does reports all the double-button
> > stuff and autorepeat, and horizontal wheel together with button press on
> > wheel tilt.
>
> Okay, I'm playing wit
On Sun, 3 Apr 2005, Dave Hansen wrote:
> On Sun, 2005-04-03 at 15:37 +0100, Mel Gorman wrote:
> > While testing the page placement policy patches on 2.6.12-rc1, I noticed
> > that aim9 is showing significant slowdowns on page allocation-related
> > tests. An excerpt of the results is at the end of
On Sat, Apr 02, 2005 at 09:09:37AM +0300, Antti Salmela wrote:
> % mdadm --create -l 1 -n 2 /dev/md2 /dev/hde /dev/hdg
> % pvcreate /dev/md2
> % vgextend vg1 /dev/md2
> % pvmove /dev/hdf /dev/md2
A few similar reports still appearing, possibly still related to
the md bio_clone changes that fixed
On Sunday 03 April 2005 12:31 pm, [EMAIL PROTECTED] wrote:
> Okay, you obviously have easy access to usb development trees...
> Do you think you could just take this patch as a basis and fix
> remaining u32 vs pm-message-t in usb? --p
Fixing the "sparse -Wbitwise" messages, and addressing some o
Folks,
I humbly submit configfs. With configfs, a configfs
config_item is created via an explicit userspace operation: mkdir(2).
It is destroyed via rmdir(2). The attributes appear at mkdir(2) time,
and can be read or modified via read(2) and write(2). readdir(3)
queries the list of item
Patches 1-3 are fine.
Protocol switching via sysfs works too but if I switch from LBPS/2 to
PS/2 the device name changes from "/dev/event1" to "/dev/event2" -- is
this intended?
If I do "echo -n 50 > resolution" "0xe8 0x01" is sent. I don't know if
this is correct for "usual" PS/2-devices but for
On Sat, Mar 19, 2005 at 07:28:00PM -0500, Ryan Anderson wrote:
> On Mon, Mar 14, 2005 at 11:59:26AM -0800, Ajay Patel wrote:
> > I had a similar problem building binrpm-pkg.
> > Try following patch. It worked for me.
>
> My problem wasn't actually resolved by this - the make in builddeb still
> ca
Steven Rostedt wrote:
On Sun, 2005-04-03 at 09:10 +0200, Manfred Spraul wrote:
Yes - sem or spin locks are quicker as long as no cache line transfers
are necessary. If the semaphore is accessed by multiple cpus, then
kmalloc would be faster: slab tries hard to avoid taking global locks.
I'm n
On Apr 3, 2005, at 2:30 PM, Dag Arne Osvik wrote:
Stephen Rothwell wrote:
On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <[EMAIL PROTECTED]> wrote:
I've been working on a new DES implementation for Linux, and ran into
the problem of how to get access to C99 types like uint_fast32_t for
internal
On Sat, Mar 12, 2005 at 11:32:29PM -0500, Ryan Anderson wrote:
>
> Sam, you'll probably want this on top of the patch I sent. (I haven't
> built in a clean tree in a while, found a minor problem when I was
> transitioning to quilt today.)
Combined this to one patch and applied it.
Let's see what
On Sun, 2005-04-03 at 15:37 +0100, Mel Gorman wrote:
> While testing the page placement policy patches on 2.6.12-rc1, I noticed
> that aim9 is showing significant slowdowns on page allocation-related
> tests. An excerpt of the results is at the end of this mail but it shows
> that page_test is allo
On Mon, Apr 04, 2005 at 12:11:56AM +1000, Michael Ellerman wrote:
> Hi Paul,
>
> I'm not quite clear on the difference between the two synchronize functions ,
> the comment for synchronize_sched() seems to have a bit missing? (see below)
>
> cheers
>
> On Sun, 3 Apr 2005 16:21, Paul E. McKenney
On Sun, Apr 03, 2005 at 02:26:50PM +0530, Dipankar Sarma wrote:
> On Sat, Apr 02, 2005 at 10:21:50PM -0800, Paul E. McKenney wrote:
> > The synchronize_kernel() primitive is used for quite a few different
> > purposes: waiting for RCU readers, waiting for NMIs, waiting for interrupts,
> > and so on
On Sun, Apr 03, 2005 at 02:30:11PM +0200, Dag Arne Osvik wrote:
> Yes, but wouldn't it be much better to avoid code like the following,
> which may also be wrong (in terms of speed)?
>
> #ifdef CONFIG_64BIT // or maybe CONFIG_X86_64?
> #define fast_u32 u64
> #else
> #define fast_u32 u32
> #end
Actually, please do NOT apply this. It conflicts with other
patches, which have been in the past few MM releases, have
also been circulated on linux-usb-devel, and actually address
some of the bugs which crept in as things have changed around
the USB stack.
- Dave
-
To unsubscribe from this list:
1 - 100 of 174 matches
Mail list logo