Matthew Wilcox wrote:
On Tue, Feb 01, 2005 at 11:35:05AM -0600, Brian King wrote:
If we've done a write to config space while the adapter was blocked,
shouldn't we replay those accesses at this point?
I did not think that was necessary.
We have to do *something*. We can't just throw away writes.
[Xavier Bestel]
> Le mercredi 02 février 2005 à 15:21 +0100, Haakon Riiser a
> écrit :
>> How can I use a frame buffer driver's optimized copyarea,
>> fillrect, blit, etc. from userspace? The only way I've ever
>> seen anyone use the frame buffer device is by mmap()ing it
>> and doing
Vivek Goyal <[EMAIL PROTECTED]> writes:
> On Tue, 2005-02-01 at 20:56, Eric W. Biederman wrote:
> > Vivek Goyal <[EMAIL PROTECTED]> writes:
>
> "elfcorehdr=" also looks good.
Then let's go with that for now. It is not perfect but it seems
a little more self explanatory at first glance.
> > A
On Wed, 02 Feb 2005 11:22:43 +0100, Victor Hahn <[EMAIL PROTECTED]> wrote:
> Dmitry Torokhov wrote:
>
> >It still complains in dmesg about throwing away bytes, right? Please try
> >loading the box some more to make sure mouse survives some abuse.
> >
> >
>
> No, it doesn't. The only message I
On Wed, Feb 02, 2005 at 03:21:55PM +0100, Haakon Riiser wrote:
> > X-Windows already does this.
>
> Yeah, I thought the X11 fbdev driver supported acceleration, but not
> according to its manpage:
>
> fbdev is an Xorg driver for framebuffer devices. This is a
> non-accelerated driver [...]
On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 01, 2005 at 11:41:48PM -0800, Pete Zaitcev wrote:
> > On 30 Jan 2005 12:10:34 +0100, Peter Osterlund <[EMAIL PROTECTED]> wrote:
> >
> > > > - Slow motion of finger produces no motion, then a jump. So, it's
Hi,
I've played lately a bit with Subversion and used it for managing
the kernel sources, using Larry McVoy's bk2cvs bridge and Ben Collins'
bkcvs2svn conversion script.
Since there is little information on the web on how to properly
set up a SVN repository and use it for tracking the latest
On Wed, Feb 02, 2005 at 10:51:38AM -0500, Dmitry Torokhov wrote:
> I wonder if we should just add speed factor (along with tap distance)
> options to mousedev. Vojtech, will you take such patch? I know you
> want to drop mousedev and have everyone use evdev but, although people
> started
[trimming the Cc: list]
> * Jack O'Quin <[EMAIL PROTECTED]> wrote:
>> Remember when I asked how you handle changes to sizeof(struct rusage)?
>> That was a serious question. I hope there's a solution. [...]
Ingo Molnar <[EMAIL PROTECTED]> writes:
> what does any of what we've talking about have
Hello,
I have been told that dm_snapshot is still experimental in the 2.6.10
kernel, and I was advised not to have more than one snapshot created
at a time for the same logical volume.
Basically I am just wondering what the potential problems are with
dm_snapshot. Is there anything particular
(first sorry for my poor English)
Very nice howto. It's useful for generic use of svn too.
The notations about converting bk to svn is really interesting... nice job!
Just a little error:
How to I ignore temporary build files ? <- to should be do
I would add this rule as a personal
Positive, I only applied this single two-line change. I'm not capable of
messing with kernel code myself so I prefer not to. Probably just a lucky
shot that the vesa didn't go nuts with nvidia before... O well, with a bit
more o'those pharmaceutical drugs even this 80x25 doesn't look too bad.
On Wed, 2 Feb 2005, Lennert Van Alboom wrote:
>
> I applied the patch and it works like a charm. As a kinky side effect: before
> this patch, using a compiled-in vesa or vga16 framebuffer worked with the
> proprietary nvidia driver, whereas now tty1-6 are corrupt when not using
> 80x25.
Add access control lists for tmpfs. There is more code in tmpfs itself
than in the generic acl layer, but at least the acl handling
complexities are hidden from the filesystem.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm2/mm/shmem.c
/dev/pts is somewhat special: there are no directories, and so we
don't need default acls.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm2/fs/devpts/inode.c
===
---
Add some infrastructure for access control lists on in-memory
filesystems such as tmpfs and devpts. We can probably also use
this code from ext2 and ext3, but this hasn't been started, yet.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Index: linux-2.6.11-rc2-mm2/fs/Kconfig
Here is a set of three patches which implement some general
infrastructure and on top of that, acls for tmpfs and /dev/pts files.
We may want to factor out some of the current ext2 and ext3 acl code
and use the generic layer instead. Comments welcome.
Regards,
--
Andreas Gruenbacher <[EMAIL
On Tue, 2005-02-01 at 09:06 -0700, Tom Rini wrote:
> is unsafe for inclusion by userland apps, but it
> is in the userland-exposed portion of . It's only needed
> in the __KERNEL__ protected portion of the file, so move the #include
> down to there.
You accidentally posted this patch to the
THIS IS AN AUTOMATED RESPONSE. DO NOT RESPOND TO THIS EMAIL.
Thank you for your comments. Customer Service
emails are answered in the order in which they are received.
The department is closed on weekends and holidays and there
will be a delay in response for comments sent during these
times.
On Wed, 2 Feb 2005 16:41:39 +0100, Haakon Riiser
<[EMAIL PROTECTED]> wrote:
> Thanks for the tip, I hadn't heard about it. I will take a look,
> but only to see if it can show me the user space API of /dev/fb.
> I don't need a general library that supports a bunch of different
> graphics cards.
On Wed, Feb 02, 2005 at 04:21:23PM +, David Woodhouse wrote:
> On Tue, 2005-02-01 at 09:06 -0700, Tom Rini wrote:
> > is unsafe for inclusion by userland apps, but it
> > is in the userland-exposed portion of . It's only needed
> > in the __KERNEL__ protected portion of the file, so move the
(first sorry for my poor English)
Very nice howto. It's useful for generic use of svn too.
The notations about converting bk to svn is really interesting... nice job!
Just a little error:
How to I ignore temporary build files ? <- to should be do
I would add this rule as a personal
Bill Huey (hui) <[EMAIL PROTECTED]> writes:
> Also, as media apps get more sophisticated they're going to need some
> kind of access to the some traditional softirq facilities, possibily
> migrating it into userspace safely somehow, with how it handles IO
> processing such as iSCSI, FireWire,
Hi Pete,
> > I think if cat is the prefered tool for viewing this file then it should
> > be more human readable. If not, then a binary format should be choosen.
> > Maybe we can implement both. Is this possible?
>
> Yes. Now you know why files were split as they were.
still no reason for me to
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> your concerns would be valid if this was impossible to achieve by an
> exploit, sadly, you'd be wrong too, it's possible to force an
> exploited application to call something like
> dl_make_stack_executable() and then execute the shellcode. [...]
On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> Well, you removed the scaling to the touchpad resolution, which will
> cause ALPS touchpad to be significantly slower than Synaptics touchpads.
> Similarly, the screen size used to be taken into account, but probably
>
On Wed, Feb 02, 2005 at 05:13:40PM +0100, Andreas Gruenbacher wrote:
> Here is a set of three patches which implement some general
> infrastructure and on top of that, acls for tmpfs and /dev/pts files.
Why would you want ACLs on /dev/pts?
-
To unsubscribe from this list: send the line
On Wed, Feb 02, 2005 at 08:56:28AM -0800, Pete Zaitcev wrote:
> On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
>
> > Well, you removed the scaling to the touchpad resolution, which will
> > cause ALPS touchpad to be significantly slower than Synaptics touchpads.
> >
Alexey Dobriyan wrote:
On Tue, 01 Feb 2005 10:54:32 -0700, Mark A. Greer wrote:
+struct mv64xxx_i2c_data {
+ void *reg_base;
ioremap() returns "void __iomem *".
Okay.
+static void __devexit
+mv64xxx_i2c_unmap_regs(struct mv64xxx_i2c_data *drv_data)
+{
+ if (!drv_data->reg_base) {
+
On Wed, Feb 02, 2005 at 11:02:49AM -0500, Kristina Clair wrote:
> I have been told that dm_snapshot is still experimental in the 2.6.10
> kernel, and I was advised not to have more than one snapshot created
> at a time for the same logical volume.
Each snapshot is independent and keeps its own
On Wed, 2005-02-02 at 17:55, Christoph Hellwig wrote:
> On Wed, Feb 02, 2005 at 05:13:40PM +0100, Andreas Gruenbacher wrote:
> > Here is a set of three patches which implement some general
> > infrastructure and on top of that, acls for tmpfs and /dev/pts files.
>
> Why would you want ACLs on
[Jon Smirl]
> On Wed, 2 Feb 2005 16:41:39 +0100, Haakon Riiser
> <[EMAIL PROTECTED]> wrote:
>> Thanks for the tip, I hadn't heard about it. I will take a look,
>> but only to see if it can show me the user space API of /dev/fb.
>> I don't need a general library that supports a bunch of different
I think there's still something funky going on in the pipe code, at
least in 2.6.11-rc2-mm2, which does contain the misordered __free_page()
fix in pipe.c. I'm noticing any leak pretty easily because I'm
attempting memory removal of highmem areas, and these apparently leaked
pipe pages the only
On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 02, 2005 at 08:56:28AM -0800, Pete Zaitcev wrote:
> > On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> >
> > > Well, you removed the scaling to the touchpad resolution, which
On Wed, Feb 02, 2005 at 09:34:21AM -0700, Tom Rini wrote:
> On Wed, Feb 02, 2005 at 04:21:23PM +, David Woodhouse wrote:
> > On Tue, 2005-02-01 at 09:06 -0700, Tom Rini wrote:
> > > is unsafe for inclusion by userland apps, but it
> > > is in the userland-exposed portion of . It's only
On Wed, Feb 02, 2005 at 10:18:27PM +1000, [EMAIL PROTECTED] wrote:
> your concerns would be valid if this was impossible to achieve by an
> exploit, sadly, you'd be wrong too, it's possible to force an exploited
> application to call something like dl_make_stack_executable() and then
> execute the
I've got a simple test app that tries to mmap() and mlock() an amount of
memory specified on the commandline.
If I specify more than the amount of physical memory in the system, I
get different behaviours between ppc and ppc64.
With the ppc kernel, my mmap() call will eventually fail and
When I compile and run the following program:
#include
int main(int x, char **y)
{
pause();
}
... as:
./xxx `yes`
... the following occurs after about 30 seconds (your mileage
may vary):
Additional sense: Peripheral device write fault
end_request: I/O error, dev sdb, sector 34605780
SCSI
On Wed, 2 Feb 2005, Dave Hansen wrote:
>
> In any case, I'm running a horribly hacked up kernel, but this is
> certainly a new problem, and not one that I've run into before. Here's
> output from the new CONFIG_PAGE_OWNER code:
Hmm.. Everything looks fine. One new thing about the pipe code is
Additional information:
My swap-file is also on /dev/sdb2. It appears as though swap
is being written beyond the end of the SCSI device and the
device doesn't like it. Also on a subsequent re-boot the
signature in the swap file had been destroyed so that swapon
didn't like it. I needed to use
On Thu, Jan 27, 2005 at 12:15:24PM +, David Woodhouse wrote:
> On Fri, 2005-01-21 at 12:29 -0800, Christoph Lameter wrote:
> > Adds management of ZEROED and NOT_ZEROED pages and a background daemon
> > called scrubd. scrubd is disabled by default but can be enabled
> > by writing an order
Marcelo Tosatti wrote:
On Tue, Jan 25, 2005 at 11:00:22AM +0300, Vasily Averin wrote:
You should unlock io_request_lock before msleep, like in latest versions
of megaraid2 drivers.
Andrey,
Can you please update your patch to unlock io_request_lock before sleeping
and locking after coming back?
While testing an older driver on an -RT kernel (currently using
-V0.7.37-03), I noticed something strange.
The driver was triggering a "sleeping function called from invalid
context" BUG(). It was coming from a case where the driver was doing
a __get_free_page(GFP_ATOMIC) while interrupts were
On Wed, 2 Feb 2005, linux-os wrote:
When I compile and run the following program:
./xxx `yes`
It looks like the program itself doesn't matter, since it's
bash that's eating up memory like crazy, until the point where
it is OOM killed.
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+
linux-os <[EMAIL PROTECTED]> writes:
> When I compile and run the following program:
>
> #include
> int main(int x, char **y)
> {
> pause();
> }
> ... as:
>
> ./xxx `yes`
This is roughly equivalent to this:
#include
int main(void) { while (1) malloc(1); }
Andreas.
--
Andreas Schwab,
Hi,
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Michael Brade
>Sent: Tuesday, February 01, 2005 3:58 AM
>To: linux-kernel@vger.kernel.org
>Subject: Linux hangs during IDE initialization at boot for 30 sec
>
[snip]
>
>I found additional lines in
On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote:
> Marcelo Tosatti wrote:
> >On Tue, Jan 25, 2005 at 11:00:22AM +0300, Vasily Averin wrote:
> >>You should unlock io_request_lock before msleep, like in latest versions
> >>of megaraid2 drivers.
> >
> >Andrey,
> >
> >Can you please
On Tue, 2005-02-01 at 23:10 -0600, Jack O'Quin wrote:
> > So in the Linux core code we have zero tolerance on crap. We are
> > doing this for the long-term fun of it.
>
> So, we should never do anything boring, even though people actually
> need it?
>
> The fact that a large group of
On Wed, 2005-02-02 at 10:27 -0800, Linus Torvalds wrote:
> How many of these pages do you see? It's normal for a single pipe to be
> associated with up to 16 pages (although that would only happen if there
> is no reader or a slow reader, which is obviously not very common).
Strangely enough,
On Wed, 2 Feb 2005, Marcelo Tosatti wrote:
> Sounds very interesting idea to me. Guess it depends on whether the cost of
> DMA write for memory zeroing, which is memory architecture/DMA engine
> dependant,
> offsets the cost of CPU zeroing.
>
> Do you have any thoughts on that?
>
> I wonder if
On Wed, Feb 02, 2005 at 09:58:51AM -0800, Pete Zaitcev wrote:
> On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Feb 02, 2005 at 08:56:28AM -0800, Pete Zaitcev wrote:
> > > On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik <[EMAIL PROTECTED]>
> > >
On Wed, 02 Feb 2005 17:40:17 +0100, Marcel Holtmann <[EMAIL PROTECTED]> wrote:
> While I am really thinking about starting usbdump, I may ask why you
> have choosen to use debugfs as interface. This will not be available in
> normal distribution kernels and I think a general USB monitoring
> On Tue, 2005-02-01 at 23:10 -0600, Jack O'Quin wrote:
>> Is nobody responsible for figuring out what users need? I didn't
>> realize kernel development had become so disconnected.
Lee Revell <[EMAIL PROTECTED]> writes:
> IMHO the requirements gathering process usually works well. When
>
> > Le mercredi 02 février 2005 à 15:21 +0100, Haakon Riiser a
> > écrit :
>
> >> How can I use a frame buffer driver's optimized copyarea,
> >> fillrect, blit, etc. from userspace? The only way I've ever
> >> seen anyone use the frame buffer device is by mmap()ing it
> >> and doing everything
On Wed, 2 Feb 2005, Frank klein wrote:
1. For explaining the internals of a filesystem in
detail, I need to take their code from kernel sources
'as it is' in the book. Do I need to take any
permissions from the owner/maintainer regarding this ?
Will it violate any license if reproduce the driver
> > You should look at writing a DRM driver. DRM implements the kernel
> > interface to get 3D hardware running. It is a fully accelerated driver
> > interface. They are located in drivers/char/drm
>
> Have the standard frame buffer drivers been abandoned, even
> for devices that have no 3D
Hi Vasily Averin!
On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote next:
> Marcelo Tosatti wrote:
> >On Tue, Jan 25, 2005 at 11:00:22AM +0300, Vasily Averin wrote:
> >>You should unlock io_request_lock before msleep, like in latest versions
> >>of megaraid2 drivers.
> >
> >Andrey,
Hello Matt
Matt Domsch wrote:
On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote:
Marcelo,
This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible
version that I've seen), taken from latest RHEL3 kernel update. I
believe it should prevent NMI in abort/reset handler.
On Wed, 2 Feb 2005, Haakon Riiser wrote:
> > On Wed, 2 Feb 2005 16:41:39 +0100, Haakon Riiser
> > <[EMAIL PROTECTED]> wrote:
> >> Thanks for the tip, I hadn't heard about it. I will take a look,
> >> but only to see if it can show me the user space API of /dev/fb.
> >> I don't need a general
On Wed, 2 Feb 2005 09:58:51 -0800, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Feb 2005 18:07:27 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Feb 02, 2005 at 08:56:28AM -0800, Pete Zaitcev wrote:
> > > On Wed, 2 Feb 2005 11:20:33 +0100, Vojtech Pavlik <[EMAIL PROTECTED]>
Hello,
I need this patch (against linux-2.6.11-rc2), to keep ide disk sleeping,
when resuming from ACPI S1.
In fact, it's just removing a patch from 22 Jun 2004 by Jens Axboe. He has
told me, that "We can probably kill the patch completely".
So, this is what I'm doing now.
Kind regards, Peter
On Wed, Feb 02, 2005 at 11:39:29AM -0800, Pete Zaitcev wrote:
> On Wed, 2 Feb 2005 20:11:35 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
>
> > It's different hardware. While the ALPS pad delivers X axis in the range
> > of 0 to 1000, the Synaptics pad will give X axis values from approx 1500
Hello Matt
Matt Domsch wrote:
On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote:
This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible
version that I've seen), taken from latest RHEL3 kernel update. I
believe it should prevent NMI in abort/reset handler.
Thanks
On Wed, 2 Feb 2005 20:11:35 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> It's different hardware. While the ALPS pad delivers X axis in the range
> of 0 to 1000, the Synaptics pad will give X axis values from approx 1500
> to approx 5500. This is four times the resolution - the size of the
>-Original Message-
>From: Michael Brade [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, February 02, 2005 11:55 AM
>To: Aleksey Gorelov
>Subject: Re: Linux hangs during IDE initialization at boot for 30 sec
>
>Hi,
>
>> Since you don't care about anything except ide0 & ide1, try to add
>>
[Geert Uytterhoeven]
> mmap() the MMIO registers to userspace, and program the
> acceleration engine from userspace, like DirectFB (and XF*_FBDev
> 3.x for Matrox and Mach64) does.
Right, this was how I originally intended to do it. The reason
why I started to obsess about the accelerated
I tried to send a Cc of a patch in a file in the Linux kernel that is
credited to Pedro Roque Marques, but the email bounced.
The patch below (already ACK'ed by Pedro Roque Marques) updates his
email address.
This patch was already included in Marcelo's 2.4 tree.
Signed-off-by: Adrian Bunk
Matt Domsch wrote:
On Wed, Feb 02, 2005 at 09:42:02PM +0300, Vasily Averin wrote:
This is megaraid2 driver update (2.10.8.2 version, latest 2.4-compatible
version that I've seen), taken from latest RHEL3 kernel update. I
believe it should prevent NMI in abort/reset handler.
Thanks Vasily, I was
Hello,
This is the unique announcement that will be sent to LKML.
I'm maintaining a small patch against the -mm tree that might be useful to
other people.
Almost every time Andrew releases a new -mm version, it brings nice bug
fixes, and it also often introduces new exciting
* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> The LSM was a stop-gap measure intended to tide us over until a real
> fix could be "done right" for 2.8. It had the advantage of being
> minimally disruptive to the kernel and its maintainability. [...]
i'm not opposed to the LSM solution per se,
Hi!
I pretty much screwed up in the last update you merged for 2.6.11,
making USB input devices rather annoying to use. These four patches fix
the damage made:
1) The MUX mode disabling had a bug that caused it to not work at
all.
2) MSC_SCAN events backpropagating into hid-input.c caused a
You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/for-linus
===
[EMAIL PROTECTED], 2005-01-28 21:11:52+01:00, [EMAIL PROTECTED]
input: Fix MUX mode disabling.
Signed-off-by: Vojtech Pavlik <[EMAIL
* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> I guess you're right, Lee. I hadn't thought of it that way. It just
> looks broken to me because we have no standing in any normal kernel
> requirements process. That's a shame, but it does seem less like a
> systemic issue.
you have just as much
On Wed, Feb 02, 2005 at 10:32:28PM +0300, Vasily Averin wrote:
> >As a hack, one could #define inline /*nothing*/ in megaraid2.h to
> >avoid this, but it would be nice if the functions could all get
> >reordered such that inlining works properly, and the need for function
> >declarations in
Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
>
> What are your thoughts about inclusion of Mel's allocator work on -mm ?
It's sitting in my to-do pile.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/for-linus
===
[EMAIL PROTECTED], 2005-01-29 12:27:56+01:00, [EMAIL PROTECTED]
input: Document the atkbd.softraw module parameter.
From: Andries Brouwer
You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/for-linus
===
[EMAIL PROTECTED], 2005-02-02 17:54:35+01:00, [EMAIL PROTECTED]
input: Fix HID LED mapping. LEDs were ignored because the usage
value
Christoph Hellwig wrote:
On Mon, Jan 31, 2005 at 04:45:05PM -0600, Pat Gefre wrote:
Please kill ioc4_ide_init as it's completely unused and make ioc4_serial_init
a normal module_init() handler in ioc4_serial, there's no need to call
them from the generic driver.
I want ioc4_serial_init called
You can pull this changeset from:
bk://kernel.bkbits.net/vojtech/for-linus
===
[EMAIL PROTECTED], 2005-01-29 13:09:24+01:00, [EMAIL PROTECTED]
input: Ignore non-LED events in hid-input hidinput_event(). This gets rid
Hi Andrew,
What are your thoughts about inclusion of Mel's allocator work on -mm ?
On Wed, Feb 02, 2005 at 12:31:36AM +, Mel Gorman wrote:
> On Tue, 1 Feb 2005, Christoph Lameter wrote:
>
> > On Tue, 1 Feb 2005, Mel Gorman wrote:
> >
> > > > Would it not be better to zero the global
Pete Zaitcev <[EMAIL PROTECTED]> writes:
> On 30 Jan 2005 12:10:34 +0100, Peter Osterlund <[EMAIL PROTECTED]> wrote:
>
> > > - Slow motion of finger produces no motion, then a jump. So, it's very
> > > hard to
> > > target smaller UI elements and some web links.
> >
> > I see this too when I
The patch below makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 21 Nov 2004
drivers/video/savage/savagefb.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
---
On Wed, 2 Feb 2005, Marcelo Tosatti wrote:
> > Some architectures tend to have spare DMA engines lying around. There's
> > no need to use the CPU for zeroing pages. How feasible would it be for
> > scrubd to use these?
[...]
> I suppose you are talking about DMA engines which are not being driven
On Mon, Jan 17, 2005 at 08:56:04PM -0500, Michael H. Warfield wrote:
> On Sat, Jan 01, 2005 at 06:28:32PM +0100, Adrian Bunk wrote:
>...
> > It seems you are still active :-) , so why is it "Orphaned"?
>
> Good question. Probably someone jumping the gun a bit because
> I haven't been very
On Wed, Feb 02, 2005 at 11:05:14AM -0800, Christoph Lameter wrote:
> On Wed, 2 Feb 2005, Marcelo Tosatti wrote:
>
> > Sounds very interesting idea to me. Guess it depends on whether the cost of
> > DMA write for memory zeroing, which is memory architecture/DMA engine
> > dependant,
> > offsets
On Wed, Feb 02, 2005 at 10:44:22AM -0600, Jack O'Quin wrote:
> Bill Huey (hui) <[EMAIL PROTECTED]> writes:
> > Also, as media apps get more sophisticated they're going to need some
> > kind of access to the some traditional softirq facilities, possibily
> > migrating it into userspace safely
>From looking at the dm_crypt code, it appears that it can be
interrogated to report the current key. Some quick testing shows:
# dmsetup table /dev/mapper/volume1
0 200 crypt aes-plain 0123456789abcdef0123456789abcdef 0 7:0 0
Obviously, root can in principle recover this password from the
On Wed, 02 Feb 2005 13:07:21 -0800 (PST), Peter Osterlund
<[EMAIL PROTECTED]> wrote:
> + if (mousedev->pkt_count >= 2) {
> + tmp = ((fx(0) - fx(2)) * (250 *
> FRACTION_DENOM)) / size;
> + tmp
On Wed, 2005-02-02 at 21:00 +, Maciej W. Rozycki wrote:
> E.g. the Broadcom's MIPS64-based SOCs have four general purpose DMA
> engines onchip which can transfer data to/from the memory controller in
> 32-byte chunks over the 256-bit internal bus. We have hardly any use for
> these
On Wed, Feb 02, 2005 at 10:21:00PM +0100, Ingo Molnar wrote:
> yes and no. You are right in that the individual workloads (e.g.
> softirqs) are not separated and identified/credited to the thread that
> requested them. (in part due to the fact that you cannot e.g. credit a
> thread for e.g.
Oleg Nesterov wrote:
This patch introduces make_ahead_window() function for
simplification of page_cache_readahead.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- 2.6.11-rc2/mm/readahead.c~ 2005-01-27 22:14:39.0 +0300
+++ 2.6.11-rc2/mm/readahead.c 2005-01-29 15:51:04.0
On Wed, 2005-02-02 at 14:31 -0200, Marcelo Tosatti wrote:
> Someone should try implementing the zeroing driver for a fast x86 PCI
> device. :)
The BT848/BT878 seems like an ideal candidate. That kind of abuse is
probably only really worth it on an architecture with cache-coherent DMA
though. If
On Wed, 02 Feb 2005 14:36:15 -0600, Patrick Gefre <[EMAIL PROTECTED]> wrote:
> Christoph Hellwig wrote:
> > Do you need to use ide_pci_register_driver? IOC4 doesn't have the legacy
> > IDE problems, and it's never used together with such devices in a system,
> > so a plain pci_register_driver
What does one need to do to:
a) put tapping back in, and
b) fix the severe jerkiness with small movements
Thanks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Dmitry Torokhov <[EMAIL PROTECTED]> writes:
> On Wed, 02 Feb 2005 13:07:21 -0800 (PST), Peter Osterlund
> <[EMAIL PROTECTED]> wrote:
> > + if (mousedev->pkt_count >= 2) {
> > + tmp = ((fx(0) - fx(2)) * (250 *
> >
Il giorno 02/feb/05, alle 16:54, Stelian Pop ha scritto:
Hi,
I've played lately a bit with Subversion and used it for managing
the kernel sources, using Larry McVoy's bk2cvs bridge and Ben Collins'
bkcvs2svn conversion script.
Really useful, thanks !
I'm using svn to manage a very small part of
Bill Huey (hui) wrote:
On Tue, Feb 01, 2005 at 11:10:48PM -0600, Jack O'Quin wrote:
Ingo Molnar <[EMAIL PROTECTED]> writes:
(also, believe me, this is not arrogance or some kind of game on our
part. If there was a nice clean solution that solved your and others'
problems equally well then it would
On Wed, 2 Feb 2005, Andrew Morton wrote:
> Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
> >
> > What are your thoughts about inclusion of Mel's allocator work on -mm ?
>
> It's sitting in my to-do pile.
Tell me when you need my prezeroing patches on top of mel's patches
-
To unsubscribe from
On Wed, Feb 02, 2005 at 02:36:15PM -0600, Patrick Gefre wrote:
> >Please kill ioc4_ide_init as it's completely unused and make
> >ioc4_serial_init
> >a normal module_init() handler in ioc4_serial, there's no need to call
> >them from the generic driver.
> >
>
> I want ioc4_serial_init called
On Wed, 02 Feb 2005 13:52:03 -0800 (PST), Peter Osterlund
<[EMAIL PROTECTED]> wrote:
>
>if (mousedev->touch) {
> + size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
> + if (size == 0) size = xres;
Sorry, missed this piece first time around. Since we don't want
401 - 500 of 605 matches
Mail list logo
