On 3/8/07, Linus Torvalds [EMAIL PROTECTED] wrote:
Which is why you introduced a new system call, but that leads to all the
problems with the file descriptor no longer being *usable*.
Think scripts. It's easy to do reads in perl scripts, and parse the
output. In contrast, making perl use a new
On Saturday 10 March 2007 05:07, Mark Lord wrote:
Mmm.. when it's good, it's *really* good.
My desktop feels snappier and all of that.
No noticeable jerkiness of windows/scrolling,
which I *do* observe with the stock scheduler.
Thats good.
But when it's bad, it stinks.
Like when a make
On Saturday 10 March 2007 07:15, Con Kolivas wrote:
On Saturday 10 March 2007 05:27, Matt Mackall wrote:
On Fri, Mar 09, 2007 at 07:39:05PM +1100, Con Kolivas wrote:
On Friday 09 March 2007 19:20, Matt Mackall wrote:
And I've just rebooted with NO_HZ and things are greatly improved. At
On Fri, 9 Mar 2007, Oliver Neukum wrote:
Adding a new release() callback would solve the problem by creating
another. Drivers need to release their data as soon as possible after
they unbind from a device, not when the device itself goes away. Think
Wait, the callback from closing the
Am Freitag, 9. März 2007 21:27 schrieb Alan Stern:
On Fri, 9 Mar 2007, Oliver Neukum wrote:
Adding a new release() callback would solve the problem by creating
another. Drivers need to release their data as soon as possible after
they unbind from a device, not when the device itself
William Lee Irwin III wrote:
William Lee Irwin III wrote:
I consider policy issues to be hopeless political quagmires and
therefore stick to mechanism. So even though I may have started the
code in question, I have little or nothing to say about that sort of
use for it.
There's my
On Fri, March 9, 2007 20:30, David Brownell wrote:
On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote:
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have a built-in
i2c controller, additional i2c busses, or testing
Am Freitag, 9. März 2007 21:08 schrieb Alan Stern:
After some more thought, I basically agree with what Oliver wrote
originally. sysfs_dirent is indeed the logical place to store the kref
pointer. However it needs to be used during open and release, not during
OK.
read, write, and poll.
This problem and patch were discovered and written by Alan Tyson of HP, who
asked that I post this. The problem is this:
When the CIFS client mounts a share that does not have Unix extensions, it
will turn off the w bits in the file mode if it sees that ATTR_READONLY is
set. It has no
On 03/08, Roland McGrath wrote:
Your change seems fine to me. I certainly concur that it seems insane
for init to be responsible for tasks created magically inside the
kernel. The history I've found says that the setting to SIGCHLD was
introduced as part of v2.5.1.9 - v2.5.1.10, without
On Fri, Mar 09, 2007 at 07:39:05PM +1100, Con Kolivas wrote:
On Friday 09 March 2007 19:20, Matt Mackall wrote:
And I've just rebooted with NO_HZ and things are greatly improved. At
idle, Beryl effects are silky smooth (possibly better than stock) and
shows less load. Under 'make', Beryl is
On Sat, Mar 10, 2007 at 07:26:15AM +1100, Con Kolivas wrote:
How odd. I would have thought that if an interaction was to occur it would
have been without the new feature. Clearly what you describe without NO_HZ
is not the expected behaviour with RSDL. I wonder what went wrong. Are you
on
* Linus Torvalds [EMAIL PROTECTED] wrote:
So please
- point out things that are badly done. [...]
the thing badly done is fundamental and it trumps any other small
technological detail complaint i have, because it affects the
development and maintainance model: to promise backwards
Ingo Molnar wrote:
Once this thing is released upstream, it creates a new compatibility
rule:
_new kernel must not break on an older hypervisor_
Yes, that's important. (It's perhaps more important that a new
hypervisor not break an old kernel, but that's 100% the hypervisor's
Hello,
On Mar 9 2007 20:24, Ingo Molnar wrote:
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 9 Mar 2007, Ingo Molnar wrote:
yes - but we already support the raw hardware ABI, in the native
kernel.
Why do you continue to call paravirt an ABI?
We got over that. It's not. It's an API.
On Saturday 10 March 2007 07:46, Matt Mackall wrote:
Ok, I've now disabled sched_yield (I'm using xorg radeon drivers).
Great.
So far:
rc2-mm2 RSDL RSDL+NO_HZ RSDL+NO_HZ+no_yield estimated CPU
no load
berylgood good great great~30% at 600MHz
On Sat, Mar 10, 2007 at 07:15:38AM +1100, Con Kolivas wrote:
How odd. I would have thought that if an interaction was to occur it would
have been without the new feature. Clearly what you describe without NO_HZ is
not the expected behaviour with RSDL. I wonder what went wrong. Are you on
On Fri, 9 Mar 2007, Ingo Molnar wrote:
_new kernel must not break on an older hypervisor_
Total red herring. AGAIN.
The paravirt_ops isn't a 1:1 hypervisor ABI.
If we change paravirt_ops to be higher-level ops (as we should), yes, the
paravirt-VMI layer needs to be extended to have the
On Sunday 04 March 2007 01:00, Con Kolivas wrote:
This message is to announce the first general public release of the
Rotating Staircase DeadLine cpu scheduler.
Based on previous work from the staircase cpu scheduler I set out to
design, from scratch, a new scheduling policy design which
Hi!
So... if current console is graphical, we leave X accessing the
console... That's bad, because video state is not going to be
restored...?
A graphical console is not necessarily X. Is there any requirement for
there to be a single VT that isn't in text mode? The vt switching
On Friday 09 March 2007 12:08 pm, Russell King wrote:
On Fri, Mar 09, 2007 at 11:30:12AM -0800, David Brownell wrote:
On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote:
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that
Hi!
So... if current console is graphical, we leave X accessing the
console... That's bad, because video state is not going to be
restored...?
A graphical console is not necessarily X. Is there any requirement for
there to be a single VT that isn't in text mode? The vt switching
On Saturday 10 March 2007 08:07, Con Kolivas wrote:
On Saturday 10 March 2007 07:46, Matt Mackall wrote:
My suspicion is the problem lies in giving too much quanta to
newly-started processes.
Ah that's some nice detective work there. Mainline does some rather complex
accounting on
Hi!
Index: linux-2.6.21-rc2-mm2/kernel/power/disk.c
===
--- linux-2.6.21-rc2-mm2.orig/kernel/power/disk.c
+++ linux-2.6.21-rc2-mm2/kernel/power/disk.c
@@ -61,6 +61,7 @@ static void
Hi!
So... if current console is graphical, we leave X accessing the
console... That's bad, because video state is not going to be
restored...?
A graphical console is not necessarily X. Is there any requirement for
there to be a single VT that isn't in text mode? The vt switching is
a
On Friday, 9 March 2007 22:07, Pavel Machek wrote:
Hi!
Index: linux-2.6.21-rc2-mm2/kernel/power/disk.c
===
--- linux-2.6.21-rc2-mm2.orig/kernel/power/disk.c
+++ linux-2.6.21-rc2-mm2/kernel/power/disk.c
On Fri, Mar 09, 2007 at 02:46:24PM -0600, Matt Mackall wrote:
A priori, this load should be manageable by RSDL as the interactive
loads are all pretty small. So I wrote a little Python script that
basically continuously memcpys some 16MB chunks of memory:
#!/usr/bin/python
a = a * 16 * 1024
Hi!
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8100
Summary: dynticks makes ksoftirqd1 use unreasonable amount of cpu
time
Kernel Version: 2.6.21-rc2
Status: NEW
Severity: low
Owner:
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
( if there is no backwards compatibility promise then i have zero
complaints: then paravirt_ops + the hypercall just becomes another API
internal to Linux that we can improve at will. But that is not
realistic: if we provide CONFIG_VMI today,
Hi,
Is there any debug option where I get some memory (from kmalloc() family) for
limited time only.
Once the time slice expires, that memory is zeroed out so that if I use it
again after the time
slice expired, I should see a crash.
-Amit
On Thu, 8 Mar 2007, David M. Lloyd wrote:
On Wed, 2007-03-07 at 17:21 -0800, Davide Libenzi wrote:
int signalfd_dequeue(int fd, siginfo_t *info, long timeo);
The fd parameter must ba a signalfd file descriptor. The info parameter
is a pointer to the siginfo that will receive the
* Linus Torvalds [EMAIL PROTECTED] wrote:
If we change paravirt_ops to be higher-level ops (as we should), yes,
the paravirt-VMI layer needs to be extended to have the
higher-lower translation. But at no point did we break the
hypervisor.
hm. So your point is that VMI is in essence a
Yes sure, this change shoud be tested in -mm tree (I'll send the patch
on Sunday after some testing). The only (afaics) problem is that with
this change a kernel thread must not do do_fork(CLONE_THREAD).
To clarify, the danger here is that an exit_signal=-1 leader would
self-reap and leave
Ingo Molnar wrote:
but ... maybe because VMI is so lowlevel and covers /all/ of x86 today,
it will always be able to emulate whatever different concept we can come
up with? Do we really know this absolutely sure?
Why don't you make a specific proposal, and we'll work out the details.
On Friday 09 March 2007 12:43 pm, Håvard Skinnemoen wrote:
On Fri, March 9, 2007 20:30, David Brownell wrote:
On Friday 09 March 2007 10:48 am, Haavard Skinnemoen wrote:
This is a very simple bitbanging i2c bus driver utilizing the new
arch-neutral GPIO API. Useful for chips that don't have
Hello,
I periodically see the following TCP kernel assertion errors in
/var/log/message
(it does seem that networking is eventually able to recover from these
errors):
kernel: KERNEL: assertion (flags MSG_PEEK) failed at net/ipv4/tcp.c
(1171)
kernel: KERNEL: assertion (flags
* Chris Wright [EMAIL PROTECTED] wrote:
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
( if there is no backwards compatibility promise then i have zero
complaints: then paravirt_ops + the hypercall just becomes another API
internal to Linux that we can improve at will. But that is not
On Sat, Mar 10, 2007 at 08:19:18AM +1100, Con Kolivas wrote:
On Saturday 10 March 2007 08:07, Con Kolivas wrote:
On Saturday 10 March 2007 07:46, Matt Mackall wrote:
My suspicion is the problem lies in giving too much quanta to
newly-started processes.
Ah that's some nice detective
On Saturday 10 March 2007 08:39, Matt Mackall wrote:
On Sat, Mar 10, 2007 at 08:19:18AM +1100, Con Kolivas wrote:
On Saturday 10 March 2007 08:07, Con Kolivas wrote:
On Saturday 10 March 2007 07:46, Matt Mackall wrote:
My suspicion is the problem lies in giving too much quanta to
On Fri, Mar 09, 2007 at 03:39:59PM -0600, Matt Mackall wrote:
On Sat, Mar 10, 2007 at 08:19:18AM +1100, Con Kolivas wrote:
On Saturday 10 March 2007 08:07, Con Kolivas wrote:
On Saturday 10 March 2007 07:46, Matt Mackall wrote:
My suspicion is the problem lies in giving too much quanta
On Fri, 2007-09-03 at 21:13 +, Pavel Machek wrote:
Hi!
So... if current console is graphical, we leave X accessing the
console... That's bad, because video state is not going to be
restored...?
A graphical console is not necessarily X. Is there any requirement for
following up on an earlier post by stefan richter, i wrote a
brute-force little script that scanned the source tree, looking for
header files that weren't included from *anywhere* in the tree. what
turned up was the following:
./arch/m68k/atari/atasound.h
./arch/arm/mach-s3c2410/bast.h
Ingo Molnar wrote:
i am worried whether /any/ future change to the upstream kernel's design
can be adopted via paravirt_ops, via the current VMI ABI. And by /any/ i
mean truly any. And whether that can be done is not a function of the
flexibility of paravirt_ops, it's a function of the
When booting my laptop with a 2.6.20.1 laptop with lockdep enabled to test my
code, I got a lockdep warning on pktcdvd on setup. It seems that do_open on a
pktcdvd device causes another do_open on the underlying device, and that
mutex_lock_nested is called with the same subclass (the for_part
Hi!
...so, if pm_ops is non-null, power_down does nonboot cpu disabling,
otherwise we proceed with cpus enabled?
That looks ugly.
Is the warning bogus? Or maybe we should *always* disable nonboot cpus
in powerdown path?
Is disable_nonboot_cpus() assuming that
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
i am worried whether /any/ future change to the upstream kernel's design
can be adopted via paravirt_ops, via the current VMI ABI. And by /any/ i
mean truly any. And whether that can be done is not a function of the
flexibility of paravirt_ops, it's
On Saturday 10 March 2007 08:57, Willy Tarreau wrote:
On Fri, Mar 09, 2007 at 03:39:59PM -0600, Matt Mackall wrote:
On Sat, Mar 10, 2007 at 08:19:18AM +1100, Con Kolivas wrote:
On Saturday 10 March 2007 08:07, Con Kolivas wrote:
On Saturday 10 March 2007 07:46, Matt Mackall wrote:
Hi!
Index: linux-2.6.21-rc3/kernel/power/user.c
===
--- linux-2.6.21-rc3.orig/kernel/power/user.c
+++ linux-2.6.21-rc3/kernel/power/user.c
@@ -402,9 +402,10 @@ static int snapshot_ioctl(struct inode *
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Now it may be that you've got a change that's absolutely great for
everyone, and the only blocker is that the FoobieVisor can't deal with
it. OK, great, then you'd have a point.
yep. That's precisely my worry. And it doesnt have to be a
On Saturday 10 March 2007 08:57, Con Kolivas wrote:
On Saturday 10 March 2007 08:39, Matt Mackall wrote:
On Sat, Mar 10, 2007 at 08:19:18AM +1100, Con Kolivas wrote:
On Saturday 10 March 2007 08:07, Con Kolivas wrote:
On Saturday 10 March 2007 07:46, Matt Mackall wrote:
My suspicion
from what I understood, there is a performance loss in plugsched
schedulers because they have to share code
even if pluggable schedulers is not a viable option, being able to
choose which one was built into the kernel would be easy (only takes a
few ifdefs), i too think competition would be
On Fri, 2007-03-09 at 17:11 +0100, Andi Kleen wrote:
David Woodhouse [EMAIL PROTECTED] writes:
Most system calls seem to get added to i386 first. This patch
automatically generates a warning for any new system call which is
implemented on i386 but not the architecture currently being
On Fri, 2007-03-09 at 17:11 +0100, Andi Kleen wrote:
Of course the existing syscall numbers can't be changed, but for all new
calls one could just add automatically for everybody.
A global table with two entries (compat and non compat) and a per arch
override table should be sufficient.
On Fri, 09 Mar 2007 08:19:36 -0500 Mimi Zohar wrote:
On Thu, 2007-03-08 at 15:08 -0800, Randy Dunlap wrote:
On Thu, 08 Mar 2007 17:58:16 -0500 Mimi Zohar wrote:
This is a request for comments for a new Integrity Based Access
Control(IBAC) LSM module which bases access control
We need additional gunk for syscalls that can be called from SPEs on
cell
Can that gunk not be auto generated?
I know s390 does in some cases, but it looks quite auto generatable to me.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Not everybody has a simple indexed list of pointers :) For example,
for vax-linux, we use a struct per syscall with the expected number of
on-stack longwords for the call.
So if something new is coming up, please keep in mind that it should
be flexible enough to represent that. :)
Are
On Fri, 2007-03-09 20:00:51 +0100, Andi Kleen [EMAIL PROTECTED] wrote:
Not everybody has a simple indexed list of pointers :) For example,
for vax-linux, we use a struct per syscall with the expected number of
on-stack longwords for the call.
So if something new is coming up, please
Jan-Benedict Glaw wrote:
Not everybody has a simple indexed list of pointers :) For example,
for vax-linux, we use a struct per syscall with the expected number of
on-stack longwords for the call.
So if something new is coming up, please keep in mind that it should
be flexible enough to
On Fri, Mar 09, 2007 at 11:40:08AM -0800, H. Peter Anvin wrote:
Jan-Benedict Glaw wrote:
Not everybody has a simple indexed list of pointers :) For example,
for vax-linux, we use a struct per syscall with the expected number of
on-stack longwords for the call.
So if something new is
Tosoni [EMAIL PROTECTED] writes:
OTOH I wonder what does the device in question require WRT the
serial port and WRT RTS line in particular.
I know there are some half-duplex converters which drive RTS only
while sending and which require CTS to send.
As far as I know in the old times this
Russell King wrote:
On Fri, Mar 09, 2007 at 11:40:08AM -0800, H. Peter Anvin wrote:
Jan-Benedict Glaw wrote:
Not everybody has a simple indexed list of pointers :) For example,
for vax-linux, we use a struct per syscall with the expected number of
on-stack longwords for the call.
So if
Hi, Pavel,
Please find my patch to add LRU behaviour to your latest RSS controller.
Balbir Singh
Linux Technology Center
IBM, ISTL
Add LRU behaviour to the RSS controller patches posted by Pavel Emelianov
http://lkml.org/lkml/2007/3/6/198
which was in turn similar to the RSS controller
On Fri, 9 Mar 2007 07:18:56 +, Pavel Machek wrote:
Port (and memory) addresses can be dynamically generated by the AML code
and thus, there is no way that the ACPI subsystem can statically predict
any addresses that will be accessed by the AML.
Can you take this as a wishlist item?
Jean Delvare wrote:
On Fri, 9 Mar 2007 07:18:56 +, Pavel Machek wrote:
Port (and memory) addresses can be dynamically generated by the AML code
and thus, there is no way that the ACPI subsystem can statically predict
any addresses that will be accessed by the AML.
Can you take
Hi!
Can you take this as a wishlist item?
It would be nice if next version of acpi specs supported table
'AML / SMM BIOS will access these ports'
...so we can get it correct with acpi4 or something..?
I can only second Pavel's wish here. This would be highly convenient
for OS
Hi Alexey,
On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote:
Jean Delvare wrote:
I can only second Pavel's wish here. This would be highly convenient
for OS developers to at least know which resources are accessed by AML
and SMM. Without this information, we can never be sure
Jean Delvare wrote:
Hi Alexey,
On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote:
Jean Delvare wrote:
I can only second Pavel's wish here. This would be highly convenient
for OS developers to at least know which resources are accessed by AML
and SMM. Without this
Included the Intel ACPI spec representative.
I have heard that Windows is somehow restricting the ports and memory
locations that are accessible via AML; I don't know any of the details.
Also, there are fears of an AML virus attacking the machine.
Bob
-Original Message-
From: Pavel
No ACPI discussion can be complete without mentioning Microsoft and
Microsoft compatibility -- Windows does not fully support ACPI 2.0 to
this day, even though it was released in the year 2000, and ACPI 3.0 has
been out since 2004.
-Original Message-
From: Alexey Starikovskiy
On Fri, Mar 09, 2007 at 12:23:55PM +0300, Kirill Korotaev wrote:
There have been various projects attempting to provide
resource management support in Linux, including
CKRM/Resource Groups and UBC.
let me note here, once again, that you forgot Linux-VServer
which does quite non-intrusive
On Fri, Mar 09, 2007 at 12:07:27PM +0300, Kirill Korotaev wrote:
nobody actually cares about a precise accounting and
calculating shares or partitions of whatever resource,
all that matters is that you have a way to prevent a
potential hostile environment from sucking up all your
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Wed, Mar 07, 2007 at 08:12:00PM -0700, Eric W. Biederman wrote:
I have a question? What does rcfs look like if we start with
the code that is in the kernel? That is start with namespaces
and nsproxy and just build a filesystem to
On Wed, Mar 07, 2007 at 01:20:18PM -0800, Paul Menage wrote:
On 3/7/07, Serge E. Hallyn [EMAIL PROTECTED] wrote:
All that being said, if it were going to save space without overly
complicating things I'm actually not opposed to using nsproxy, but it
If space-saving is the main issue, then
On Fri, Mar 09, 2007 at 10:04:30PM +0530, Srivatsa Vaddagiri wrote:
2. Regarding space savings, if 100 tasks are in a container (I dont know
what is a typical number) -and- lets say that all tasks are to share
the same resource allocation (which seems to be natural), then having
a
Quoting Paul Menage ([EMAIL PROTECTED]):
On 3/7/07, Sam Vilain [EMAIL PROTECTED] wrote:
Ok, they share this characteristic with namespaces: that they group
processes.
Namespaces have a side effect of grouping processes, but a namespace is
not defined by 'grouping proceses.' A container is,
On Fri, Mar 09, 2007 at 01:38:19AM +0100, Herbert Poetzl wrote:
2) you allow a task to selectively reshare namespaces/subsystems with
another task, i.e. you can update current-task_proxy to point to
a proxy that matches your existing task_proxy in some ways and the
task_proxy of
On Fri, Mar 09, 2007 at 01:48:16AM +0100, Herbert Poetzl wrote:
There have been various projects attempting to provide resource
management support in Linux, including CKRM/Resource Groups and UBC.
let me note here, once again, that you forgot Linux-VServer
which does quite non-intrusive
On Fri, Mar 09, 2007 at 01:53:57AM +0100, Herbert Poetzl wrote:
The real trick is that I believe these groupings are designed to
be something you can setup on login and then not be able to switch
out of. Which means we can't use sessions and process groups as the
grouping entities as those
On Fri, Mar 09, 2007 at 02:16:08AM +0100, Herbert Poetzl wrote:
On Thu, Mar 08, 2007 at 05:00:54PM +0530, Srivatsa Vaddagiri wrote:
On Thu, Mar 08, 2007 at 01:50:01PM +1300, Sam Vilain wrote:
7. resource namespaces
It should be. Imagine giving 20% bandwidth to a user X. X wants to
Ease of use maybe. Scripts can be more readily used with a fs-based
interface.
And, as I might have already stated, file system API's are a natural
fit for hierarchically shaped data, especially if the nodes in the
hierarchy would benefit from file system like permission attributes.
--
Herbert wrote (and vatsa quoted):
precisely, once you are inside a resource container, you
must not have the ability to modify its limits, and to
some degree, you should not know about the actual available
resources, but only about the artificial limits
Not necessarily. Depending on the
On Fri, Mar 09, 2007 at 11:49:08PM +0530, Srivatsa Vaddagiri wrote:
On Fri, Mar 09, 2007 at 01:53:57AM +0100, Herbert Poetzl wrote:
The real trick is that I believe these groupings are designed to
be something you can setup on login and then not be able to switch
out of. Which means we can't
the emphasis here is on 'from inside' which basically
boils down to the following:
if you create a 'resource container' to limit the
usage of a set of resources for the processes
belonging to this container, it would be kind of
defeating the purpose, if you'd allow the processes
to
Hi Pete,
On 2/28/07, Pete Zaitcev [EMAIL PROTECTED] wrote:
If a process is closing /dev/input/mice and an mouse disconnects simulta-
neously, the system is likely to oops. This usually happens when someone
hits AltCtrlF1 or logs out from X, and flips a KVM while the system
is reacting.
I
On Fri, 9 Mar 2007 09:28:49 -0500, Dmitry Torokhov [EMAIL PROTECTED] wrote:
On 2/28/07, Pete Zaitcev [EMAIL PROTECTED] wrote:
Dmitry, please consider getting rid of the list of handles entirely.
The other major user is drivers/char/keyboard.c.
I agree that handlers should not access
On 3/9/07, Pete Zaitcev [EMAIL PROTECTED] wrote:
On Fri, 9 Mar 2007 09:28:49 -0500, Dmitry Torokhov [EMAIL PROTECTED] wrote:
On 2/28/07, Pete Zaitcev [EMAIL PROTECTED] wrote:
Dmitry, please consider getting rid of the list of handles entirely.
The other major user is
Hi all,
I've just compiled and installed 2.6.21-rc3 on my Dual CPU Dell
Precision 610MT system. Dual 550mhz Xeon, 768mb of RAM. Mix of SCSI,
ATA drives. I'm using the new ATA_ drivers for my PATA disks.
After booting, I pulled my seldom used USB-serial device from the
system to toss in my
On Fri, Mar 09, 2007 at 10:40:21AM -0500, John Stoffel wrote:
Hi all,
I've just compiled and installed 2.6.21-rc3 on my Dual CPU Dell
Precision 610MT system. Dual 550mhz Xeon, 768mb of RAM. Mix of SCSI,
ATA drives. I'm using the new ATA_ drivers for my PATA disks.
After booting, I
* Linus Torvalds [EMAIL PROTECTED] wrote:
disabling the following radeonfb options in the .config made resume
work again:
In general, don't even *try* to use radeonfb for suspend/resume.
I don't think it has ever worked, except on some very rare laptops
(largely PPC Macs) where
Hi!
disabling the following radeonfb options in the .config made resume work
again:
In general, don't even *try* to use radeonfb for suspend/resume.
I don't think it has ever worked, except on some very rare laptops
(largely PPC Macs) where people had enough information to set up the
On Fri, 9 Mar 2007, Ingo Molnar wrote:
Some day we may have modesetting support in the kernel for some
graphics hw, right now it's pretty damn spotty.
having no video is what i'd have expected - but getting a /hang/ is not
what i'd have expected.
I debugged a case exactly like this
On Thu, Mar 08, 2007, Linus Torvalds wrote:
On Fri, 9 Mar 2007, Ingo Molnar wrote:
disabling the following radeonfb options in the .config made resume work
again:
In general, don't even *try* to use radeonfb for suspend/resume.
I don't think it has ever worked, except on some very
Andrew Morton wrote:
On Mon, 26 Feb 2007 17:48:55 -0600 Marc St-Jean
[EMAIL PROTECTED] wrote:
[PATCH] drivers: PMC MSP71xx LED driver
Patch to add LED driver for the PMC-Sierra MSP71xx devices.
This patch references some platform support files previously
submitted to the
On Fri, Mar 09, 2007 at 09:16:35PM +0100, Jan Engelhardt wrote:
On Mar 9 2007 20:00, Sam Ravnborg wrote:
On Thu, Mar 08, 2007 at 11:01:57PM +0100, Jan Engelhardt wrote:
Since Solaris seems to be on the run, I did myself try compile it.
However, unlike the original poster who said he
* Chris Wright [EMAIL PROTECTED] wrote:
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
i am worried whether /any/ future change to the upstream kernel's design
can be adopted via paravirt_ops, via the current VMI ABI. And by /any/ i
mean truly any. And whether that can be done is not a
On Fri, 9 Mar 2007, Ingo Molnar wrote:
hm. So your point is that VMI is in essence a Turing machine (a
near-complete one)? No matter what redesign we do on the Linux side, the
VMI paravirt_ops will always be able to adopt to it?
No, I don't think it's turing-complete ;)
But since it
Ingo Molnar wrote:
yep. That's precisely my worry. And it doesnt have to be a 'great' thing
- just any random small change in the kernel that makes sense: what is
the likelyhood that it cannot be implemented, no matter what amount of
insight, paravirt_ops + hyper-ABI emulation hackery, for
On Friday, 9 March 2007 23:13, Pavel Machek wrote:
Hi!
Index: linux-2.6.21-rc3/kernel/power/user.c
===
--- linux-2.6.21-rc3.orig/kernel/power/user.c
+++ linux-2.6.21-rc3/kernel/power/user.c
@@ -402,9 +402,10 @@
Hi, I am encountering a performance problem, which I have tracked into the
Linux kernel. The problem occurs with my experimental web server that uses
sendfile to repeatedly transmit files. The files are based on the static
portion of the SPECweb99 fileset and range in size to model a
On Sat, Mar 10, 2007 at 09:12:07AM +1100, Con Kolivas wrote:
(...)
Matt, could you check with plain 2.6.20 + Con's patch ? It is possible
that he added bugs when porting to -mm, or that someting in -mm causes
the trouble. Your experience with -mm seems so much different from mine
with
201 - 300 of 1046 matches
Mail list logo
