Hi Darren,
It has come to my attention that the current routine for setting power
is not compliant with the specification. As such, I'd like you to try
the following and see if removes the need for your patch:
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index dc1b04a..13ac2fe 100644
--
> Isn't that kind of information supposed to be captured in nfs_open_context ?
> Which is associated with the open file instance ...
Or a refcounted struct cred. Which would be needed for strict POSIX thread
semantics likely anyways. But there never was enough incentive to go down
that path and i
Philippe Dhont (Sea-ro) wrote:
hello,
i downloaded latest kernel 2.6.19.2 and installed it and it works fine.
Now i am trying to install vmware and it asks the location of the
directory of the C header files.
So i pointed it to my download/install directory
/data/kernel/2.6.19.2/linux-2.6.19.
Hi Alexey,
> I believe, barriers not needed, not now.
>
> This scheme relies on the fact that remove_proc_entry() will be the only
> place that will clear ->proc_fops and, once cleared, ->proc_fops will
> never be resurrected. Clearing of ->proc_fops will eventually propagate
> to CPU doing first
On Fri, Feb 02 2007, David Chinner wrote:
> On Thu, Feb 01, 2007 at 08:18:57PM +0100, Jens Axboe wrote:
> > That down() probably wants a replug to precede it. Probably something
> > like:
> >
> > if (atomic_read(&bp->b_io_remaining))
> > blk_replug_current_nested();
> >
>
On Mon, 22 Jan 2007 10:35:10 -0800 Andrew Vasquez <[EMAIL PROTECTED]> wrote:
> All,
>
> We've been trying to track down a nagging regression seen during some
> port-disable/enable testing. The problem occurs anywhere from
> 20 minutes to 120 minutes of testing under very minimal I/O load:
>
>
On Thursday 01 February 2007 15:29, Jiri Bohac wrote:
> If I do:
> rdtscll(a)
> ...
> rdtscll(b)
> is it guaranteed that (b > a) ?
It's not architecturally -- unless you have a barrier.
On P4 the micro architecture guarantees it, but there the barrier in
get_cycles_sync is pat
On Fri, Feb 02, 2007 at 05:29:06PM +1100, Neil Brown wrote:
> On Friday February 2, [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > For no important reason, I've again looked at those zeroing patches that
> > Neil did a while back. I've always thought that a simple
> > `write(fd, NULL, size)` would cause
> > Hmm, I wasn't sure. Why is it needed? How outdated can the
> > result of RDTSC / RDTSCP be?
> >
> > If I do:
> > rdtscll(a)
> > ...
> > rdtscll(b)
> > is it guaranteed that (b > a) ?
>
> On a single CPU this is always guaranteed. Even on AMD.
It's not guaranteed on Intel at leas
On Thursday 01 February 2007 14:17, Jiri Bohac wrote:
> On Thu, Feb 01, 2007 at 12:14:23PM +0100, Andi Kleen wrote:
> > On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
> > > TSC is either synchronized by design or not reliable
> > > to be used for anything, let alone timekeeping.
> >
On Thursday 01 February 2007 16:16, Vojtech Pavlik wrote:
> It might even make sense to desycnhronize the TSCs on such (AMD)
> machines on purpose, so that applications that rely on TSC break
> immediately and not after some time when the error becomes too large.
They won't because they're normal
On Friday 02 February 2007 05:22, Andrew Morton wrote:
> On Thu, 01 Feb 2007 10:59:52 +0100 [EMAIL PROTECTED] wrote:
>
> > TSC-based x86_64 timekeeping implementation
>
> I worry about the relationship between this work and all the time-management
> changes in -mm. If Andi to were to merge all t
>
> So I'd say that x86_64 is wrong, and should be changed to take ulong*.
I'm trying to remember why I used void * -- I think there was a reason,
but it's lost in the myst of time.
Anyways, I suspect changing it now would have quite some fallout on other
code, but hopefully limited to arch/x86
On Thu, Feb 01, 2007 at 11:50:06AM -0800, Trond Myklebust wrote:
> On Thu, 2007-02-01 at 16:43 +0530, Suparna Bhattacharya wrote:
> > Wooo ...hold on ... I think this is swinging out of perspective :)
> >
> > I have said some of this before, but let me try again.
> >
> > As you already discovered
On Thu, 1 Feb 2007 21:29:06 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Thu, 1 Feb 2007, Andrew Morton wrote:
>
> > > Peter Zilkstra addressed the NFS issue.
> >
> > Did he? Are you yet in a position to confirm that?
>
> He provided a solution to fix the congestion issue in
On Thu, Feb 01, 2007 at 01:29:41PM -0800, Zach Brown wrote:
> >I want to try it on from a userspace perspective.
>
> Frankly, I'm not sure its ready for that yet. You're welcome to give
> it a try, but it's early enough that you're sure to hit problems
> almost immediately.
I'm counting on
[EMAIL PROTECTED] wrote:
"With 100 million computers in use today, we should expect roughly 6 million
single bit errors per year. Computer hardware and software companies must
receive thousands of "side effect" bug reports and support calls due to memory
errors alone. The costs of NOT including
On Thursday February 1, [EMAIL PROTECTED] wrote:
>
> > The network stack is of course a different (much harder) problem.
>
> An NFS solution is possible without solving the network stack issue?
NFS is currently able to make more than max_dirty_ratio of memory
Dirty/Writeback without being effect
Hello Stephen,
> I can reproduce the problem now (on mac mini). Interestingly it seems
> to whack the whole ethernet switch when it happens.
wow. I have Linksys wrt54g has 'ethernet switch' and my Snom 320 VoIP
phone still works when the mini network card goes down. On the other
side the wrt54g i
Jeff Garzik wrote:
Volatile is usually reserved for a specific need on a specific arch. I
doubt it is correct to force it on all arches.
They already are volatile; the issue is adding "const".
All io(read|write)* pointers are volatile, IIRC.
-hpa
-
To unsubscribe from this list: send
Linus, please revert commit e4f0ae0ea63caceff37a13f281a72652b7ea71ba
Rationale:
The thread starting with http://lkml.org/lkml/2007/1/9/63 contains
a discussion about what might be a correct patch.
Somehow the first patch of this discussion made it into 2.6.20-rc, but
the ones considered more c
On Friday February 2, [EMAIL PROTECTED] wrote:
> Hi,
>
> For no important reason, I've again looked at those zeroing patches that
> Neil did a while back. I've always thought that a simple
> `write(fd, NULL, size)` would cause the same sorts of problems.
Yeh, but who in their right mind would do
Hello Fagyal,
> - a previously suggested fix - passing idle=poll to the kernel - did not
> work for me at the end
same for me. I tried the two module parameters and the kernel parameter:
pci=nomsi sky2.disable_msi=1 sky2.idle_timeout=1000
> - the locks I have happen very periodically (somewhere
On Friday 02 February 2007, Willy Tarreau wrote:
> I think it would be reasonable to use the NR_epoll* names first, and to
> declare NR_sys_epoll* aliases which will point to NR_epoll*. You would
> then add a comment with the date of the change, stating that you keep
> them just in case there are s
On Fri, 2 Feb 2007, Neil Brown wrote:
> md/raid doesn't cause any problems here. It preallocates enough to be
> sure that it can always make forward progress. In general the entire
> block layer from generic_make_request down can always successfully
> write a block out in a reasonable amount of
Arjan van de Ven wrote:
But you're right, the MODULE_LICENSE tag really does imply that
licenses other than the GPL are ok.
yup.. BSD licensed modules are clearly ok as well..
So I guess we're going to go with Jan's change then.
I just wanted to discuss this briefly since I'm very keen for
Volatile is usually reserved for a specific need on a specific arch. I
doubt it is correct to force it on all arches.
Jeff
-
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.kerne
On Thursday February 1, [EMAIL PROTECTED] wrote:
>The NFS problems also exist for non cpuset scenarios
> and we have by and large been able to live with it so I think they are
> lower priority. It seems that the basic problem is created by the dirty
> ratios in a cpuset.
Som
Roland Dreier wrote:
> They are mostly from Chuck Level and make preparating for IPv6 support
> in the NFS server.
> They are *not* for 2.6.20, but should be ok for .21.
Out of curiousity, does this patch series reduce the delta between the
NFS/RDMA tree and mainline Linux? In other words do
Hi,
For no important reason, I've again looked at those zeroing patches that
Neil did a while back. I've always thought that a simple
`write(fd, NULL, size)` would cause the same sorts of problems.
Turns out it does. If you first write all 1s into a page, then do the
`write(fd, NULL, size)` at th
This email lists some known regressions in 2.6.20-rc7 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering
On Fri, Feb 02, 2007 at 12:19:35AM -0500, Mike Frysinger wrote:
> On Friday 02 February 2007, Andrew Morton wrote:
> > It might be to late to fix this - we risk breaking userspace which worked
> > around it.
>
> we'd be breaking userspace API, but not ABI ... and the largest consumers out
> there
On Thu, Feb 01, 2007 at 08:07:12PM -0800, Andrew Morton wrote:
> On Fri, 2 Feb 2007 03:33:43 +0100 Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Feb 01, 2007 at 06:21:47PM -0800, Andrew Morton wrote:
> > > On Fri, 2 Feb 2007 00:07:52 +0100 Luca Tettamanti <[EMAIL PROTECTED]>
> > > wrote:
>
On Tue, 30 Jan 2007, Peter Zijlstra wrote:
> I'm guessing this will involve page migration.
Not necessarily. The approach also works without page migration. Depends
on an intelligent allocation scheme that stays off the areas of interest
to those restricted to low area allocations as much as po
On Thu, 1 Feb 2007, Andrew Morton wrote:
> > Peter Zilkstra addressed the NFS issue.
>
> Did he? Are you yet in a position to confirm that?
He provided a solution to fix the congestion issue in NFS. I thought
that is what you were looking for? That should make NFS behave more
like a block devi
On Thursday 01 February 2007 23:32, Andrew Morton wrote:
> On Thu, 1 Feb 2007 18:46:00 +0100 "Lapo TIN" <[EMAIL PROTECTED]> wrote:
>
> > Dear all,
> > I have a problem with IRQs.
> >
> > My pc has a CPU PentiumD945 (dual core) and a 2.6.19smp kernel.
> > I have two video acquisition board (four b
On Mon, 29 Jan 2007, Andrew Morton wrote:
> On Mon, 29 Jan 2007 15:37:29 -0800 (PST)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > With a alloc_pages_range() one would be able to specify upper and lower
> > boundaries.
>
> Is there a proposal anywhere regarding how this would be implemen
On Friday 02 February 2007, Andrew Morton wrote:
> It might be to late to fix this - we risk breaking userspace which worked
> around it.
we'd be breaking userspace API, but not ABI ... and the largest consumers out
there (glibc/uclibc) have not been accounting for this, so we wouldnt be
breakin
On Thu, 1 Feb 2007 15:20:45 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote:
> the alpha linux port differs from all others when it comes to the epoll
> functions in that it uses '__NR_sys_epoll_XXX' instead of '__NR_epoll_XXX' in
> the asm/unistd.h header ... the trouble with this is that glibc
On Thursday February 1, [EMAIL PROTECTED] wrote:
> > They are mostly from Chuck Level and make preparating for IPv6 support
> > in the NFS server.
> > They are *not* for 2.6.20, but should be ok for .21.
>
> Out of curiousity, does this patch series reduce the delta between the
> NFS/RDMA tree
On Wed, 31 Jan 2007 21:20:06 +0100 Greg KH wrote:
> On Wed, Jan 31, 2007 at 02:06:32PM +0100, Nicolas Mailhot wrote:
>> I'd really love if the same offer was extended to GPL out-of-tree
>> driver trees.
>
> This kind of offer has _always_ been there for out-of-tree GPL
> drivers. I have contacted
Sorry, missed a cast in a dprintk that I could remove (and a '&' that
had to go too).
NeilBrown
### Comments for Changeset
From: Chuck Lever <[EMAIL PROTECTED]>
Modify svc_tcp_accept to support connecting on IPv6 sockets.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMA
> They are mostly from Chuck Level and make preparating for IPv6 support
> in the NFS server.
> They are *not* for 2.6.20, but should be ok for .21.
Out of curiousity, does this patch series reduce the delta between the
NFS/RDMA tree and mainline Linux? In other words does this bring
NFS/RDMA
> Have you had a chance to review this?
Still on my list.
Can we trade? Can you look at the IPoIB connected mode stuff in the
ipoib-cm branch in
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
and let me know if you see anything you don't like?
- R.
-
To unsubscribe
From: Chuck Lever <[EMAIL PROTECTED]>
Expand the rq_addr field to allow it to contain larger addresses.
Specifically, we replace a 'sockaddr_in' with a 'sockaddr_storage',
then everywhere the 'sockaddr_in' was referenced, we use instead
an accessor function (svc_addr_in) which safely casts the _
Rather than calling svc_sock_enqueue at the end of svc_setup_socket,
we now call it (via svc_sock_recieved) after calling svc_setup_socket
at each call site.
We do this because a subsequent patch will insert some code between
the two calls at one call site.
Signed-off-by: Neil Brown <[EMAIL PROT
From: Chuck Lever <[EMAIL PROTECTED]>
The remote peer's address won't change after the socket has been
accepted. We don't need to call ->getname on every incoming request.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PR
From: Chuck Lever <[EMAIL PROTECTED]>
The rq_daddr field must support larger addresses.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./include/linux/sunrpc/svc.h | 15 +++
From: Chuck Lever <[EMAIL PROTECTED]>
Replace existing svc_create_socket() API to allow callers to pass addresses
larger than a sockaddr_in.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
From: Chuck Lever <[EMAIL PROTECTED]>
Add support for IPv6 addresses in the RPC server's UDP receive path.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./include/linux/sunrpc/svc.h |
From: Chuck Lever <[EMAIL PROTECTED]>
CMSG_DATA comes in different sizes, depending on address family.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcsock.c | 67
From: Chuck Lever <[EMAIL PROTECTED]>
The only reason svcsock.c looks at a sockaddr's port is to check whether
the remote peer is connecting from a privileged port. Refactor this check
to hide processing that is specific to address format.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurel
From: Chuck Lever <[EMAIL PROTECTED]>
Modify svc_tcp_accept to support connecting on IPv6 sockets.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcsock.c | 13 ++--
From: Chuck Lever <[EMAIL PROTECTED]>
Clean-up: msg_name and msg_namelen are not used by sock_recvmsg, so
don't bother to set them in svc_recvfrom.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcsock.c | 22
From: Chuck Lever <[EMAIL PROTECTED]>
Sockaddr_storage will allow us to store arbitrary socket addresses in
the svc_deferred_req struct.
Signed-off-by: Chuck Lever <[EMAIL PROTECTED]>
Cc: Aurelien Charbon <[EMAIL PROTECTED]>
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./in
From: Chuck Lever <[EMAIL PROTECTED]>
Sometimes we need to create an RPC service but not register it with the
local portmapper. NFSv4 delegation callback, for example.
Change the svc_makesock() API to allow optionally creating temporary or
permanent sockets, optionally registering with the local
From: Chuck Lever <[EMAIL PROTECTED]>
There are loads of places where the RPC server assumes that the rq_addr
fields contains an IPv4 address. Top among these are error and debugging
messages that display the server's IP address.
Let's refactor the address printing into a separate function that'
Hi Andrew,
could you please remove
knfsd-sunrpc-update-internal-api-separate-pmap-register-and-temp-sockets.patch
knfsd-sunrpc-allow-creating-an-rpc-service-without-registering-with-portmapper.patch
knfsd-sunrpc-cache-remote-peers-address-in-svc_sock.patch
knfsd-sunrpc-use-sockaddr_storage-to-sto
From: Chuck Lever <[EMAIL PROTECTED]>
Currently in the RPC server, registering with the local portmapper and
creating "permanent" sockets are tied together. Expand the internal APIs
to allow these two socket characteristics to be separately specified.
This will be externalized in the next patch.
On Thu, 1 Feb 2007 18:46:00 +0100 "Lapo TIN" <[EMAIL PROTECTED]> wrote:
> Dear all,
> I have a problem with IRQs.
>
> My pc has a CPU PentiumD945 (dual core) and a 2.6.19smp kernel.
> I have two video acquisition board (four bt8t8 each) in the only two pci
> slots of my motherboard. Thus I have a
On Thu, 01 Feb 2007 10:59:52 +0100 [EMAIL PROTECTED] wrote:
> TSC-based x86_64 timekeeping implementation
I worry about the relationship between this work and all the time-management
changes in -mm. If Andi to were to merge all this stuff under that then I
expect various catastrophes would ensue
On Fri, 2 Feb 2007 03:33:43 +0100 Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 01, 2007 at 06:21:47PM -0800, Andrew Morton wrote:
> > On Fri, 2 Feb 2007 00:07:52 +0100 Luca Tettamanti <[EMAIL PROTECTED]> wrote:
> >
> > > Il Thu, Feb 01, 2007 at 12:30:44AM +0100, Adrian Bunk ha scritto:
>
On Thu, Feb 01, 2007 at 08:18:57PM +0100, Jens Axboe wrote:
> That down() probably wants a replug to precede it. Probably something
> like:
>
> if (atomic_read(&bp->b_io_remaining))
> blk_replug_current_nested();
>
> for xfs_buf_wait_unpin() and xfs_buf_lock(). Does this f
On Thu, 1 Feb 2007 18:16:05 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Thu, 1 Feb 2007, Ethan Solomita wrote:
>
> >Hi Christoph -- has anything come of resolving the NFS / OOM concerns
> > that
> > Andrew Morton expressed concerning the patch? I'd be happy to see some
> >
On Wed, 24 Jan 2007 22:37:20 GMT, Chris Rankin said:
> --- Mark Rustad <[EMAIL PROTECTED]> wrote:
> > Well, do you have ECC memory? If not, it is at least possible that
> > that the solar flares that occurred last month may have affected your
> > system.
>
> I am going to assume that you are b
On Fri, Feb 02, 2007 at 11:01:21AM +0800, Zou, Nanhai wrote:
> > > > void
> > > > machine_crash_shutdown(struct pt_regs *pt)
> > > > @@ -132,11 +134,12 @@ kdump_cpu_freeze(struct unw_frame_info *
> > > > atomic_inc(&kdump_cpu_freezed);
> > > > kdump_status[cpuid] = 1;
> > > > mb
RCU_TRACE is always defined.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
---
diff -pur rc6-mm2/kernel/rcupreempt.c rc6-mm2-kw/kernel/rcupreempt.c
--- rc6-mm2/kernel/rcupreempt.c 2007-01-30 00:08:21.0 +0100
+++ rc6-mm2-kw/kernel/rcupreempt.c 2007-01-29 11:07:43.0 +0100
@
On Thu, Feb 01, 2007 at 02:18:55PM -0800, Zach Brown wrote:
> >Wooo ...hold on ... I think this is swinging out of perspective :)
>
> I'm sorry, but I don't. I think using the EIOCBRETRY method in
> complicated code paths requires too much maintenance cost to justify
> its benefits. We can a
Michael K. Edwards wrote:
It looks to me, by comparison to memcpy_(from|to)io, as if the
volatiles ought to be there. It also looks to me like the void *
parameters should be u(8|16|32) * instead, so the compiler knows what
alignment to expect (the implementations would generally fail or suck
o
On Tue, 2007-01-30 at 19:44 -0800, Divy Le Ray wrote:
> Dual licensing, needed for OFED 1.2
Hi,
did you get permission from all the people who contributed code to your
driver ? If not.. that'd be a problem
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test t
> But you're right, the MODULE_LICENSE tag really does imply that
> licenses other than the GPL are ok.
yup.. BSD licensed modules are clearly ok as well..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Magnus Damm
> Sent: 2007年2月2日 10:39
> To: Andrew Morton
> Cc: Magnus Damm; linux-kernel@vger.kernel.org; linux-ia64@vger.kernel.org;
> Luck, Tony; fastboot@lists.osdl.org
> Subject: Re: [PATCH] kexec: Fi
James Bottomley wrote:
On Thu, 2007-02-01 at 15:02 -0500, Mark Lord wrote:
..
One thing that could be even better than the patch below,
would be to have it perhaps skip the entire bio that includes
the failed sector, rather than only the bad sector itself.
Er ... define "skip over the bio". A
On 2/2/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
(added ia64 list)
(added ia64 maintainer)
(added kexec list)
Sorry about that.
On Thu, 01 Feb 2007 22:13:47 +0900
Magnus Damm <[EMAIL PROTECTED]> wrote:
> kexec: Fix CONFIG_SMP=n compilation (ia64)
>
> This patch makes it possible to compi
On Thu, 01 Feb 2007 10:59:53 +0100 [EMAIL PROTECTED] wrote:
> Fix a race in the initialization of HPET, which might result in a
> 5 minute lockup on boot.
>
What race? Please always describe bugs when fixing them.
>
> Index: linux-2.6.20-rc5/arch/x86_64/kernel/apic.c
> ==
On Thu, Feb 01, 2007 at 06:21:47PM -0800, Andrew Morton wrote:
> On Fri, 2 Feb 2007 00:07:52 +0100 Luca Tettamanti <[EMAIL PROTECTED]> wrote:
>
> > Il Thu, Feb 01, 2007 at 12:30:44AM +0100, Adrian Bunk ha scritto:
> > > On Tue, Jan 30, 2007 at 08:53:19PM +0100, Luca Tettamanti wrote:
> > > > Hi,
On Fri, 2 Feb 2007 00:07:52 +0100 Luca Tettamanti <[EMAIL PROTECTED]> wrote:
> Il Thu, Feb 01, 2007 at 12:30:44AM +0100, Adrian Bunk ha scritto:
> > On Tue, Jan 30, 2007 at 08:53:19PM +0100, Luca Tettamanti wrote:
> > > Hi,
> > > pktcdvd on kernel 2.6.20-rc6 is not working as expected. Any file t
On Fri, 02 Feb 2007 10:51:23 +1000, Trent Waddington said:
> On 2/2/07, Tomas Carnecky <[EMAIL PROTECTED]> wrote:
> > Can't you put this somewhere into the documentation: it's our kernel,
> > play by our rules, and our rules are, the license is what is visible in
> > 'printf(license)'?
>
> Here I
On Thu, 1 Feb 2007, Ethan Solomita wrote:
>Hi Christoph -- has anything come of resolving the NFS / OOM concerns that
> Andrew Morton expressed concerning the patch? I'd be happy to see some
> progress on getting this patch (i.e. the one you posted on 1/23) through.
Peter Zilkstra addressed t
On Thu, 1 Feb 2007, Andrew Morton wrote:
> Is this bug unique to the changes in -mm, or is it in mainline?
Mainline is also affected. However, mainline may need a different fix
since the hotplug notifier scheme was changed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
Hi Christoph -- has anything come of resolving the NFS / OOM
concerns that Andrew Morton expressed concerning the patch? I'd be happy
to see some progress on getting this patch (i.e. the one you posted on
1/23) through.
Thanks,
-- Ethan
-
To unsubscribe from this list: send the line
Frederic Riss wrote:
2007/2/1, bibo,mao <[EMAIL PROTECTED]>:
currently x86_64 kernel does not support efi, efi convention comply to
MS convention. On ia32 parameter is passed on stack, on x86_64 parameter
is passed by registers but that is different from x86_64 linux
convention.
Is an x86_64
On Thu, 1 Feb 2007 22:12:24 +0100
Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> +/* Kbuild sometimes doesn't set this */
> +#ifndef KBUILD_MODNAME
> +#define KBUILD_MODNAME "asy_gigaset"
> +#endif
That's a subtle way of reporting a kbuild bug ;)
What's the story here?
> --- linux-2.6.20-rc6-mm3-o
Lapo TIN wrote:
I need to capture at 25 frame per second from each channel...
So 25 x 8 total frames per second on the pci.
So do you think I have to change the motherboard ?
What is important ? the chipset ? is there specification I need ?
What resolution are you using? 720x480 with 24 bits
On Thu, 1 Feb 2007 11:13:29 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> Shutdown the cache_reaper if the cpu is brought down and set the
> cache_reap.func to NULL. Otherwise hotplug shuts down the reaper for good.
>
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
>
> Index
On 2/2/07, Tomas Carnecky <[EMAIL PROTECTED]> wrote:
Can't you put this somewhere into the documentation: it's our kernel,
play by our rules, and our rules are, the license is what is visible in
'printf(license)'?
Here I was thinking the rules were: all modules must be GPL and the
jerks who mak
I just noticed this in my logs, from the lock checker:
[ 142.299455]
[ 142.299458] ===
[ 142.299473] [ INFO: possible circular locking dependency detected ]
[ 142.299478] 2.6.20-rc6-mm3 #2
[ 142.299482] -
The attached patch uses RCU to avoid the need to acquire tasklist_lock
in the single-threaded case of clock_gettime(). It still acquires
tasklist_lock when for a (potentially multithreaded) process. This change
allows realtime applications to frequently monitor CPU consumption of
individual tasks
Sorry, I wrote this:
(This is not an ARM-specific question, although the example is on ARM.)
and then sent it to linux-arm-kernel anyway. :-P
I'm writing an ALSA driver for an ARM SoC whose PCM audio interface is
MMIO. ALSA provides copy_from_user_toio and copy_to_user_fromio
routines for th
(added ia64 list)
(added ia64 maintainer)
(added kexec list)
On Thu, 01 Feb 2007 22:13:47 +0900
Magnus Damm <[EMAIL PROTECTED]> wrote:
> kexec: Fix CONFIG_SMP=n compilation (ia64)
>
> This patch makes it possible to compile kexec for ia64 without SMP support.
>
Please always include the compi
On Thu, 2007-02-01 at 17:10 -0700, Eric D. Mudama wrote:
> In the log you posted, the drive posted 51/04 to your out-of-bounds
> request, but these are 59/04, do they span the end of the device or
> something?
As you can see in the error-log including in the Ubuntu bug report, the
51/04 errors ar
On Thu, 2007-02-01 at 18:54 +0300, Edward Shishkin wrote:
[snip]
> Thanks for the dump.
>
> >[ 3138.456588] [] current_atom_finish_all_fq+0x12e/0x280
> >[ 3138.456661] [] autoremove_wake_function+0x0/0x30
> >[ 3138.456674] [] submit_wb_list+0x11c/0x130
> >[ 3138.456690] [] reiser4_txn_end+0x34
On 2/1/07, TJ <[EMAIL PROTECTED]> wrote:
short extract ---
DC202XX: Primary channel reset.
ide2: reset: success
hde: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest
Error }
hde: task_in_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
end_request: I/O err
I need to capture at 25 frame per second from each channel...
So 25 x 8 total frames per second on the pci.
So do you think I have to change the motherboard ?
What is important ? the chipset ? is there specification I need ?
-Messaggio originale-
Da: [EMAIL PROTECTED]
[mailto:[EMAIL PRO
Jon Masters wrote:
> need a technological mechanism here to enforce the obvious. To me, it
> just seems totally obvious (any legal comment?) that early C string
> termination is undermining the intent of the MODULE_LICENSE tag.
>
I completely agree with that. It's like I sign a contract and the o
On Thu, 2007-02-01 at 14:26 -0800, Andrew Morton wrote:
> The recursion is a concern. Is there any way in which a cunningly-crafted
> device can cause sufficiently deep recursion to crash the kernel?
I did wonder about this, but couldn't think of an *elegant* way of
mirroring the extended_partit
Brian D. McGrew wrote:
What am I missing to get the 2.6.16.16 kernel to see a SATA CD-ROM
drive
in normal, non-legacy move?
Try booting 2.6.16 with the following options:
libata.atapi_enabled=1 ide0=noprobe ide1=noprobe
-
Still no go. /dev/sda* is created for the hard drive but no CD-R
Trent Waddington wrote:
On 2/2/07, Jon Masters <[EMAIL PROTECTED]> wrote:
Ok. I totally dig the *idea* here - I mean, this issue has been ongoing
for a long time now. But I'd like to see a few comments as to whether we
need a technological mechanism here to enforce the obvious. To me, it
just se
Lapo TIN wrote:
Dear all,
I have a problem with IRQs.
My pc has a CPU PentiumD945 (dual core) and a 2.6.19smp kernel.
I have two video acquisition board (four bt8t8 each) in the only two pci
slots of my motherboard. Thus I have a total of 8 bttv modules that are
working together, and the /proc/i
Andrew,
On Thu, Feb 01, 2007 at 02:55:25PM -0800, Andrew Morton wrote:
> On Thu, 1 Feb 2007 01:15:55 -0800
> Stephane Eranian <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> >
> > On Fri, Jan 26, 2007 at 09:49:54AM -0800, H. Peter Anvin wrote:
> > > >
> > > >I ran into compiler warnings with the perfm
1 - 100 of 384 matches
Mail list logo
