There's an existing quirk for the kernel to use 1k IO space granularity
on the Intel P64H2. It turns out however that pci_setup_bridge() in
drivers/pci/setup-bus.c reads in the IO base and limit address register
masks it off to the nearest 4k, and writes it back. This causes the
kernel to be on
On Thu, 21 Dec 2006 20:52:40 +0100
Ard -kwaak- van Breemen <[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Thu, Dec 21, 2006 at 04:04:04PM +0800, Zhang, Yanmin wrote:
> > I couldn't reproduce it on my EM64T machine. I instrumented function
> > start_kernel and
> > didn't find irq was enabled before
"Scott Preece" <[EMAIL PROTECTED]> writes:
> Which is more rude:
> (a) "Thank you for requesting a driver to support our hardware on
> Linux. Unfortunately, we don't have time either to provide such a
> driver or write the documentation that would allow you do so. The
> Linux market is not big
>> What about merging util-linux and procps?
>
> How? Which way?
In that all the following tools (and possibly files) which are
returned by `rpm ql procps` replace the util-linux counterparts, if
any. Note that rpm -ql might return less programs than actually
present in procps, since
* Tim Chen <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> While trying out the 2.6.19.1-rt14 kernel with a x86_64 system with
> Clovertown processor, it hung when it was shutting down e1000 ethernet
> interface running the command:
>
> /sbin/ip link set dev eth0 down
does the patch below solve it
On Thu, Dec 21 2006, Andrew Morton wrote:
> On Thu, 21 Dec 2006 20:47:41 +0100
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Dec 21 2006, Jens Axboe wrote:
> > > On Thu, Dec 21 2006, Andrew Morton wrote:
> > > >
> > > > Jens, elapsed time for `mke2fs /dev/hdc5' with the anticipatory
> >
On Thu, 21 Dec 2006 20:47:41 +0100
Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 21 2006, Jens Axboe wrote:
> > On Thu, Dec 21 2006, Andrew Morton wrote:
> > >
> > > Jens, elapsed time for `mke2fs /dev/hdc5' with the anticipatory scheduler
> > > (at least) has gone from nine seconds to
On Thu, 21 Dec 2006, pHilipp Zabel wrote:
> > > --- linux-2.6.orig/arch/arm/mach-pxa/generic.c2006-12-16
> > > +++ linux-2.6/arch/arm/mach-pxa/generic.c 2006-12-16
> > > 16:47:45.0
> > > @@ -129,6 +129,29 @@
> > > EXPORT_SYMBOL(pxa_gpio_mode);
> > >
> > > /*
> > > + * Return
On Thu, 21 Dec 2006, Peter Zijlstra wrote:
>
> Also, I'm dubious about the while thing and stuck a WARN_ON(ret) thing
> at the beginning of the loop. flush_tlb_page() does IPI the other cpus
> to flush their tlb too, so there should not be a SMP race, Arjan?
Now, the reason I think the loop
Hi Tejun,
Tejun Heo wrote:
> * dmesg is truncated, please post the content of file /var/log/boot.msg.
>
> * Please post the result of 'lspci -nnvvv'
>
> * Please try the attached patch and see if it makes any difference and
> post the result of 'dmesg' after trying to play a problematic dvd.
>
local_add_return should also deal with the removed volatile from local_t.
Inspired from atomic_t modifications : it must use the local_t both as input and
output.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
--- a/include/asm-x86_64/local.h
+++ b/include/asm-x86_64/local.h
@@ -136,8
On Thu, Dec 21 2006, Jens Axboe wrote:
> On Thu, Dec 21 2006, Andrew Morton wrote:
> >
> > Jens, elapsed time for `mke2fs /dev/hdc5' with the anticipatory scheduler
> > (at least) has gone from nine seconds to sixty as a result of the recent
> > block merge.
>
> About when? I'll double check and
local_add_return fix for non volatile local_t on i386.
local_add_return should act like the new atomic_add_return considering the
removal of volatile from atomic_t.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
--- a/include/asm-i386/local.h
+++ b/include/asm-i386/local.h
@@ -142,8
atomic64_add_return fix for volatile removal
atomic64_add_return should follow the change done to atomic.h following the
removal of "volatile" in the atomic_t type, just like atomic_add_return.
It applies cleanly on top of my "atomic.h : x86_64" patch posted in this
thread.
Signed-off-by:
On Thu, Dec 21 2006, Andrew Morton wrote:
>
> Jens, elapsed time for `mke2fs /dev/hdc5' with the anticipatory scheduler
> (at least) has gone from nine seconds to sixty as a result of the recent
> block merge.
About when? I'll double check and test here, I'm assuming you mean since
2.6.19?
>
On Tue, 21 Nov 2006 06:58:38 -0800, Akemi Yagi wrote:
> On Tue, 21 Nov 2006 00:24:40 -0800, Chakri n wrote:
>
>> Hi,
>>
>> I am seeing a kernel panic in cifs module. It seems to be a result of
>> invalid inode entry in dentry for the file it is trying to validate.
>>
>> The inode->i_ino is set
On 12/21/06, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
On Thu, 21 Dec 2006, pHilipp Zabel wrote:
> David suggested to have both inline and non-inline functions depending
> on whether gpio is constant. How is this patch?
More comments below.
> --- /dev/null 1970-01-01 00:00:00.0 +
>
On Fri, 22 Dec 2006 02:34:54 +1100, Marek Wawrzyczny said:
>
> > And then there's stuff on this machine that are *not* options, but don't
> > matter to me. I see an 'O2 Micro' Firewire in the 'lspci' output. I have
> > no idea how well it works. I don't care what it contributes to the score.
>
Jens, the elapsed time for `mkefs2 /dev/hdc5' has just gone from nine
seconds to sixty, with the anticipatory scheduler (at least). It is due to
your recent merge.
This is the enty enth time that block changes have been slammed into
mainline without having had any exposure to -mm testers or
Jens, elapsed time for `mke2fs /dev/hdc5' with the anticipatory scheduler
(at least) has gone from nine seconds to sixty as a result of the recent
block merge.
This is the enty enth time that block code has been slammed into mainline
without having had exposure to -mm testers or even to me
James Porter wrote:
I'm pretty sure Linus has decided, basically he said the patches to
prevent non-gpl binary drivers are not going into his tree unless every
other tree adopts it. Of course the few supporting won't get off their
high horse and try it on a different tree.
.. unfortunately,
On Thursday 21 December 2006 7:03 am, pHilipp Zabel wrote:
> On 12/21/06, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> +static inline void __gpio_set_value(unsigned gpio, int value)
> +{
> + if (value)
> + GPSR(gpio) = GPIO_bit(gpio);
> + else
> + GPCR(gpio) =
On Wed, Dec 20, 2006 at 12:44:42PM +0100, Miklos Szeredi wrote:
> The stat64.st_ino field is 64bit, so AFAICS you'd only need to extend
> the kstat.ino field to 64bit and fix those filesystems to fill in
> kstat correctly.
Coda actually uses 128-bit file identifiers internally, so 64-bits
really
Frederik Deweerdt wrote:
> Following the i386 pda patches, it's not possible to set gs or fs value
> from gdb anymore. The following patch restores the old behaviour of
> getting and setting thread.gs of thread.fs respectively.
> Here's a gdb session *before* the patch:
> (gdb) info reg
> [...]
>
Hi,
I'm trying to use the splice/vmsplice system calls to improve the
samba server write throughput, but before touching the smbd, I started
to improve the ttcp tool since it simple and has the same flow. I'm
expecting to avoid the "copy_from_user" path when using those
syscalls.
so far, I
On Thu, Dec 21 2006, Mike Christie wrote:
> Jens Axboe wrote:
> > On Thu, Dec 21 2006, Mike Christie wrote:
> >> Mike Christie wrote:
> >>> Jens Axboe wrote:
> On Thu, Dec 21 2006, Mike Christie wrote:
> > Or the block layer code could set up the clone too. elv_next_request
> > could
Yinghai Lu wrote:
> On 12/19/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >So the pin2 case should be tested right after the pin1 case as we do
> >currently. On most new boards that will be a complete noop.
> >
> >But it is better than our current blind guess at using ExtINT mode.
> >
> >I
On Thu, 21 Dec 2006 13:11:01 -0600 Eric Sandeen wrote:
> Randy Dunlap wrote:
>
> > Please don't hide the goto; un-indent 1 tab stop.
> Whoops, thanks Randy - it wasn't intentional. :)
Yeah, I didn't think it was. Sorry if it sounded like that.
---
~Randy
-
To unsubscribe from this list: send
Randy Dunlap wrote:
> Please don't hide the goto; un-indent 1 tab stop.
Whoops, thanks Randy - it wasn't intentional. :)
Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
Index: linux-2.6.19/fs/ext2/dir.c
===
---
On Thu, 21 Dec 2006 12:58:28 -0600 Eric Sandeen wrote:
> This one was pointed out on the MOKB site:
> http://kernelfun.blogspot.com/2006/11/mokb-09-11-2006-linux-26x-ext2checkpage.html
>
> If a directory's i_size is corrupted, ext2_find_entry() will keep processing
> pages until the i_size is
> > > > > > Yes, note the flush_dcache_page() call in fuse_copy_finish(). That
> > > > > > could be replaced by the flush_kernel_dcache_page() (added by James
> > > > > > Bottomley together with flush_anon_page()) when all relevant
> > > > > > architectures have defined it.
> > > > >
> > > > > I
This one was pointed out on the MOKB site:
http://kernelfun.blogspot.com/2006/11/mokb-09-11-2006-linux-26x-ext2checkpage.html
If a directory's i_size is corrupted, ext2_find_entry() will keep processing
pages until the i_size is reached, even if there are no more blocks associated
with the
Jens Axboe wrote:
> On Thu, Dec 21 2006, Mike Christie wrote:
>> Mike Christie wrote:
>>> Jens Axboe wrote:
On Thu, Dec 21 2006, Mike Christie wrote:
> Or the block layer code could set up the clone too. elv_next_request
> could prep a clone based on the orignal request for the driver
On Thu, Dec 21, 2006 at 07:30:11PM +0100, Miklos Szeredi wrote:
> > > > > Yes, note the flush_dcache_page() call in fuse_copy_finish(). That
> > > > > could be replaced by the flush_kernel_dcache_page() (added by James
> > > > > Bottomley together with flush_anon_page()) when all relevant
> > > >
Erik Mouw wrote:
"However, we thought the legal and technical expense involved in
writing this binary driver and possibly violating the Linux kernel
copyright was well spend."
So Microsoft is right, the legal status of Linux software _is_ unclear.
You just gave them every reason to
Ingo Molnar wrote:
> Subject: [patch] change WARN_ON back to "BUG: at ..."
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> WARN_ON() ever triggering is a kernel bug. Do not try to paper over this
> fact by suggesting to the user that this is 'only' a warning, as the
> following recent commit does:
>
On Thu, Dec 21 2006, Mike Christie wrote:
> Jens Axboe wrote:
> > On Thu, Dec 21 2006, Mike Christie wrote:
> >> Or the block layer code could set up the clone too. elv_next_request
> >> could prep a clone based on the orignal request for the driver then dm
> >> would not have to worry about that
On Thu, Dec 21 2006, Mike Christie wrote:
> Mike Christie wrote:
> > Jens Axboe wrote:
> >> On Thu, Dec 21 2006, Mike Christie wrote:
> >>> Or the block layer code could set up the clone too. elv_next_request
> >>> could prep a clone based on the orignal request for the driver then dm
> >>> would
Mike Christie wrote:
> Jens Axboe wrote:
>> On Thu, Dec 21 2006, Mike Christie wrote:
>>> Or the block layer code could set up the clone too. elv_next_request
>>> could prep a clone based on the orignal request for the driver then dm
>>> would not have to worry about that part.
>> It really can't,
On Thu, Dec 14, 2006 at 10:59:13PM -0800, Andrew Morton wrote:
> http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
>
Hi all,
Following the i386 pda patches, it's not possible to set gs or fs value
from gdb anymore. The following patch restores the old behaviour of
getting and setting
Jens Axboe wrote:
> On Thu, Dec 21 2006, Mike Christie wrote:
>> Or the block layer code could set up the clone too. elv_next_request
>> could prep a clone based on the orignal request for the driver then dm
>> would not have to worry about that part.
>
> It really can't, since it doesn't know
> > > > Yes, note the flush_dcache_page() call in fuse_copy_finish(). That
> > > > could be replaced by the flush_kernel_dcache_page() (added by James
> > > > Bottomley together with flush_anon_page()) when all relevant
> > > > architectures have defined it.
> > >
> > > I should say that
On Wed, 20 Dec 2006 22:06:51 EST, Dan Williams said:
> It's also complicated because some switches are supposed to rfkill both
> an 802.11 module _and_ a bluetooth module at the same time, or I guess
> some laptops may even have one rfkill switch for each wireless device.
On my Dell D820, it's
Jens Axboe wrote:
> On Wed, Dec 20 2006, Kiyoshi Ueda wrote:
>> Hi Jens,
>>
>> On Wed, 20 Dec 2006 19:49:17 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote:
> Big NACK on this - it's not only really ugly, it's also buggy to pass
> interrupt flags as function arguments. As you also mention in
Hi,
Well, Spin lock itself is a while loop. So in case a process on another
CPU has the semaphore and you get a spin lock and try to wait on a
semaphore and the other CPU also tries to get the spin lock then you are
in a dead loop.
CPU 1 CPU 2
Get
On Thu, Dec 21 2006, Mike Christie wrote:
> Or the block layer code could set up the clone too. elv_next_request
> could prep a clone based on the orignal request for the driver then dm
> would not have to worry about that part.
It really can't, since it doesn't know how to allocate the clone
On Thu, Dec 21 2006, Kiyoshi Ueda wrote:
> Hi Jens,
>
> OK, I understand that.
> But I think that the block layer assumption (depending on "current")
> is not ideal.
> Anyway, thank you for the information.
(don't top post)
Well, how else would you throttle request allocations on a process
On Wed, 20 Dec 2006 23:06:43 +0100, Giuseppe Bilotta said:
> So while what you say is perfectly sensible for *software* developers,
> it has absolutely nothing to do with the closed source drivers
> *hardware* companies distribute.
The problem is that the software drivers reveal an awful lot
Mike Christie wrote:
> Jens Axboe wrote:
>> On Wed, Dec 20 2006, Kiyoshi Ueda wrote:
>>> Hi Jens,
>>>
>>> On Wed, 20 Dec 2006 19:49:17 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote:
>> Big NACK on this - it's not only really ugly, it's also buggy to pass
>> interrupt flags as function
On Thu, 21 Dec 2006 14:59:22 +0100, "Jean Delvare" <[EMAIL PROTECTED]>
said:
> Hi Vivek,
>
> On Thu, 21 Dec 2006 08:43:26 +0530, Vivek Goyal wrote:
> > On Thu, Dec 21, 2006 at 02:13:54PM +0100, Jean Delvare wrote:
> > > On Thu, 21 Dec 2006 06:38:14 +0530, Vivek Goyal wrote:
> > > > Looks like it
On Thu, Dec 21, 2006 at 06:55:47PM +0100, Miklos Szeredi wrote:
> > > Yes, note the flush_dcache_page() call in fuse_copy_finish(). That
> > > could be replaced by the flush_kernel_dcache_page() (added by James
> > > Bottomley together with flush_anon_page()) when all relevant
> > > architectures
Hi Jens,
OK, I understand that.
But I think that the block layer assumption (depending on "current")
is not ideal.
Anyway, thank you for the information.
Thanks,
Kiyoshi Ueda
On Thu, 21 Dec 2006 08:53:05 +0100, Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 20 2006, Kiyoshi Ueda wrote:
>
C99 standard allows the use of the long long data type, both signed and
unsigned. We should allow this to be used if defined.
Signed-off-by: Roy Marples <[EMAIL PROTECTED]>
--- a/include/asm-arm/types.h 2006-11-29 21:57:37.0 +
+++ b/include/asm-arm/types.h 2006-12-21
[EMAIL PROTECTED] wrote on Thursday, December 21, 2006 9:35 AM
> kenneth.w.chen> Take ioctx_lock is one part, the other part is to move
> kenneth.w.chen> spin_unlock_irqrestore(>ctx_lock, flags);
> kenneth.w.chen> in aio_complete all the way down to the end of the
> kenneth.w.chen> function,
> > Yes, note the flush_dcache_page() call in fuse_copy_finish(). That
> > could be replaced by the flush_kernel_dcache_page() (added by James
> > Bottomley together with flush_anon_page()) when all relevant
> > architectures have defined it.
>
> I should say that flush_anon_page() in its
> On Thu, Dec 21, 2006 at 04:53:56PM +0100, Miklos Szeredi wrote:
> > I'll first answer the last paragraph.
> >
> > > I suggest that in order for fuse to work reliably on ARM, it is modified
> > > to behave more like a reasonable device driver, and use the functions
> > > defined in asm/uaccess.h
On Thu, Dec 21, 2006 at 10:33:10AM -0600, Scott Preece wrote:
> (b) "Thank you for requesting a driver to support our hardware on
> Linux. Unfortunately, we don't have time either to provide such a
> driver or write the documentation that would allow you do so. The
> Linux market is not big enough
==> Regarding RE: [patch] aio: fix buggy put_ioctx call in aio_complete; "Chen,
Kenneth W" <[EMAIL PROTECTED]> adds:
kenneth.w.chen> [EMAIL PROTECTED] wrote on Thursday, December 21, 2006 8:56
kenneth.w.chen> AM I think I'm going to abandon this whole synchronize
kenneth.w.chen> thing and going
On Thu, Dec 21, 2006 at 05:29:42PM +0100, Arjan van de Ven wrote:
>
> > So, given all this additional complexity _and_ that it would only be
> > safe on non-preempt UP, the question becomes: is using get_user_pages()
> > to access the current processes memory space legal? Given the above,
> > I
Update the serial_txx9 driver.
* Configurable manumum port number. (SERIAL_TXX9_NR_UARTS)
* Remove some code which is unneeded if CONFIG_PM=n.
* Use PCI_DEVICE() for pci device id table and make it const.
* Do not include
Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
Kconfig
On Thu, 21 Dec 2006, pHilipp Zabel wrote:
> David suggested to have both inline and non-inline functions depending
> on whether gpio is constant. How is this patch?
More comments below.
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ linux-2.6/include/asm-arm/arch-pxa/gpio.h
On Wed, 20 Dec 2006, Trond Myklebust wrote:
>
> I can't see that it is the business of invalidate_inode_pages2() to
> resolve races between ->direct_IO() and pages that are redirtied by
> mmap(). All it needs to ensure is that pages that clean are discarded,
> since those are neither consistent
On Thu, Dec 21, 2006 at 12:04:10AM -0800, Andrew Morton wrote:
> On Thu, 21 Dec 2006 00:36:09 -0700
> Grant Grundler <[EMAIL PROTECTED]> wrote:
> > Any reasons why the Documentation/pci.txt patch isn't included?
> > Did I botch something?
>
> I saw about 88,000 of them fly past, none of which
On Thu, Dec 21, 2006 at 04:53:56PM +0100, Miklos Szeredi wrote:
> Yes, note the flush_dcache_page() call in fuse_copy_finish(). That
> could be replaced by the flush_kernel_dcache_page() (added by James
> Bottomley together with flush_anon_page()) when all relevant
> architectures have defined
On Thu, 2006-12-21 at 14:19 +0100, Sven-Haegar Koch wrote:
> On Wed, 20 Dec 2006, Dan Williams wrote:
>
> >> If we define interface down as meaning that the device is powered down
> >> and the radio switched off, then (b) and (c) would presumably just need
> >> to ensure that the interface is
[EMAIL PROTECTED] wrote on Thursday, December 21, 2006 8:56 AM
> kenneth.w.chen> I think I'm going to abandon this whole synchronize thing
> kenneth.w.chen> and going to put the wake up call inside ioctx_lock spin
> kenneth.w.chen> lock along with the other patch you mentioned above in the
>
On Thu, 21 Dec 2006, Andrei Popa wrote:
> On Wed, 2006-12-20 at 16:24 -0800, Linus Torvalds wrote:
> >
> > Martin, Peter, Andrei, pls give it a try. (Martin and Andrei may be
> > talking about different bugs, so _both_ of your experiences definitely
> > matter here).
>
> with
On Thu, Dec 21, 2006 at 04:53:56PM +0100, Miklos Szeredi wrote:
> I'll first answer the last paragraph.
>
> > I suggest that in order for fuse to work reliably on ARM, it is modified
> > to behave more like a reasonable device driver, and use the functions
> > defined in asm/uaccess.h when it
==> Regarding RE: [patch] aio: fix buggy put_ioctx call in aio_complete; "Chen,
Kenneth W" <[EMAIL PROTECTED]> adds:
kenneth.w.chen> I think I'm going to abandon this whole synchronize thing
kenneth.w.chen> and going to put the wake up call inside ioctx_lock spin
kenneth.w.chen> lock along with
On Thu, Dec 21, 2006 at 11:42:04AM -0500, jamal ([EMAIL PROTECTED]) wrote:
> > > > Things like sockets/pipes can only benefit from direct kevent usage
> > > > instead of ->poll() and wrappers.
> > >
> > > You should be able change it to use those schemes when it detects
> > > that the kernel
Marek Wawrzyczny <[EMAIL PROTECTED]> wrote:
[...]
> No, no, no... I was never proposing that. I was thinking of something more
> along the lines of reporting back on open-source friendliness of
> manufacturers of devices, and perhaps on the availability of open source
> drivers for the
On Thu, 2006-21-12 at 17:46 +0300, Evgeniy Polyakov wrote:
> On Thu, Dec 21, 2006 at 09:40:26AM -0500, jamal ([EMAIL PROTECTED]) wrote:
> > > Things like sockets/pipes can only benefit from direct kevent usage
> > > instead of ->poll() and wrappers.
> >
> > You should be able change it to use
On 12/18/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
We have a process that has worked for centuries to improve our
knowledge base. The scientific method and peer review. We use a
variation of this proven process for writing software in linux. The
binary only vendors are being rude and
> So, given all this additional complexity _and_ that it would only be
> safe on non-preempt UP, the question becomes: is using get_user_pages()
> to access the current processes memory space legal? Given the above,
> I would say not.
I'd say that copy_from_user is the right api for this, not
I'll first answer the last paragraph.
> I suggest that in order for fuse to work reliably on ARM, it is modified
> to behave more like a reasonable device driver, and use the functions
> defined in asm/uaccess.h when it wants to access the current processes
> VM space.
Fuse needs to use
This is support for the TC variations of the TGA boards (properly known
as SFB+ or Smart Frame Buffer Plus boards). The 8-plane SFB+ board uses
the Bt459 RAMDAC (unlike its PCI TGA counterpart, which uses the Bt485),
so bits have been added to support this chip as well.
Signed-off-by: Maciej
On Wed, 2006-12-20 at 16:24 -0800, Linus Torvalds wrote:
>
> Btw, I'd really love to hear whether the patch I sent out actually _helps_
> at all, or whether we're just discussing something that in the end is just
> a cleanup..
>
> Martin, Peter, Andrei, pls give it a try. (Martin and Andrei
... duh
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/include/net/ip6_checksum.h b/include/net/ip6_checksum.h
index 68e2b32..bc1b0fd 100644
--- a/include/net/ip6_checksum.h
+++ b/include/net/ip6_checksum.h
@@ -87,7 +87,7 @@ static __inline__ __sum16 csum_ipv6_magi
carry =
On Wed, 20 Dec 2006 17:13:19 EST, john stultz said:
> Andrew, Andi,
>
> Here is the same patchset from lastnight, re-diffed against -mm
This one does indeed apply, compile, and boot.
> Thanks to Valdis Kletnieks for pointing out that it didn't apply.
Not being a locking ninja or a PCI demigod,
On Wednesday 20 December 2006 16:11, [EMAIL PROTECTED] wrote:
> On Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny said:
> > On Sunday 17 December 2006 21:11, Geert Uytterhoeven wrote:
> > And if you let yourself get carried away, you can also imagine a little
> > multi-platform utility. It
On Wed, 20 Dec 2006 22:15:50 GMT, Alistair John Strachan said:
> Seems pretty unlikely on a 4 year old Via Epia. Never had any problems with it
> before now.
>
> Maybe a cosmic ray event? ;-)
More likely a stray alpha particle from a radioactive decay in the actual chip
casing - I saw some
On 12/21/06, Arnaud Patard <[EMAIL PROTECTED]> wrote:
(adding Ben Dooks as he's taking care of s3c24xx stuff)
David Brownell <[EMAIL PROTECTED]> writes:
Note that I neither tested it nor build tested it. It's only remarks I
have when I read the code.
Thanks for looking through this. I
I've recently been asked to look at why fuse doesn't work on ARM.
In doing so and thinking about what fuse is doing, I've come to
the conclusion that the way fuse accesses the _current_ processes
memory space is less than ideal.
The problem is as follows:
- current process calls writev()
-
This is a set of changes to add TURBOchannel support to the defxx driver.
As at this point the EISA support in the driver has become the only not
having been converted to the driver model, I took the opportunity to
convert it as well. Plus support for MMIO in addition to PIO operation as
On 12/21/06, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
On Wed, 20 Dec 2006, David Brownell wrote:
> On Wednesday 20 December 2006 10:12 pm, Andrew Morton wrote:
> > Why not implement them as inline functions?
>
> I just collected and forwarded the code from Philip...
> the better not to lose
On Thu, Dec 21, 2006 at 09:40:26AM -0500, jamal ([EMAIL PROTECTED]) wrote:
> > Things like sockets/pipes can only benefit from direct kevent usage
> > instead of ->poll() and wrappers.
>
> You should be able change it to use those schemes when it detects
> that the kernel supports them.
I.e.
On Wed, 2006-12-20 at 19:03 -0600, Linas Vepstas wrote:
> Same kernel runs fine on power5. Although it does have patches
> applied, those very same patches boot fine when applied to a slightly
> older kernel (2.6.19-rc4). I haven't been messing with buids or
> pci config space (at least not
Nicolas Ferre a écrit :
As the SPI underlying code behaves quite differently from a
controller driver
to another whan not having a tx_buf filled, I have add a zerroed
buffer to give
to the spi layer while receiving data.
You must be working with a buggy controller driver then. That part of
On Thu, 2006-21-12 at 17:36 +0300, Evgeniy Polyakov wrote:
> Btw, it uses only read/write/signal on fd events, so it must use
> ->poll() and thus be as fast as epoll.
>
It is supposed to "detect" the best mechanism in the kernel and switch
to that.
At the moment for example in my app it
Petr Vandrovec wrote:
Hello Jeff,
I'm using second patch below for couple of months to get MSI on all
devices present on my notebook which are MSI capable (except IDE - notebook
uses IDE in legacy mode and seems unhappy with transition to native MSI-based
mode; maybe I could try do the job
On Thu, Dec 21, 2006 at 05:23:37PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> Ok, when site will be ready I will patch libevent and post patch or link
> in this thread. I plan to complete it this week.
Btw, it uses only read/write/signal on fd events, so it must use
->poll() and thus
Sorin Manolache wrote:
The Linux Device Drivers book says that a spin_lock should not be
shared between a process and an interrupt handler. The explanation is
that the process may hold the lock, an interrupt occurs, the interrupt
handler spins on the lock held by the process and the system
On Thu, Dec 21, 2006 at 09:21:07AM -0500, jamal ([EMAIL PROTECTED]) wrote:
> > I just do not know _what_ else should be done not even for inclusion -
> > but at least for some progress.
>
> I know you are frustrated but stop doing the above like a broken vinyl
> record, it doesnt help your case.
On Wed, 20 Dec 2006, David Brownell wrote:
> On Wednesday 20 December 2006 10:12 pm, Andrew Morton wrote:
> > Why not implement them as inline functions?
>
> I just collected and forwarded the code from Philip...
> the better not to lose such stuff! :)
>
>
> > Or non-inline functions, come
On Thu, Dec 21, 2006 at 07:56:01AM +0530, Vivek Goyal wrote:
[..]
> > # Manual, Mixing 16-bit and 32-bit code, page 16-6)
> >
> > .byte 0x66, 0xea# prefix + jmpi-opcode
> > -code32:.long 0x1000 # will be set to
> > 0x10
On Thursday 21 December 2006 08:05, Chuck Ebbert wrote:
> In-Reply-To: <[EMAIL PROTECTED]>
>
> On Wed, 20 Dec 2006 22:15:50 +, Alistair John Strachan wrote:
> > > I'd guess you have some kind of hardware problem. It could also be
> > > a kernel problem where the saved address was corrupted
On Thu, 21 Dec 2006 09:10:29 +0530, Vivek Goyal wrote:
> Ok. so indirect jump seems to be having problem. On my machine disassembly
> of setup.o show following.
>
> ff a6 14 02 00 00 jmp*0x214(%esi)
>
> This seems to be fine as 0x14 is the offset of code32_start, and
>
On Thu, 2006-21-12 at 17:04 +0300, Evgeniy Polyakov wrote:
> I modified world-wide used web server lighttpd and ran a lot of tests
> with it (compared to epoll version with major performance win).
>
> I was asked yesterday by Jan Kneschke (lighttpd main developer) if
> kevent API is ready so he
> And with that, I then either rip out any old users of
> "test_clear_page_dirty()" or "clear_page_dirty()", and if appropriate (and
> it's realy lonly appropriate for "truncate()", I replace them with the new
> "cancel_dirty_page()". Most of the time, they should just be deleted
> entirely.
>
On Thu, Dec 21, 2006 at 02:54:01PM +0100, Jean Delvare wrote:
> On Thu, 21 Dec 2006 03:32:33 -0700, Eric W. Biederman wrote:
> > Ok. There is almost enough for inference but here is a patch of stops
> > for setup.S let's see if one of those will stop the reboots.
> >
> > I have a strong feeling
101 - 200 of 602 matches
Mail list logo
