On Thu, Apr 07, 2005 at 10:17:15AM +0200, Xavier Bestel wrote:
Le jeudi 07 avril 2005 à 10:04 +0200, David Schmitt a écrit :
Then I would like to exercise my right under the GPL to aquire the source
code
for the firmware (and the required compilers, starting with genfw.c which
is
Le jeudi 07 avril 2005 10:32 +0200, Olivier Galibert a crit :
On Thu, Apr 07, 2005 at 10:17:15AM +0200, Xavier Bestel wrote:
Le jeudi 07 avril 2005 10:04 +0200, David Schmitt a crit :
Then I would like to exercise my right under the GPL to aquire the source
code
for the firmware
Andrew Morton writes:
The problem with those is letting other people get access to it. I guess
that could be fixed with a bit of scripting and rsyncing.
Yes.
(I don't do that for -mm because -mm basically doesn't work for 99% of the
time. Takes 4-5 hours to out a release out assuming that
On Thu, 2005-04-07 at 01:50 -0700, Andrew Morton wrote:
(I don't do that for -mm because -mm basically doesn't work for 99% of
the time. Takes 4-5 hours to out a release out assuming that
nothing's busted, and usually something is).
On the subject of -mm: are you going to keep doing the BK
Here's an updated dyn-tick patch. Some minor fixes:
Doesn't look so good here. I get this with 2.6.12-rc2 (plus a few other
patches).
Disabling Dynamic Tick makes everything happy again (it boots).
[4294688.655000] Unable to handle kernel NULL pointer dereference at
virtual
Eric W. Biederman wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
I don't think you did get a rejection, a few people said that _they_
weren't going to do it, but if you
Andrew Morton wrote:
David Woodhouse [EMAIL PROTECTED] wrote:
One feature I'd want to see in a replacement version control system is
the ability to _re-order_ patches, and to cherry-pick patches from my
tree to be sent onwards.
You just described quilt patch-scripts.
The problem with
On Thu, Mar 31, 2005 at 03:23:11PM -0800, Greg KH wrote:
ChangeSet 1.2331, 2005/03/31 14:08:02-08:00, [EMAIL PROTECTED]
[PATCH] i2c: new driver for ds1337 RTC
Hi,
I know it is bad time to send any patches, but lets try anyway :)
My embedded device is using DS1339 I2C RTC clock which differs
Paul Mackerras [EMAIL PROTECTED] wrote:
With -mm we get those nice little automatic emails saying you've put
the patch into -mm, which removes one of the main reasons for wanting
to be able to get an up-to-date image of your tree.
Should have done that ages ago..
The other reason,
of
David Woodhouse [EMAIL PROTECTED] wrote:
On Thu, 2005-04-07 at 01:50 -0700, Andrew Morton wrote:
(I don't do that for -mm because -mm basically doesn't work for 99% of
the time. Takes 4-5 hours to out a release out assuming that
nothing's busted, and usually something is).
On the
On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
The main idea was to simplify userspace control and notification
system - so people did not waste it's time learning how skb's are
allocated
and processed, how socket layer is
On Apr 6, 2005, at 9:09 PM, Blaisorblade wrote:
For Jörn Engel and the issue he opened: at the end of this mail I
describe
another bug caught by 2.95 and not by 3.x.
On Tuesday 05 April 2005 22:18, Renate Meijer wrote:
On Apr 5, 2005, at 8:53 PM, Blaisorblade wrote:
On Tuesday 05 April 2005
On Thu, Apr 07, 2005 at 10:25:18AM +0100, David Woodhouse wrote:
On Thu, 2005-04-07 at 01:50 -0700, Andrew Morton wrote:
(I don't do that for -mm because -mm basically doesn't work for 99% of
the time. Takes 4-5 hours to out a release out assuming that
nothing's busted, and usually
Hi all,
/proc/scsi/scsi currently has a very dumb implementation of the seq_file
api which causes 'cat /proc/scsi/scsi' to return with -ENOMEM when a
large amount of devices are connected.
This patch impelements the proper seq_file interface which prints out
all devices sequentially.
The use of
Hi Ladislav,
I know it is bad time to send any patches, but lets try anyway :)
My embedded device is using DS1339 I2C RTC clock which differs from
DS1337 only in one register at address 10h which enables battery charge.
Originaly I was using my own driver, but decided to extend existing
On Thu, 2005-04-07 at 01:32 -0700, Andrew Morton wrote:
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
Plus, I'm still quite unsettled about the whole object lifecycle
management, refcounting and locking in there. The fact that the code is
littered with peculiar barriers says something
2.6.12-rc2, with CONFIG_PREEMPT and CONFIG_PREEMPT_DEBUG. The
in_atomic() macro thinks that preempt_disable() indicates an atomic
region so calls to __might_sleep() result in a stack trace.
preempt_count() returns 1, no soft or hard irqs are running and no
spinlocks are held. It looks like there
On Thu, 2005-04-07 at 10:55 +0100, Russell King wrote:
Thinking about it a bit, if you're asking Linus to pull your tree,
Linus would then have to extract the individual change sets as patches
to put into his new fangled patch management system. Is that a
reasonable expectation?
I don't know
Hugh Dickins [EMAIL PROTECTED] wrote:
Remove use of FIRST_USER_PGD_NR from sys_mincore: it's inconsistent (no
other syscall refers to it), unnecessary (sys_mincore loops over vmas
further down) and incorrect (misses user addresses in ARM's first pgd).
You should make it use
On Thu, 2005-04-07 at 20:10 +1000, Keith Owens wrote:
2.6.12-rc2, with CONFIG_PREEMPT and CONFIG_PREEMPT_DEBUG. The
in_atomic() macro thinks that preempt_disable() indicates an atomic
region so calls to __might_sleep() result in a stack trace.
but you're not allowed to schedule when preempt
Keith Owens [EMAIL PROTECTED] wrote:
2.6.12-rc2, with CONFIG_PREEMPT and CONFIG_PREEMPT_DEBUG. The
in_atomic() macro thinks that preempt_disable() indicates an atomic
region so calls to __might_sleep() result in a stack trace.
preempt_count() returns 1, no soft or hard irqs are running and
On Thu, Apr 07, 2005 at 05:34:56AM -0400, Jeff Garzik wrote:
For tg3 a transition period shouldn't be needed as firmware loading
is only needed on old/buggy hardware which is not the common case.
Or to support advanced features which can be disabled.
TSO firmware is commonly used these days.
On Thu, Apr 07, 2005 at 11:46:27AM +0200, Hannes Reinecke wrote:
Hi all,
/proc/scsi/scsi currently has a very dumb implementation of the seq_file
api which causes 'cat /proc/scsi/scsi' to return with -ENOMEM when a
large amount of devices are connected.
/proc/scsi/scsi is deprecated and
On Thu, 07 Apr 2005, Sergei Organov wrote:
David Woodhouse [EMAIL PROTECTED] writes:
On Wed, 2005-04-06 at 08:42 -0700, Linus Torvalds wrote:
PS. Don't bother telling me about subversion. If you must, start reading
up on monotone. That seems to be the most viable alternative, but don't
On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote:
On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
The main idea was to simplify userspace control and notification
system - so people did not waste it's time learning
On Thu, 7 Apr 2005, Paul Mackerras wrote:
Andrew Morton writes:
The problem with those is letting other people get access to it. I guess
that could be fixed with a bit of scripting and rsyncing.
Yes.
Me too ;-)
(I don't do that for -mm because -mm basically doesn't work for 99% of the
I recently switched from bk to darcs (actually looked into it after the author
mentioned on LKML that he had imported the kernel tree). Very impressed so
far, but as you say,
1. It's rather slow and quite CPU consuming and certainly I/O consuming
I expect something as large as the kernel tree
On Wednesday 06 April 2005 16:42, Linus Torvalds wrote:
PS. Don't bother telling me about subversion. If you must, start reading
up on monotone. That seems to be the most viable alternative, but don't
pester the developers so much that they don't get any work done. They are
already aware of
Ingo Molnar [EMAIL PROTECTED] wrote:
--- linux/arch/i386/kernel/entry.S.orig
+++ linux/arch/i386/kernel/entry.S
@@ -179,12 +179,17 @@ need_resched:
ENTRY(sysenter_entry)
movl TSS_sysenter_esp0(%esp),%esp
sysenter_past_esp:
-sti
+#
+# irqs are disabled: set up
Andrew Morton writes:
The other reason,
of course, is to be able to see if a patch I'm about to send conflicts
with something you have already taken, and rebase it if necessary.
hack, hack
How's this?
Nice; but in fact I meant that I want to be able to see if a patch of
mine
On Wednesday 30 March 2005 11:59 pm, Patrick McFarland wrote:
2.6.8 is also fubar. Now to 2.6.7
Nope, 2.6.7 is also fubar. Now to 2.6.6.
BTW, can the ALSA userland in anyway screw me here? I mean,the joystick stuff
shouldn't have anything to do with it at all... but
--
Patrick
On Thu, 2005-04-07 at 12:41 +0200, Kay Sievers wrote:
On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote:
On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote:
The main idea was to simplify userspace control and
Christoph Hellwig wrote:
On Thu, Apr 07, 2005 at 11:46:27AM +0200, Hannes Reinecke wrote:
Hi all,
/proc/scsi/scsi currently has a very dumb implementation of the seq_file
api which causes 'cat /proc/scsi/scsi' to return with -ENOMEM when a
large amount of devices are connected.
On Thu, Apr 07, 2005 at 11:59:05AM +0200, Jean Delvare wrote:
Please slice this into separarte patches. Adding support for the DS1339
is one thing, bug fixes are another. I can't review patches which do
that many different things at once.
I have objection ;-) Nothing in kernel seems to use
On Apr 6, 2005, at 11:11 PM, Kyle Moffett wrote:
On Apr 06, 2005, at 07:41, Renate Meijer wrote:
On Apr 6, 2005, at 12:11 AM, Kyle Moffett wrote:
Please don't remove Linux-Kernel from the CC, I think this is an
important discussion.
GAAH!!! Read my lips!!! Quit removing Linux-Kernel from the CC!!!
On Thu, Apr 07, 2005 at 01:21:23PM +0200, Hannes Reinecke wrote:
/proc/scsi/scsi is deprecated and even only compiled in if
legacy /proc/scsi/ support is enabled. Please move over to lssci which
is using sysfs ASAP.
Ah. And that's enough reason for it not to work properly?
Deprecated
Hi,
Are there any estimates for when inotify will finally make it into the
official kernel? The mm kernels are getting pretty well tested, and it's
fairly obvious that inotify is a big improvement on dnotify. It would be
really cool to have this more widely distributed.
Cheers,
Dave.
--
David
Hi Jes, long time without hearing about you :)
On Thu, Apr 07, 2005 at 03:17:33AM -0400, Jes Sorensen wrote:
Sven On Mon, Apr 04, 2005 at 12:21:05PM +0200, Arjan van de Ven
Sven wrote:
Sven Ok, can you please point to me where is the place it should be
Sven taken off ? I suppose you mean
On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
I don't think you did get a rejection, a few people
On Tue, Apr 05, 2005 at 11:46:41AM -0400, Benjamin LaHaise wrote:
On Mon, Apr 04, 2005 at 01:56:35PM -0400, Trond Myklebust wrote:
IOW: the current semaphore implementations really all need to die, and
be replaced by a single generic version to which it is actually
practical to add new
Thanks for kindly reply, :)
No. I got the same problem without linuxrc.
As I mount ram0 as root, linuxrc is not necessary. Right?
Apply these rules:
1.) If you do provide an initrd= thing, the initrd is being looked for
/linuxrc.
2.) If the root is the same as the ramdisk, then the initrd is
Dropping Linus off this list...
On Mon, Mar 28, 2005 at 12:40:16PM +0100, Dave Airlie wrote:
Hi Linus,
In order to stop someone loading a drm driver on a wrong core this patch
makes the driver pass in the version is was built against, this mainly
useful for people using the DRI snapshots
David Schwartz wrote:
Well whoever wrote that seems to have taken the stand that
the openfirmware package was were the firmware came from.
The person obviously made a lot of statements without
bothering checking out the real source. Well it didn't come
from there, I got it from Alteon under a
Hi,
again I've hit some wird problem doing make dep for 2.4 kernel:
I've extracted the linxu-2.4.30.tar.gz file, copied .config from
previous src-tree, ran `make oldconfig', did `make menuconfig',
and finally `make dep':
[cut]
make[2]: Leaving directory `/usr/src/linux-2.4.30/arch/i386/lib'
Hello!
[I hope this is the correct list, if not, please tell me where to ask]
The following scenario:
Linux-client -- Ethernet -- Linux-router -- PPPoE -- Internet.
Linux-client has MTU==1500, so the MSS is 1460.
Linux-router has MTU==1500 on eth0 and MTU=1492 on ppp0.
The MSS is set to 1452
On Thu, Apr 07, 2005 at 12:17:37PM +0200, Arjan van de Ven wrote:
On Thu, 2005-04-07 at 20:10 +1000, Keith Owens wrote:
2.6.12-rc2, with CONFIG_PREEMPT and CONFIG_PREEMPT_DEBUG. The
in_atomic() macro thinks that preempt_disable() indicates an atomic
region so calls to __might_sleep()
Hi Martin :)
* Martin MOKREJ? [EMAIL PROTECTED] dixit:
again I've hit some wird problem doing make dep for 2.4 kernel:
Not a kernel problem but a findutils problem. Fixed in 4.2.19,
but 4.2.20 was released recently. Upgrade.
Raúl Núñez de Arenas Coronado
--
Linux Registered
When using a machine with a 2612-rc 1kernel, I encounter problems
reading /dev/random:
it simply nevers returns anything, and the process is blocked in the
read...
The easiest way to see it is to type:
od /dev/random
Any idea?
--
Best regards
Patrice Martinez
Linux Kernel Architect.
OFFICE :
I tried 2.6.12-rc2 which includes this patch, and I get DRM failures
here, which causes application and X to hang. (I got failures with 2.6.11
also.)
Does the FC-4 test kernel work? There was a bug in X6.8.2 but I think it
would be fixed in FC-4 test.. I run Xorg CVS on a 9200 with the
Hi,
VST patch (http://lwn.net/Articles/118693/) attempts to avoid useless
regular (local) timer ticks when a CPU is idle.
I think a potential area which VST may need to address is
scheduler load balance. If idle CPUs stop taking local timer ticks for
some time, then during that period
On Thu, Apr 07, 2005 at 01:38:52PM +0100, Dave Airlie wrote:
I tried 2.6.12-rc2 which includes this patch, and I get DRM failures
here, which causes application and X to hang. (I got failures with 2.6.11
also.)
Does the FC-4 test kernel work? There was a bug in X6.8.2 but I think it
David Schmitt wrote:
On Thursday 07 April 2005 09:25, Jes Sorensen wrote:
[snip] I got it from Alteon under a written agreement stating I
could distribute the image under the GPL. Since the firmware is
simply data to Linux, hence keeping it under the GPL should be just
fine.
Then I would
My lattest runs were with 2 days old FC development (a.k.a. bleeding edge)
environment with xorg-11-** of same age. Then I noticed that these DRM
patches didn't make it into kernel-smp-2.6.11-1.1226_FC4.i686.rpm,
and I made 2.6.12-rc2 -- just in case it had fixed the problem...
well
Hi,
On Thu, 2005-04-07 at 09:14, Ingo Molnar wrote:
doesnt the first option also allow searches to be in parallel?
In terms of CPU usage, yes. But either we use large windows, in which
case we *can't* search remotely near areas of the disk in parallel; or
we use small windows, in which case
Srivatsa Vaddagiri wrote:
I think a potential area which VST may need to address is
scheduler load balance. If idle CPUs stop taking local timer ticks for
some time, then during that period it could cause the various runqueues to
go out of balance, since the idle CPUs will no longer pull tasks
On Thu, 7 Apr 2005, Humberto Massa wrote:
David Schmitt wrote:
On Thursday 07 April 2005 09:25, Jes Sorensen wrote:
[snip] I got it from Alteon under a written agreement stating I
could distribute the image under the GPL. Since the firmware is
simply data to Linux, hence keeping it under the GPL
On Thu, 2005-04-07 at 14:40 +0200, Patrice Martinez wrote:
When using a machine with a 2612-rc 1kernel, I encounter problems
reading /dev/random:
it simply nevers returns anything, and the process is blocked in the
read...
The easiest way to see it is to type:
od /dev/random
Any
Hi Ladislav,
Please slice this into separarte patches. Adding support for the DS1339
is one thing, bug fixes are another. I can't review patches which do
that many different things at once.
I have objection ;-) Nothing in kernel seems to use that driver (...)
How would you know? It has
On Thu, 2005-04-07 at 14:40 +0200, Patrice Martinez wrote:
When using a machine with a 2612-rc 1kernel, I encounter problems
reading /dev/random:
it simply nevers returns anything, and the process is blocked in the
read...
The easiest way to see it is to type:
od /dev/random
Any
On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
On Wed, Apr 06 2005, James Bottomley wrote:
My proposal is to correct this by moving the data back to the correct
object, and make any object using it hold a reference, so this would
make the provider of the block request_fn hold a
On Thu, Apr 07, 2005 at 09:18:38AM -0400, James Bottomley wrote:
On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
On Wed, Apr 06 2005, James Bottomley wrote:
My proposal is to correct this by moving the data back to the correct
object, and make any object using it hold a reference, so
On Thu, Apr 07 2005, Christoph Hellwig wrote:
On Thu, Apr 07, 2005 at 09:18:38AM -0400, James Bottomley wrote:
On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
On Wed, Apr 06 2005, James Bottomley wrote:
My proposal is to correct this by moving the data back to the correct
On Thu, Apr 07 2005, James Bottomley wrote:
On Thu, 2005-04-07 at 08:49 +0200, Jens Axboe wrote:
On Wed, Apr 06 2005, James Bottomley wrote:
My proposal is to correct this by moving the data back to the correct
object, and make any object using it hold a reference, so this would
make
On Thu, 2005-04-07 at 14:22 +0100, Christoph Hellwig wrote:
Do we really need the sdev_lock pointer? There's just a single place
where we're using it and the code would be much more clear if it had just
one name.
Humour me for a while. I don't believe we have any way the lock can be
used
On Thu, Apr 07 2005, James Bottomley wrote:
On Thu, 2005-04-07 at 14:22 +0100, Christoph Hellwig wrote:
Do we really need the sdev_lock pointer? There's just a single place
where we're using it and the code would be much more clear if it had just
one name.
Humour me for a while. I
On Thu, 2005-04-07 at 15:32 +0200, Jens Axboe wrote:
I think Christophs point is that why add sdev_lock as a pointer, instead
of just killing it? It's only used in one location, so it's not really
that confusing (and a comment could fix that).
Because any use of sdev-request_queue-queue_lock
Richard == Richard B Johnson [EMAIL PROTECTED] writes:
Richard Last time I checked, GPL was about SOFTware, not FIRMware,
Richard and not MICROcode.
Oh be real, there's no real difference between them and you know it.
It's all about where the bits are stored and what they tend to do in a
Richard B. Johnson [EMAIL PROTECTED] writes:
Last time I checked, GPL was about SOFTware, not FIRMware, and
not MICROcode. If somebody has decided to rename FIRMware to
SOFTware,
Debian has undertaken to change the meaning of a whole lot of words,
including software and free.
This whole
AsterixTheGaul [EMAIL PROTECTED] said:
-#define module_init(x) __initcall(x);
+#define module_init(x) __initcall(x); __module_init_disable(x);
It would be better if there is brackets around them... like
#define module_init(x) { __initcall(x); __module_init_disable(x); }
then we know
On Thu, Apr 07, 2005 at 11:07:55PM +1000, Nick Piggin wrote:
3. This is exactly one of the situations that the balancing backoff code
was designed for. Can you just schedule interrupts to fire when the
next balance interval has passed? This may require some adjustments to
the backoff
Srivatsa Vaddagiri wrote:
Hmm ..I guess we could restrict the max time a idle CPU will sleep taking
into account its balance interval. But whatever heuristics we follow to
maximize balance_interval of about-to-sleep idle CPU, don't we still run the
risk of idle cpu being woken up and going
Le jeudi 07 avril 2005 à 09:03 -0400, Richard B. Johnson a écrit :
Well it doesn't make any difference. If GPL has degenerated to
where one can't upload microcode to a device as part of its
initialization, without having the source that generated that
microcode, we are in a lot of hurt. Intel
On Thu, Apr 07, 2005 at 03:24:34PM +0400, Evgeniy Polyakov wrote:
On Thu, 2005-04-07 at 12:41 +0200, Kay Sievers wrote:
On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote:
On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote:
On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov
David Howells wrote:
Hugh Dickins [EMAIL PROTECTED] wrote:
Remove use of FIRST_USER_PGD_NR from sys_mincore: it's inconsistent (no
other syscall refers to it), unnecessary (sys_mincore loops over vmas
further down) and incorrect (misses user addresses in ARM's first pgd).
You should make it use
On Thu, 2005-04-07 at 16:23 +0200, Kay Sievers wrote:
Sure, but seems I need to ask again: What is the exact reason not to implement
the muticast message multiplexing/subscription part of the connector as a
generic part of netlink? That would be nice to have and useful for other
subsystems
On Thu, 7 Apr 2005, Andrew Morton wrote:
Ingo Molnar [EMAIL PROTECTED] wrote:
--- linux/arch/i386/kernel/entry.S.orig
+++ linux/arch/i386/kernel/entry.S
@@ -179,12 +179,17 @@ need_resched:
ENTRY(sysenter_entry)
movl TSS_sysenter_esp0(%esp),%esp
sysenter_past_esp:
-
* Linus Torvalds [EMAIL PROTECTED] wrote:
pushfl
After all, I very strongly suspect that we don't actually really
_care_ if eflags stays the same over a system call, and I could see
that some dynamic CPU's might prefer not having to push an eflags
value that just got changed
* Keith Owens [EMAIL PROTECTED] wrote:
2.6.12-rc2, with CONFIG_PREEMPT and CONFIG_PREEMPT_DEBUG. The
in_atomic() macro thinks that preempt_disable() indicates an atomic
region so calls to __might_sleep() result in a stack trace.
preempt_count() returns 1, no soft or hard irqs are running
On Wednesday 06 April 2005 22:21, Greg KH wrote:
On Wed, Apr 06, 2005 at 08:38:00PM +0200, [EMAIL PROTECTED] wrote:
CC: [EMAIL PROTECTED]
I'm resending this for inclusion in the -stable tree. I've deleted
whitespace cleanups, and hope this can be merged. I've been asked to
split the
On Wednesday 06 April 2005 23:35, Daniel Phillips wrote:
When I tried it, it took 13 seconds to 'bzr add' the 2.6.11.3 tree on a
relatively slow machine.
Oh, and 135 seconds to commit, so 148 seconds overall. Versus 87 seconds to
to bunzip the tree in the first place. So far, you are in the
On Thu, 7 Apr 2005, Paul Mackerras wrote:
Are you happy with processing patches + descriptions, one per mail?
Yes. That's going to be my interim, I was just hoping that with 2.6.12-rc2
out the door, and us in a calming down period, I could afford to not
even do that for a while.
The real
* Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
Hi,
VST patch (http://lwn.net/Articles/118693/) attempts to avoid useless
regular (local) timer ticks when a CPU is idle.
I think a potential area which VST may need to address is scheduler
load balance. If idle CPUs stop taking local
In the not-too distant past, one could disable Ctl-Alt-DEL.
Can't do it anymore.
Script started on Thu 07 Apr 2005 10:58:11 AM EDT
[SNIPPED leading stuff...]
mprotect(0xb7fe4000, 28672, PROT_READ|PROT_EXEC) = 0
brk(0) = 0x804a000
brk(0x8053000)
On Thu, Apr 07 2005, James Bottomley wrote:
On Thu, 2005-04-07 at 15:32 +0200, Jens Axboe wrote:
I think Christophs point is that why add sdev_lock as a pointer, instead
of just killing it? It's only used in one location, so it's not really
that confusing (and a comment could fix that).
Richard B. Johnson wrote:
Well it doesn't make any difference. If GPL has degenerated to where
one can't upload microcode to a device as part of its initialization,
without having the source that generated that microcode, we are in
a lot of hurt. Intel isn't going to give their designs away.
I
Am Donnerstag, 7. April 2005 16:30 schrieb Humberto Massa:
I don't recall anyone asking Intel to give theirs designs away. This
thread is about:
1. (mainly) some firmware hexdumps present in the kernel source tree are
either expicitly marked as being GPL'd or unmarked, in which case one
On Wed, Apr 06, 2005 at 05:28:56PM -0400, Trond Myklebust wrote:
...
A look at nfsstat might help, as might netstat -s.
In particular, I suggest looking at the retrans counter in nfsstat.
When doing a 'cp largefile1 largefile2' on the client, I see approx. 10
retransmissions per second in
On Thu, 2005-04-07 at 02:30 +0200, Roman Zippel wrote:
I was hoping for this too, in the meantime can't you simply make it a
suboption of DISCONTIGMEM? So an extra option is only visible when it's
enabled and most people can ignore it completely by just disabling a
single option.
That's
Dear Jean,
On Thu, Apr 07, 2005 at 03:07:40PM +0200, Jean Delvare wrote:
I have objection ;-) Nothing in kernel seems to use that driver (...)
How would you know? It has a user-space interface
(ds1337_driver.command), which anyone might be using.
I asked how is this driver supposed to
On Thu, 7 Apr 2005, Yura Pakhuchiy wrote:
On Thu, 2005-04-07 at 14:40 +0200, Patrice Martinez wrote:
When using a machine with a 2612-rc 1kernel, I encounter problems
reading /dev/random:
it simply nevers returns anything, and the process is blocked in the
read...
The easiest way
On Thu, Apr 07, 2005 at 09:19:06AM +1000, Greg Banks wrote:
...
How large is the client's RAM?
2GB - (32 bit kernel because it's dual PIII, so I use highmem)
A few more details:
With standard VM settings, the client will be laggy during the copy, but
it will also have a load average around 10
Oliver Neukum wrote:
As this has been discussed numerous times and consensus never
achieved and is unlikely to be achieved, I suggest that you keep this
discussion internal to Debian until at least you have patches which
can be evaluated and discussed. Until then Debian may do to its
kernel
Am Donnerstag, 7. April 2005 17:01 schrieb Humberto Massa:
Oliver Neukum wrote:
As this has been discussed numerous times and consensus never
achieved and is unlikely to be achieved, I suggest that you keep this
discussion internal to Debian until at least you have patches which
On Thu, 7 Apr 2005, Kay Sievers wrote:
Sure, but seems I need to ask again: What is the exact reason not to implement
the muticast message multiplexing/subscription part of the connector as a
generic part of netlink? That would be nice to have and useful for other
subsystems too as an option
Hi,
On Wed, 2005-04-06 at 21:10, Stephen C. Tweedie wrote:
However, 2.6 is suspected of still having leaks in ext3. To be certain
that we're not just backporting one of those to 2.4, we need to
understand who exactly is going to clean up these bh's if they are in
fact unused once we
On Thu, Apr 07, 2005 at 05:38:48PM +0200, Jakob Oestergaard wrote:
On Thu, Apr 07, 2005 at 09:19:06AM +1000, Greg Banks wrote:
...
How large is the client's RAM?
2GB - (32 bit kernel because it's dual PIII, so I use highmem)
Ok, that's probably not enough to fully trigger some of the
Hello,
I am trying to install the srripc module - source at:
http://www.cogent.ca/Software/SRR.html
on a Linux 2.6.x kernel with udev support. The kernel generates an oops
in misc_register, which is essentially the first call that the module
makes on initialization. Oops output is attached
Sven Luther [EMAIL PROTECTED] writes:
On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote:
For tg3 a transition period shouldn't be needed as firmware loading
is only needed on old/buggy hardware which is not the common case.
Or to support advanced features which can be
Tired of waiting for the software to be delivered
to you? With our offers you will install and enjoy
the program right after the download is completed
All popular software available
http://Lynnette.hbzakkeukj.com/?aVIKcRH.SehpFaaLynnette
not interested?
Hello.
Ingo Molnar wrote:
now if an interrupt hits at this point, it will set up a 'same privilege
level' stackframe, which has eip/xcs/eflags, i.e. no esp/xss.
Yes, that's something I tried to say
when talking about the interrupt gates
(sorry if I wasn't clear).
If upon
irq-return we then
401 - 500 of 694 matches
Mail list logo
