On Sun, Jan 21, 2007 at 10:12:55PM +0100, Jan Engelhardt wrote:
> Same lie like with harddrives. It's around 80, not 100.
> But it depends on how you look at it. 80 for Layer3, possibly
> a little more for Layer2/1.
Strange, I tend to get about 95 for layer 3.
--
Len Sorensen
-
To unsubscribe
Denis Vlasenko wrote:
What will happen if we just make open ignore O_DIRECT? ;)
And then anyone who feels sad about is advised to do it
like described here:
http://lkml.org/lkml/2002/5/11/58
Then database and other high performance IO users will be broken. Most
of Linus's rant there is
On Sun, Jan 21, 2007 at 12:10:00PM +0100, Eduard Bloch wrote:
> And I cannot seriosly believe that you are cappable of reading his
> examples. Megabananas are a ridiculous demonstration becase of the
> object beeing counted itself, but if you take stuff from real life then
> I doubt that you
On 1/22/07, Alan <[EMAIL PROTECTED]> wrote:
> This is accomplished by allocating a page (or more) of memory which
> is executable and mapped into every threads address space. Also, all
> ISR entry points are modified to detect if the code that was interrupted
> was executing within the ACE page.
H. Peter Anvin wrote:
> Ralf Baechle wrote:
> > On Sun, Jan 21, 2007 at 06:37:24PM +0200, S.ط£â€،aط¤إ¸lar Onur wrote:
> >> 21 Oca 2007 Paz tarihinde ط¥إ¸unlarط¤ï؟½ yazmط¤ï؟½ط¥إ¸tط¤ï؟½nط¤ï؟½z:
> >>> RSS feed of the git tree:
> >>>
Andrea Arcangeli wrote:
> Linus may be right that perhaps one day the CPU will be so much faster
> than disk that such a copy will not be measurable and then O_DIRECT
> could be downgraded to O_STREAMING or an fadvise. If such a day will
> come by, probably that same day Dr. Tanenbaum will be
On Mon, 22 Jan 2007, Neil Horman wrote:
> On Mon, Jan 22, 2007 at 02:59:56PM +0100, Paolo Ornati wrote:
> >
> > the ERESTARTNOHAND thing is handled in arch specific signal code,
>
> In the signal handling path yes.
Right.
> Not always in the case of select, though. Check core_sys_select:
On 2007.01.21 18:17:01 -0600, Robert Hancock wrote:
> Björn Steinbrink wrote:
> >On 2007.01.21 13:58:01 -0600, Robert Hancock wrote:
> >>Björn Steinbrink wrote:
> >>>All kernels were bad using that approach. So back to square 1. :/
> >>>
> >>>Björn
> >>>
> >>OK guys, here's a new patch to try
On Sat, 2007-01-20 at 08:01 +0100, Peter Zijlstra wrote:
> Subject: nfs: fix congestion control
>
> The current NFS client congestion logic is severly broken, it marks the
> backing
> device congested during each nfs_writepages() call but doesn't mirror this in
> nfs_writepage() which makes for
Denis Vlasenko wrote:
The difference is that you block exactly when you try to access
data which is not there yet, not sooner (potentially much sooner).
If application (e.g. database) needs to know whether data is _really_ there,
it should use aio_read (or something better, something which
On Mon, Jan 22, 2007 at 08:03:53AM -0800, Linus Torvalds wrote:
>
>
> On Mon, 22 Jan 2007, Neil Horman wrote:
>
> > On Mon, Jan 22, 2007 at 02:59:56PM +0100, Paolo Ornati wrote:
> > >
> > > the ERESTARTNOHAND thing is handled in arch specific signal code,
> >
> > In the signal handling path
On Mon, 2007-01-22 at 01:25 +0200, Boaz Harrosh wrote:
> - Instantiate another request_io_part in request for bidi_read.
> - Define & Implement new API for accessing bidi parts.
> - API to Build bidi requests and map to sglists.
> - Define new end_that_request_block() function to end a complete
Benny Halevy wrote:
> Douglas Gilbert wrote:
>> Boaz Harrosh wrote:
>>> - Introduce a new enum dma_data_direction data_dir member in struct request.
>>> and remove the RW bit from request->cmd_flag
>>> - Add new API to query request direction.
>>> - Adjust existing API and implementation.
>>> -
On Sun, 21 Jan 2007 20:13:00 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Using assembler code for performance in drivers might have been a good
> idea 15 years ago when this code was written, but with today's compilers
> that's unlikely to be an advantage.
>
> Besides this, it also hurts
On Mon, 2007-01-22 at 10:05 -0500, Douglas Gilbert wrote:
> Perhaps the right use of DMA_BIRECTIONAL needs to be
> defined.
>
> Could it be used with a XDWRITE(10) SCSI command
> defined in sbc3r07.pdf at http://www.t10.org ? I suspect
> using two scatter gather lists would be a better approach.
On Mon, Jan 22, 2007 at 03:18:41PM +, Alan wrote:
> On Sun, 21 Jan 2007 20:13:00 +0100
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > Using assembler code for performance in drivers might have been a good
> > idea 15 years ago when this code was written, but with today's compilers
> >
> > The C codepaths are essentially untested on this driver.
>
> Has any part of this driver ever be tested with kernel 2.6?
> Or compiled with gcc 4?
The C code paths have never been tested at all, the asm ones certainly
worked in late 2.4, but I don't; have an ISA box any more.
-
To
These series of patches result of
UFS1 write support stress testing, like running
fsx-linux, untar and build linux kernel etc
We pass from ufs::get_block_t to levels below:
pointer to the current page, to make possible things like
reallocation of blocks on the fly, and we also uses this pointer
During ufs_trunc_direct which is subroutine of ufs::truncate,
we try the first of all free parts of block and then whole blocks.
But we calculate size of block's part to free in the wrong way.
This may cause bad update of used blocks and fragments statistic,
and you can got report that you have
In blocks reallocation function sometimes does not update some
of buffer_head::b_blocknr, which may and cause data damage.
Signed-off-by: Evgeniy Dushistov <[EMAIL PROTECTED]>
---
Index: linux-2.6.20-rc5/fs/ufs/balloc.c
===
---
Hi Linus,
could you please pull from 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus
or
master.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus
to receive bugfixes for HID code.
Thanks.
---
MAINTAINERS |5
Please revert 2.6.19's 99a10a60ba9bedcf5d70ef81414d3e03816afa3f (shown
below) for 2.6.20. Nadia Derbey has reported that mmap of /dev/kmem no
longer works with the kernel virtual address as offset, and Franck has
confirmed that his patch came from a misunderstanding of what an offset
means to
> On Jan 21 2007 00:14, Ralf Baechle wrote:
> >On Sat, Jan 20, 2007 at 11:42:37PM +, sathesh babu wrote:
> >
> >> I am trying to run Linux-2.6.18.2 ( with preemption enable)
> >> kernel on FPGA board which has MIPS24KE processor runs at 12
> >> MHZ. Programmed the timer to give interrupt
On 2007.01.22 17:12:40 +0100, Björn Steinbrink wrote:
> On 2007.01.21 18:17:01 -0600, Robert Hancock wrote:
> > Björn Steinbrink wrote:
> > >On 2007.01.21 13:58:01 -0600, Robert Hancock wrote:
> > >>Björn Steinbrink wrote:
> > >>>All kernels were bad using that approach. So back to square 1. :/
>
From: Alan Stern <[EMAIL PROTECTED]>
This patch (as839b) implements the Kwatch (kernel-space hardware-based
watchpoints) API for the i386 architecture. The API is explained in
the kerneldoc for register_kwatch() in arch/i386/kernel/kwatch.c, and
there is demonstration code in
On Jan 22 2007 10:41, Robert P. J. Day wrote:
>
>as opposed to the 100+ *other* definitions currently cluttering up the
>tree, which this patch would allow to be deleted *immediately*.
>
>forget it. i can see this argument is going nowhere and that, six
>months from now, some poor sucker is
On Jan 22 2007 10:53, Lennart Sorensen wrote:
>
>> You talk for everybody, or is it just your (and only your) mind refusing
>> to accept new terms? For my taste, kib and mib are even easier to
>> speech, easier than {KiLoBytE} resp. {MeGaBytE} or KaaaBe / eMmmBe.
>
>There is too much legacy code
"Luigi Genoni" <[EMAIL PROTECTED]> writes:
> (e-mail resent because not delivered using my other e-mail account)
>
> Hi,
> this night a linux server 8 dual core CPU Optern 2600Mhz crashed just after
> giving this message
>
> Jan 22 04:48:28 frey kernel: do_IRQ: 1.98 No irq handler for vector
Ok.
On Friday 19 January 2007 5:41 pm, Randy Dunlap wrote:
> On Thu, 18 Jan 2007 15:33:25 -0500 Rob Landley wrote:
>
> > Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
> >
> > Documentation for lib/rbtree.c.
> >
> > --
> >
> > I'm not an expert on this but I was asked to write up some
At Mon, 22 Jan 2007 10:20:21 -0500,
[EMAIL PROTECTED] wrote:
> On Mon, 22 Jan 2007 02:23:30 +0300, Samium Gromoff said:
> >
> > not "core-dumps" but "core files", in the lispspeak, but anyway.
> >
> > the reason is trivial -- if i can write programs enjoying setuid
> > privileges in C, i want to
At Mon, 22 Jan 2007 01:35:46 +0100,
Arjan van de Ven wrote:
>
>
> > the core of the problem are the cores which are customarily
> > dumped by lisps during the environment generation (or modification) stage,
> > and then mapped back, every time the environment is invoked.
>
> >
> > at the
On 2007.01.22 17:57:08 +0100, Björn Steinbrink wrote:
> On 2007.01.22 17:12:40 +0100, Björn Steinbrink wrote:
> > On 2007.01.21 18:17:01 -0600, Robert Hancock wrote:
> > > Hmm, another miss, apparently.. Has anyone tried removing these lines
> > > >from nv_host_intr in 2.6.20-rc5 sata_nv.c and see
On Sat, 2007-01-20 at 13:28 -0500, Robert P. J. Day wrote:
> Remove the last (and commented out) invocation of the obsolete
> smp_commence() call.
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
thanks,
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Ingo
-
To unsubscribe from this
On Sat, 20 Jan 2007, Peter Zijlstra wrote:
> Subject: nfs: fix congestion control
I am not sure if its too valuable since I have limited experience with NFS
but it looks fine to me.
Acked-by: Christoph Lameter <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-rc3-mm1:
>...
> git-ieee1394.patch
>...
> git trees
>...
This patch contains the following cleanups:
- "extern inline" -> "static inline"
- fw-topology.c: make struct fw_node_create static
On 1/15/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
Jens Axboe wrote:
> On Mon, Jan 15 2007, Jeff Garzik wrote:
>> Jens Axboe wrote:
>>> I'd be surprised if the device would not obey the 7 second timeout rule
>>> that seems to be set in stone and not allow more dirty in-drive cache
>>> than it
Theodore Tso wrote:
On Mon, Jan 22, 2007 at 07:45:02AM -0500, Alan Cox wrote:
Definitely disagree with that. I'd like to see the conference somewhere
else different this time - perhaps Czech Republic, or somewhere else more
easterly and Linux active (or even Finland...)
Understand that one
> For "F"s sake, when you gotta use abbreviations, then just use k=1000 and
> K=1024 already, b for bits and B for bytes. Problem gone.
K is Kelvin, k is kilo-
See ISO 31. There is a standard for this stuff which is used worldwide
and only bits of the computing industry appear incapable of
Am 22.01.2007 14:42 schrieb Thomas Hellström:
>>> On Mon, 15 Jan 2007 00:52:36 +0100 Tilman Schmidt <[EMAIL PROTECTED]> wrote:
>>> With kernel 2.6.20-rc4-mm1 and all hotfixes, i810fb fails to load on my
>>> Dell Optiplex GX110. [...]
>>
> Can you try the attached patch to see if that fixes the
Hi!
> > will be a device driver. Common causes of suspend/resume problems from
> > the list you give below are acpi modules, bluetooth and usb. I'd also be
> > consider pcmcia, drm and fuse possibilities. But again, go for unloading
> > everything possible in the first instance.
>
> Actually,
CCing linux-kernel as per AC's suggestion...
> -Original Message-
> From: Ralf Baechle [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 19, 2007 8:18 AM
> To: Marc St-Jean
> Cc: [EMAIL PROTECTED]; linux-serial@vger.kernel.org
> Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel
CCing linux-kernel as per AC's suggestion...
Here is a serial driver patch for the PMC-Sierra MSP71xx device.
There are three different fixes:
1. Fix for THRE errata
2. Fix for Busy Detect on LCR write
3. Workaround for interrupt/data concurrency issue
The first fix is handled cleanly using a
CCing linux-kernel as per AC's suggestion...
On Thu, Jan 18, 2007 at 04:23:01PM -0800, Marc St-Jean wrote:
> Index: linux_2_6/drivers/serial/8250.c
> ===
> RCS file: linux_2_6/drivers/serial/8250.c,v retrieving revision
> 1.1.1.7
CCing linux-kernel as per AC's suggestion...
-Original Message-
From: Sergei Shtylyov
Sent: Friday, January 19, 2007 9:05 AM
To: Marc St-Jean
Cc: [EMAIL PROTECTED]; linux-serial@vger.kernel.org
Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git master
Hello.
Marc
Ingo,
I hit this bug on one of my work test machines. This bug is probably what
caused my laptop to crash ever so often too, but since I don't have a
serial or other debug output, my laptop never showed what was wrong.
Here's the call trace:
[ cut here ]
kernel BUG at
On Sat, 20 Jan 2007, Nick Piggin wrote:
> > It doesn't reduce the amount of memory available to the system. It
> > just reduce the amount of memory available to the page cache. So that
> > page cache is limited and the reserved memory can be allocated by the
> > application.
>
> But the patch
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> I hit this bug on one of my work test machines. This bug is probably
> what caused my laptop to crash ever so often too, but since I don't
> have a serial or other debug output, my laptop never showed what was
> wrong.
ah, nice one! Thanks,
On Sat, 20 Jan 2007, Aubrey Li wrote:
> assume:
> min = 123pages
> pagecache_reserved = 200 pages
>
> if( alloc_flags & ALLOC_PAGECACHE)
>watermark = min + pagecache_reserved ( 323 pages)
> else
>watermark = min ( 123 pages)
>
> So if request pagecache, when free pages < 323
> "Jan" == Jan Engelhardt <[EMAIL PROTECTED]> writes:
Jan> For "F"s sake, when you gotta use abbreviations, then just use
Jan> k=1000 and K=1024 already, b for bits and B for bytes. Problem
Jan> gone.
The one-letter abbreviations are identical to SI prefixes, except
for "K", which is
* john stultz <[EMAIL PROTECTED]> wrote:
> And here would be the follow on patch (again *untested*) for
> CONFIG_NO_HZ slowing the time accumulation down to once per second.
thanks John - i've applied the combined patch below to -rt. It appears
to work fine for me.
Ingo
Greg KH <[EMAIL PROTECTED]> writes:
>> Since 2.6.19, I get the following Oops once a day, always with the same
>> process, newspipe[1] which use a lot of CPU, threads and I/O.
>>
>> The kernel is patched by Grsecurity. The ext3 filesystem is on a
>> software RAID device (the two disks are SATA2).
Fix insecure default behaviour reported by Tigran Aivazian: if an ext2
or ext3 or ext4 filesystem is tuned to mount with "acl", but mounted by
a kernel built without ACL support, then umask was ignored when creating
inodes - though root or user has umask 022, touch creates files as 0666,
and mkdir
Hello.
Bartlomiej Zolnierkiewicz wrote:
[PATCH] ide: fix UDMA/MWDMA/SWDMA masks
* use 0x00 instead of 0x80 to disable ->{ultra,mwdma,swdma}_mask
* add udma_mask field to ide_pci_device_t and use it to initialize
->ultra_mask in aec62xx, pdc202xx_new and pdc202xx_old drivers
* fix UDMA
On Sun, 21 Jan 2007, H. Peter Anvin wrote:
> In general, though, I would agree that the major number should change if there
> is an incompatible change.
Maybe when those incompatible features are enabled by default. Right
now they're not.
Nicolas
-
To unsubscribe from this list: send the
On Sun, 21 Jan 2007 03:20:06 -0800, Junio C Hamano wrote:
> Also, in the same spirit of giving the release an early
> exposure, here is the current draft of 1.5.0 release notes.
Thanks, these are very good and really show how much great progress
has gone into git recently. Congratulations to
Hello.
Bartlomiej Zolnierkiewicz wrote:
[PATCH] ide: fix UDMA/MWDMA/SWDMA masks
* use 0x00 instead of 0x80 to disable ->{ultra,mwdma,swdma}_mask
* add udma_mask field to ide_pci_device_t and use it to initialize
->ultra_mask in aec62xx, pdc202xx_new and pdc202xx_old drivers
* fix UDMA
Junio C Hamano wrote:
> GIT v1.5.0 Release Notes (draft)
>
Would they be somewhere besides todo branch of git.git repository, like the
v1.5.0 tag comment (content), or the NEWS file?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
-
To unsubscribe from this
On Mon, 22 Jan 2007 21:17:33 +0300
> Ugh, I'm not seeing any *actual* support for MW/SW DMA in this driver...
Thats long been broken. Should be correct in the libata driver
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
Documentation/DocBook/libata.tmpl |2 +-
drivers/ata/libata-eh.c |4
drivers/ata/sata_mv.c |5
On Mon, 22 Jan 2007, kyle wrote:
Hi,
Yesterday I tried to increase the value of strip_cache_size to see if I
can
get better performance or not. I increase the value from 2048 to
something
like 16384. After I did that, the raid5 freeze. Any proccess read / write
to
it stucked at D state. I
On Mon, 22 Jan 2007, kyle wrote:
> >
> > On Mon, 22 Jan 2007, kyle wrote:
> >
> > > Hi,
> > >
> > > Yesterday I tried to increase the value of strip_cache_size to see if I
> > > can
> > > get better performance or not. I increase the value from 2048 to something
> > > like 16384. After I did
On Mon, 22 Jan 2007, Steve Cousins wrote:
>
>
> Justin Piszcz wrote:
> > Yes, I noticed this bug too, if you change it too many times or change it at
> > the 'wrong' time, it hangs up when you echo numbr > /proc/stripe_cache_size.
> >
> > Basically don't run it more than once and don't run
On Mon, 22 Jan 2007, Steve Cousins wrote:
>
>
> Justin Piszcz wrote:
> > Yes, I noticed this bug too, if you change it too many times or change it at
> > the 'wrong' time, it hangs up when you echo numbr > /proc/stripe_cache_size.
> >
> > Basically don't run it more than once and don't run
Justin Piszcz wrote:
Yes, I noticed this bug too, if you change it too many times or change it
at the 'wrong' time, it hangs up when you echo numbr >
/proc/stripe_cache_size.
Basically don't run it more than once and don't run it at the 'wrong'
time and it works. Not sure where the bug
> Yes, I noticed this bug too, if you change it too many times or change
> it
> at the 'wrong' time, it hangs up when you echo numbr >
> /proc/stripe_cache_size.
>
> Basically don't run it more than once and don't run it at the 'wrong'
> time
> and it works. Not sure where the bug lies, but
Justin Piszcz wrote:
Yes, I noticed this bug too, if you change it too many times or change it
at the 'wrong' time, it hangs up when you echo numbr >
/proc/stripe_cache_size.
Basically don't run it more than once and don't run it at the 'wrong' time
and it works. Not sure where the bug
Do we need to consider the chunk size when we adjust the value of
Striped_Cache_Szie for the MD-RAID5 array?
Liang
- Original Message -
From: "Justin Piszcz" <[EMAIL PROTECTED]>
To: "kyle" <[EMAIL PROTECTED]>
Cc: ;
Sent: Monday, January 22, 2007 5:18 AM
Subject: Re: change
On Sun 2007-01-21 14:27:34, Justin Piszcz wrote:
> Why does copying an 18GB on a 74GB raptor raid1 cause the kernel to invoke
> the OOM killer and kill all of my processes?
>
> Doing this on a single disk 2.6.19.2 is OK, no issues. However, this
> happens every time!
>
> Anything to try? Any
On Mon, 22 Jan 2007, Pavel Machek wrote:
> On Sun 2007-01-21 14:27:34, Justin Piszcz wrote:
> > Why does copying an 18GB on a 74GB raptor raid1 cause the kernel to invoke
> > the OOM killer and kill all of my processes?
> >
> > Doing this on a single disk 2.6.19.2 is OK, no issues. However,
Thanks for your comments; the attached probably needs
proofreading.
The changes in response to the remainder of your comments are
quite straightforward and I do not think needs proofreading, so
I'll incorporate them and push the result out in 'todo'.
diff --git a/v1.5.0.txt b/v1.5.0.txt
index
Hello
On Monday 22 January 2007 18:48, Timothy Webster wrote:
> I am curious, who is coordinating reiserfs4 bug fixes,
> testing and kernel integration work at this point?
> I would like to help out with auto testing the reiserfs4 builds.
Thanks
> Who is coordinating this work?
All
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> thanks John - i've applied the combined patch below to -rt. It appears
> to work fine for me.
updated patch below. (previous one was a delta in timex.h)
Ingo
>
From: John Stultz <[EMAIL PROTECTED]>
Subject: [patch] HZ-free
mtrr: fix size_or_mask and size_and_mask
This fixes two bugs in /proc/mtrr interface:
o If physical address size crosses the 44 bit boundary
size_or_mask is evaluated wrong.
o size_and_mask limits width of physical base
address for an MTRR to be less than 44 bits.
Signed-off-by: Andreas
Adrian Bunk wrote:
On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
...
Changes since 2.6.20-rc3-mm1:
...
git-ieee1394.patch
...
git trees
...
This patch contains the following cleanups:
- "extern inline" -> "static inline"
I guess that's fine, I do like how extern inline
Hi Alan & Jeff,
I've finally got the new ATA drivers setup and working for my main
data disks, which is great. But I'm also trying to get my CDRW/DVDROM
drive on the MPIIX (82371AB) chipset working. I'm running 2.6.20-rc5
currently on a Debian system, using the pata_mpiix as a module. The
> On Sat, 13 Jan 2007 17:30:39 +0100 Richard Knutsson <[EMAIL PROTECTED]> wrote:
> Would like to come with a suggestion I have been wondering about for a
> while, why not add the config-flag, used in Kconfig/Makefile in the
> MAINTAINERS-file?
I find that the most practical way to find out who
> On Tue, 16 Jan 2007 07:15:22 +0100 [EMAIL PROTECTED] wrote:
> The following kernel components register a tunable structure and call the
> auto-tuning routine:
> . file system
> . shared memory (per namespace)
> . semaphore (per namespace)
> . message queues (per namespace)
This is the
> On Wed, 17 Jan 2007 17:36:14 +0100 Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> The recent discussion on LKML convinced me that a line discipline
> is the correct way to layer a driver over a serial interface.
> This means, however, that I'll need a (trivial) userspace daemon
> which will hold
> On Mon, 15 Jan 2007 15:42:21 + Ben Dooks <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 15, 2007 at 01:44:28PM +, Richard Purdie wrote:
> > On Mon, 2007-01-15 at 12:26 +, Ben Dooks wrote:
> > > Generate a name if none is passed to the S3C24XX GPIO LED driver.
Wouldn't it be better to fix
> On Thu, 18 Jan 2007 15:23:26 + Russell King <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 18, 2007 at 04:31:51PM +0100, Tomas Carnecky wrote:
> > Russell King wrote:
> > > On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard Walle wrote:
> > >> -static char command_line[COMMAND_LINE_SIZE];
> > >>
> On Thu, 18 Jan 2007 21:11:58 +0100 noah <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I'm experiencing data corruption in the following setup:
>
> 1. mdadm --create /dev/md0 -n3 -lraid5 /dev/hda1 /dev/hdc1 /dev/hde1
> 2. cryptsetup -c aes-cbc-essiva:sha256 luksFormat /dev/md0 mykey
> 3. cryptsetup -d
yunfeng zhang wrote:
> My patch is based on my new idea to Linux swap subsystem, you can find
> more in Documentation/vm_pps.txt which isn't only patch illustration but
> also file changelog. In brief, SwapDaemon should scan and reclaim pages on
> UserSpace::vmalist other than current
* Noah Watkins <[EMAIL PROTECTED]> wrote:
> fixes trailing whitespace and spaces before tab indents in
> 2.6.20-rc5-rt7 as reported with: git-apply --whitespace=error-all
thanks. Did you do the patch manually, or do you have a script for that
perhaps?
Ingo
-
To unsubscribe from this
* Pavel Pisa <[EMAIL PROTECTED]> wrote:
> Hello Thomas, Sascha and Ingo
>
> please can you find some time to review next patch
> arm: i.MX/MX1 clock event source
> which has been sent to you and to the ALKML at 2007-01-13.
>
>
On Mon, Jan 22, 2007 at 11:56:50AM -0800, Andrew Morton wrote:
> > On Thu, 18 Jan 2007 15:23:26 + Russell King <[EMAIL PROTECTED]> wrote:
> > On Thu, Jan 18, 2007 at 04:31:51PM +0100, Tomas Carnecky wrote:
> > > Russell King wrote:
> > > > On Thu, Jan 18, 2007 at 01:58:52PM +0100, Bernhard
Here is a PCI quirk and two docmuentation updates for 2.6.20-rc5
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6.git/
The full patches will be sent to the linux-pci mailing list, if anyone
wants to see it
thanks,
greg k-h
Documentation/pci.txt| 702
Adrian Bunk wrote:
On Mon, Jan 22, 2007 at 02:41:29PM -0500, Kristian Høgsberg wrote:
Adrian Bunk wrote:
On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
...
Changes since 2.6.20-rc3-mm1:
...
git-ieee1394.patch
...
git trees
...
This patch contains the following cleanups:
-
On Mon, Jan 22, 2007 at 02:41:29PM -0500, Kristian Høgsberg wrote:
> Adrian Bunk wrote:
> >On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote:
> >>...
> >>Changes since 2.6.20-rc3-mm1:
> >>...
> >> git-ieee1394.patch
> >>...
> >> git trees
> >>...
> >
> >
> >This patch contains the
http://www.cymor.com/gallery/SnowPenguin/aah
-
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/
Hello Andrew,
Can I do anything more in order to be closer to merge?
Some general comments... or should I CC other people etc...
I submitted this several times but got almost no architecture to ACK.
I just don't know how we can progress with this issue... All we wanted
is to break the 256 limit
CCing to linux-kernel as per AC's suggestion...
Original Message
Subject: RE: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git master
Date: Mon, 22 Jan 2007 10:11:04 -0800
From: Marc St-Jean
To: Sergei Shtylyov
CC: <[EMAIL PROTECTED]>,
> -Original
CCing to linux-kernel as per AC's suggestion...
Original Message
Subject:Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git
mast er
Date: Mon, 22 Jan 2007 12:23:56 -0800
From: Sergei Shtylyov
Organization: MontaVista Software Inc.
To: Marc St-Jean
CC:
I have to ask why the yellow snow appears to have run, bad aim?
On Mon, Jan 22, 2007 at 02:21:54PM -0600, David Nicol wrote:
> http://www.cymor.com/gallery/SnowPenguin/aah
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL
On Mon, Jan 22, 2007 at 05:58:42PM +0100, Jan Engelhardt wrote:
> For "F"s sake, when you gotta use abbreviations, then just use k=1000 and
> K=1024 already, b for bits and B for bytes. Problem gone.
And for 10^6 vs 2^20?
> kegs perhaps? :)
Hmm, Mega -> Megs, Kilo -> Kils?
--
Len Sorensen
-
To
On Mon, Jan 22, 2007 at 06:36:19PM +, Alan wrote:
> K is Kelvin, k is kilo-
K is a unit is Kelvin, k/K as a prefix is kilo.
> See ISO 31. There is a standard for this stuff which is used worldwide
> and only bits of the computing industry appear incapable of following it.
--
Len Sorensen
-
On Mon, 22 Jan 2007 22:31:48 +0200
"Alon Bar-Lev" <[EMAIL PROTECTED]> wrote:
> Hello Andrew,
>
> Can I do anything more in order to be closer to merge?
Avoid top-posting? ;)
> Some general comments... or should I CC other people etc...
> I submitted this several times but got almost no
>>> Adrian Bunk wrote:
This patch contains the following cleanups:
- "extern inline" -> "static inline"
- fw-topology.c: make struct fw_node_create static
Committed to linux1394-2.6.git.
--
Stefan Richter
-=-=-=== ---= =-==-
http://arcgraph.de/sr/
-
To unsubscribe from this
This removes several pointless exports from drivers/dma/dmaengine.c;
the dma_async_memcpy_*() functions are inlined by
so those exports are inappropriate.
It also moves the existing EXPORT_SYMBOL declarations next to their
functions, so it's now trivial to confirm one-to-one correspondence
On Monday 22 January 2007 15:21, David Nicol wrote:
>http://www.cymor.com/gallery/SnowPenguin/aah
Cute, somebody obviously has time on their hands. I take it the colors
are water colors? :)
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to
> 00:07.1 IDE interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 IDE
> [8086:7111] (rev 01)
This isn't an MPIIX, Use the ata_piix driver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
401 - 500 of 667 matches
Mail list logo
