* Re: [PATCH 00/22] Refactor to accept NUL in commit messages
From: Junio C Hamano @ 2011-10-23 5:51 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, peff, Ævar Arnfjörð
In-Reply-To: <CACsJy8B=TsC4A=R6b3jyYBCvorEDBYHQ8uA864WrB0-3pgNyKA@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> We could allocate just one block with length as the first field:
>
> struct commit_buffer {
> unsigned long len;
> char buf[FLEX_ARRAY];
> };
>
> The downside is commit_buffer field type in struct commit changes,
> which impacts many codepaths.
I think that is a good thing overall to _force_ us to audit all the code,
*if* our goal were to avoid losing bytes. And the solution above is better
than adding a length field to "struct commit". It certainly is better than
quoting NUL byte to ^@, keep using the "char *" field and risking some
codepaths forget to convert it back to NUL. For types of payloads for
which losing everything after the first NUL matters, converting NUL to ^@
and then forgetting to convert it back to NUL is equally bad breakage to
the payload anyway, so such a conversion would not be a particularly good
approach to avoid losing bytes.
But as Jeff suggested, we should step back a bit and think what our goal
is.
The low level object format of our commit is textual header fields, each
of which is terminated with a LF, followed by a LF to mark the end of
header fields, and then opaque payload that can contain any bytes. It does
not forbid a non-Git application to reuse the object store infrastructure
to store ASN.1 binary goo there, and the low level interface we give such
as cat-file is a perfectly valid way to inspect such a "commit" object.
But when it comes to "Git" Porcelains (e.g. the log family of commands),
we do assume people do not store random binary byte sequences in commits,
and we do take advantage of that assumption by splitting each "line" at
LF, indenting them with 4 spaces, etc. In other words, a commit log in the
Git context _is_ pretty much text and not arbitrary byte sequence. Even
the "--pretty=raw" option for "log" family is not about the "raw" body;
the "raw"-ness applies only to the header fields. So even if we _were_ to
update the codepaths involved to avoid losing bytes, the end result will
not be useful for users to whom ability to include NUL matters.
So in that sense, I do not think it is unreasonable to chop it off at the
first NUL, which is the current behaviour. IOW, it is entirely sane to
argue that there is nothing to fix.
^ permalink raw reply
* Question about: linux-linaro-2.6.38.7 booting the ubuntu 10.10 filesystem
From: David Yang @ 2011-10-23 5:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALQsFOJt6Z7J=QiS1fsieZYvY+mjv4YFZVJHzp69DEBtAA_bfQ@mail.gmail.com>
I have selected the HAVE_SCHED_CLOCK and implemnt the init_sched_clock fuction?
But the problem is the same?
So far ,I can get the login prompt only when I select the preempiable kernel .
On 10/23/11, David Yang <david.yangshuai@gmail.com> wrote:
> No,I just ported the kernel from 2.6.33 to 2.6.38.
>
> So I didn't select the HAVE_SCHED_CLOCK?
>
> And I have tested it.
>
> When I select the HAVE_SCHED_CLOCK.
> the kernel will hang after uncompressing the kernel.
>
>
> Best Regards,
> David
>
>
>
> On Sat, Oct 22, 2011 at 9:37 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Sat, Oct 22, 2011 at 05:35:52PM +0800, David Yang wrote:
>>> ?I found in my timer driver,I didn't implement the "init_sched_clock"
>>> function.
>>
>> Have you selected HAVE_SCHED_CLOCK ?
>>
>
^ permalink raw reply
* Re: Kernel Panic every 2 weeks on ISP server (NULL pointer dereference)
From: Eric Dumazet @ 2011-10-23 5:16 UTC (permalink / raw)
To: Luciano Ruete; +Cc: netdev
In-Reply-To: <201110222218.12524.lruete@sequre.com.ar>
Le samedi 22 octobre 2011 à 22:18 -0300, Luciano Ruete a écrit :
> Hi,
>
> I'm the sysadmin at a 3500 customers ISP, wich runs an iptables+tc solution
> for load balancing and QoS.
>
> Every 2 or 3 weeks the server panics with a "NULL pointer dereference" and
> with IP at "dev_queue_xmit"
>
> It is curious that if i disable MSI on the network card driver this panics
> seems to disapear, does this ring a bell?
>
> The server is an IBM, previously with Broadcom NetXtreme II BCM5709 nics and
> now with Intel 82576. I change the nics thinking that maybe the bug was in
> Broadcom Driver but it seems to affect MSI in general.
>
> The tc+iptables rules are auto-generated with sequreisp[1] an ISP solution
> that i wrote and is open sourced under AGPLv3.
>
> Tell me if you need any further information, and plz CC because I'm not
> suscribed.
>
>
> root@server:~# uname -a
> Linux server 2.6.35-30-server #60~lucid1-Ubuntu SMP Tue Sep 20 22:28:40 UTC
> 2011 x86_64 GNU/Linux
>
>
> [1]https://github.com/sequre/sequreisp
>
Hi Luciano
[694250.472081] Code: f6
49 c1 e6 07 shl $0x7,%r14
66 89 93 ac 00 00 00 mov %dx,0xac(%rbx)
4d 03 b5 40 03 00 00 add 0x340(%r13),%r14
txq = dev_pick_tx(dev, skb);
0f b7 83 a6 00 00 00 movzwl 0xa6(%rbx),%eax
4d 8b 66 08 mov 0x8(%r14),%r12
q = rcu_dereference_bh(txq->qdisc);
80 e4 cf and $0xcf,%ah
80 cc 20 or $0x20,%ah
66 89 83 a6 00 00 00 mov %ax,0xa6(%rbx)
skb->tc_verd = SET_TC_AT(skb->tc_verd, AT_EGRESS);
<49> 83 3c 24 00 cmpq $0x0,(%r12)
if (q->enqueue) CRASH because q is NULL.
0f 84 3b 02 00 00 je ...
rc = __dev_xmit_skb(skb, q, dev, txq);
49 8d 84 24 9c 00 00 00 lea 0x9c(%r12),%rax
48 89
This looks like a dev_pick_tx() bug, using an out of bound
queue_index number and returning a txq pointing after
the device allocated array.
With recent kernels, this cannot happen anymore because
we added fixes in this area.
You could try Ubuntu 11.10 (based on linux 3.0) kernel
on your server, or apply following patch :
commit df32cc193ad88f7b1326b90af799c927b27f7654
Author: Tom Herbert <therbert@google.com>
Date: Mon Nov 1 12:55:52 2010 -0700
net: check queue_index from sock is valid for device
In dev_pick_tx recompute the queue index if the value stored in the
socket is greater than or equal to the number of real queues for the
device. The saved index in the sock structure is not guaranteed to
be appropriate for the egress device (this could happen on a route
change or in presence of tunnelling). The result of the queue index
being bad would be to return a bogus queue (crash could prersumably
follow).
Signed-off-by: Tom Herbert <therbert@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/core/dev.c b/net/core/dev.c
index 35dfb83..0dd54a6 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2131,7 +2131,7 @@ static struct netdev_queue *dev_pick_tx(struct net_device *dev,
} else {
struct sock *sk = skb->sk;
queue_index = sk_tx_queue_get(sk);
- if (queue_index < 0) {
+ if (queue_index < 0 || queue_index >= dev->real_num_tx_queues) {
queue_index = 0;
if (dev->real_num_tx_queues > 1)
^ permalink raw reply related
* [U-Boot] [PATCH 05/39] GCC4.6: Squash warning in usb_storage.c
From: Mike Frysinger @ 2011-10-23 5:39 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-6-git-send-email-marek.vasut@gmail.com>
On Fri, Oct 21, 2011 at 20:17, Marek Vasut wrote:
> ?#ifdef USB_STOR_DEBUG
> -#define USB_STOR_PRINTF(fmt, args...) ?printf(fmt , ##args)
> +#define USB_BLK_DEBUG ?1
> ?#else
> -#define USB_STOR_PRINTF(fmt, args...)
> +#define ? ? ? ?USB_BLK_DEBUG ? 0
> ?#endif
#define<space>USB_BLK_DEBUG.....
-mike
^ permalink raw reply
* [U-Boot] [PATCH 01/39] DEBUG: Fix debug macros
From: Mike Frysinger @ 2011-10-23 5:37 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-2-git-send-email-marek.vasut@gmail.com>
On Fri, Oct 21, 2011 at 20:16, Marek Vasut wrote:
> The current implementation of debug doesn't play well with GCC4.6.
> This implementation also fixes GCC4.6 complaints about unused variables
> while maintaining code size.
i think this patch should come last rather than first that way you fix
all the warnings/failures *before* making the debug() code
unconditional
> +#define debug_cond(cond, fmt, args...) ? ? ? ? \
> + ? ? ? do { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? ? ? ? ? if (cond) ? ? ? ? ? ? ? ? ? ? ? \
> + ? ? ? ? ? ? ? ? ? ? ? printf(fmt, ##args); ? ?\
> + ? ? ? } while (0)
> +
> +#define debug(fmt, args...) ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? debug_cond(_DEBUG, fmt, ##args)
> +
> +#define debugX(level, fmt, args...) ? ? ? ? ? ?\
> + ? ? ? debug_cond((_DEBUG && DEBUG >= (level)), fmt, ##args)
i thought we were just going to punt debugX() ?
-mike
^ permalink raw reply
* [U-Boot] [RESEND PATCH v3] Add assert() for debug assertions
From: Mike Frysinger @ 2011-10-23 5:35 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111021222026.4F3FA18AE81D@gemini.denx.de>
On Fri, Oct 21, 2011 at 18:20, Wolfgang Denk wrote:
> Simon Glass wrote:
>> +void __assert_fail(const char *assertion, const char *file, unsigned line,
>> + ? ? ? ? ? ? ? ?const char *function)
>> +{
>> + ? ? /* This will not return */
>> + ? ? panic("%s:%u: %s: Assertion `%s' failed.", file, line, function,
>> + ? ? ? ? ? assertion);
>> +}
>
> Can you please #ifdef it so it doesn't get added for the non-debug
> case, too?
most arches are building with --gc-sections now which means there is
no overhead added for them. should we look at fixing the few holdouts
rather than adding #ifdefs ?
-mike
^ permalink raw reply
* [U-Boot] [RFC] [PATCH 00/39] Rework of the debug() macro
From: Mike Frysinger @ 2011-10-23 5:33 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA2917B.30108@aribaud.net>
On Sat, Oct 22, 2011 at 05:48, Albert ARIBAUD wrote:
> A differential 'MAKEALL arm' (ELDK42) show a sharp rise in board not
> building properly, from 74 to 141 (out of a total of 248).
these boards are broken already. Marek is just making their problems
more apparent.
-mike
^ permalink raw reply
* [U-Boot] [PATCH 2/8] Add setenv_uint() and setenv_addr()
From: Mike Frysinger @ 2011-10-23 5:29 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319259100-11376-3-git-send-email-sjg@chromium.org>
On Sat, Oct 22, 2011 at 00:51, Simon Glass <sjg@chromium.org> wrote:
> +int setenv_ulong(const char *varname, ulong value)
> +{
> + ? ? ? char *str = simple_itoa(value);
> +
> + ? ? ? return setenv(varname, str);
> +}
could be a one liner, but works either way
> +int setenv_addr(const char *varname, const void *addr)
> +{
> + ? ? ? char str[17];
char str[sizeof(addr) * 2 + 1];
> + ? ? ? sprintf(str, "%x", (uintptr_t)addr);
i wonder if we should use %p and drop the cast
-mike
^ permalink raw reply
* [xen-unstable test] 9471: regressions - trouble: broken/fail/pass
From: xen.org @ 2011-10-23 5:09 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 9471 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9471/
Regressions :-(
Tests which did not succeed and are blocking:
test-i386-i386-pair 20 leak-check/check/src_host fail REGR. vs. 9355
test-i386-i386-pair 21 leak-check/check/dst_host fail REGR. vs. 9355
test-amd64-i386-xl-credit2 12 guest-saverestore.2 fail REGR. vs. 9355
test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail REGR. vs. 9355
test-amd64-amd64-win 7 windows-install fail REGR. vs. 9355
Tests which are failing intermittently (not blocking):
test-amd64-amd64-pv 13 guest-localmigrate.2 fail pass in 9363
test-amd64-i386-pv 12 guest-saverestore.2 fail pass in 9363
test-i386-i386-xl-win 7 windows-install fail pass in 9363
test-amd64-amd64-xl-win 7 windows-install fail pass in 9363
test-amd64-amd64-pair 21 leak-check/check/dst_host fail in 9363 pass in 9471
test-amd64-amd64-pair 20 leak-check/check/src_host fail in 9363 pass in 9471
test-amd64-i386-xl-win-vcpus1 7 windows-install fail in 9363 pass in 9471
test-amd64-i386-win 7 windows-install fail in 9363 pass in 9471
Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass
test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass
test-i386-i386-win 16 leak-check/check fail never pass
test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-i386-i386-xl-win 13 guest-stop fail in 9363 never pass
test-amd64-amd64-xl-win 13 guest-stop fail in 9363 never pass
version targeted for testing:
xen a7ccbc79fc17
baseline version:
xen 6c583d35d76d
------------------------------------------------------------
People who touched revisions under test:
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Roger Pau Monne <roger.pau@entel.upc.edu>
Tim Deegan <tim@xen.org>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
test-i386-i386-xl pass
test-amd64-i386-rhel6hvm-amd fail
test-amd64-i386-xl-credit2 fail
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-i386-i386-pair broken
test-amd64-amd64-pv fail
test-amd64-i386-pv fail
test-i386-i386-pv pass
test-amd64-amd64-xl-sedf fail
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-i386-i386-win fail
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win fail
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
changeset: 23991:a7ccbc79fc17
tag: tip
user: Jan Beulich <jbeulich@suse.com>
date: Fri Oct 21 09:45:24 2011 +0200
cpumask <=> xenctl_cpumap: allocate CPU masks and byte maps dynamically
Generally there was a NR_CPUS-bits wide array in these functions and
another (through a cpumask_t) on their callers' stacks, which may get
a little large for big NR_CPUS. As the functions can fail anyway, do
the allocation in there.
For the x86/MCA case this require a little code restructuring: By using
different CPU mask accessors it was possible to avoid allocating a mask
in the broadcast case. Also, this was the only user that failed to
check the return value of the conversion function (which could have led
to undefined behvior).
Also constify the input parameters of the two functions.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 23990:1c8789852eaf
user: Jan Beulich <jbeulich@suse.com>
date: Fri Oct 21 09:44:47 2011 +0200
x86/hpet: allocate CPU masks dynamically
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 23989:8269826353d8
user: Jan Beulich <jbeulich@suse.com>
date: Fri Oct 21 09:44:03 2011 +0200
credit: allocate CPU masks dynamically
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 23988:53528bab2eb4
user: Jan Beulich <jbeulich@suse.com>
date: Fri Oct 21 09:43:35 2011 +0200
cpupools: allocate CPU masks dynamically
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 23987:2682094bc243
user: Jan Beulich <jbeulich@suse.com>
date: Fri Oct 21 09:42:47 2011 +0200
x86/p2m: allocate CPU masks dynamically
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
Acked-by: Keir Fraser <keir@xen.org>
--- 2011-10-18.orig/xen/arch/x86/hvm/nestedhvm.c 2011-10-11 17:24:46.000000000 +0200
+++ 2011-10-18/xen/arch/x86/hvm/nestedhvm.c 2011-10-18 16:45:02.000000000 +0200
@@ -114,9 +114,9 @@ nestedhvm_flushtlb_ipi(void *info)
void
nestedhvm_vmcx_flushtlb(struct p2m_domain *p2m)
{
- on_selected_cpus(&p2m->p2m_dirty_cpumask, nestedhvm_flushtlb_ipi,
+ on_selected_cpus(p2m->dirty_cpumask, nestedhvm_flushtlb_ipi,
p2m->domain, 1);
- cpumask_clear(&p2m->p2m_dirty_cpumask);
+ cpumask_clear(p2m->dirty_cpumask);
}
bool_t
--- 2011-10-18.orig/xen/arch/x86/mm/hap/nested_hap.c 2011-10-21 09:24:51.000000000 +0200
+++ 2011-10-18/xen/arch/x86/mm/hap/nested_hap.c 2011-10-18 16:44:35.000000000 +0200
@@ -88,7 +88,7 @@ nestedp2m_write_p2m_entry(struct p2m_dom
safe_write_pte(p, new);
if (old_flags & _PAGE_PRESENT)
- flush_tlb_mask(&p2m->p2m_dirty_cpumask);
+ flush_tlb_mask(p2m->dirty_cpumask);
paging_unlock(d);
}
--- 2011-10-18.orig/xen/arch/x86/mm/p2m.c 2011-10-14 09:47:46.000000000 +0200
+++ 2011-10-18/xen/arch/x86/mm/p2m.c 2011-10-21 09:28:33.000000000 +0200
@@ -81,7 +81,6 @@ static void p2m_initialise(struct domain
p2m->default_access = p2m_access_rwx;
p2m->cr3 = CR3_EADDR;
- cpumask_clear(&p2m->p2m_dirty_cpumask);
if ( hap_enabled(d) && (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) )
ept_p2m_init(p2m);
@@ -102,6 +101,8 @@ p2m_init_nestedp2m(struct domain *d)
d->arch.nested_p2m[i] = p2m = xzalloc(struct p2m_domain);
if (p2m == NULL)
return -ENOMEM;
+ if ( !zalloc_cpumask_var(&p2m->dirty_cpumask) )
+ return -ENOMEM;
p2m_initialise(d, p2m);
p2m->write_p2m_entry = nestedp2m_write_p2m_entry;
list_add(&p2m->np2m_list, &p2m_get_hostp2m(d)->np2m_list);
@@ -118,6 +119,11 @@ int p2m_init(struct domain *d)
p2m_get_hostp2m(d) = p2m = xzalloc(struct p2m_domain);
if ( p2m == NULL )
return -ENOMEM;
+ if ( !zalloc_cpumask_var(&p2m->dirty_cpumask) )
+ {
+ xfree(p2m);
+ return -ENOMEM;
+ }
p2m_initialise(d, p2m);
/* Must initialise nestedp2m unconditionally
@@ -333,6 +339,9 @@ static void p2m_teardown_nestedp2m(struc
uint8_t i;
for (i = 0; i < MAX_NESTEDP2M; i++) {
+ if ( !d->arch.nested_p2m[i] )
+ continue;
+ free_cpumask_var(d->arch.nested_p2m[i]->dirty_cpumask);
xfree(d->arch.nested_p2m[i]);
d->arch.nested_p2m[i] = NULL;
}
@@ -341,8 +350,12 @@ static void p2m_teardown_nestedp2m(struc
void p2m_final_teardown(struct domain *d)
{
/* Iterate over all p2m tables per domain */
- xfree(d->arch.p2m);
- d->arch.p2m = NULL;
+ if ( d->arch.p2m )
+ {
+ free_cpumask_var(d->arch.p2m->dirty_cpumask);
+ xfree(d->arch.p2m);
+ d->arch.p2m = NULL;
+ }
/* We must teardown unconditionally because
* we initialise them unconditionally.
@@ -1200,7 +1213,7 @@ p2m_get_nestedp2m(struct vcpu *v, uint64
if (p2m->cr3 == CR3_EADDR)
hvm_asid_flush_vcpu(v);
p2m->cr3 = cr3;
- cpu_set(v->processor, p2m->p2m_dirty_cpumask);
+ cpumask_set_cpu(v->processor, p2m->dirty_cpumask);
p2m_unlock(p2m);
nestedp2m_unlock(d);
return p2m;
@@ -1217,7 +1230,7 @@ p2m_get_nestedp2m(struct vcpu *v, uint64
p2m->cr3 = cr3;
nv->nv_flushp2m = 0;
hvm_asid_flush_vcpu(v);
- cpu_set(v->processor, p2m->p2m_dirty_cpumask);
+ cpumask_set_cpu(v->processor, p2m->dirty_cpumask);
p2m_unlock(p2m);
nestedp2m_unlock(d);
--- 2011-10-18.orig/xen/include/asm-x86/p2m.h 2011-10-21 09:24:51.000000000 +0200
+++ 2011-10-18/xen/include/asm-x86/p2m.h 2011-10-18 16:39:34.000000000 +0200
@@ -198,7 +198,7 @@ struct p2m_domain {
* this p2m and those physical cpus whose vcpu's are in
* guestmode.
*/
- cpumask_t p2m_dirty_cpumask;
+ cpumask_var_t dirty_cpumask;
struct domain *domain; /* back pointer to domain */
changeset: 23986:253073b522f8
user: Jan Beulich <jbeulich@suse.com>
date: Fri Oct 21 09:23:05 2011 +0200
allocate CPU sibling and core maps dynamically
... thus reducing the per-CPU data area size back to one page even when
building for large NR_CPUS.
At once eliminate the old __cpu{mask,list}_scnprintf() helpers.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 23985:eef4641d6726
user: Jan Beulich <jbeulich@suse.com>
date: Fri Oct 21 09:22:02 2011 +0200
x86: allocate IRQ actions' cpu_eoi_map dynamically
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 23984:07d303ff2757
user: Jan Beulich <jbeulich@suse.com>
date: Fri Oct 21 09:21:09 2011 +0200
eliminate direct assignments of CPU masks
Use cpumask_copy() instead of direct variable assignments for copying
CPU masks. While direct assignments are not a problem when both sides
are variables actually defined as cpumask_t (except for possibly
copying *much* more than would actually need to be copied), they must
not happen when the original variable is of type cpumask_var_t (which
may have lass space allocated to it than a full cpumask_t). Eliminate
as many of such assignments as possible (in several cases it's even
possible to collapse two operations [copy then clear one bit] into one
[cpumask_andnot()]), and thus set the way for reducing the allocation
size in alloc_cpumask_var().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 23983:1a4223c62ee7
user: Jan Beulich <jbeulich@suse.com>
date: Fri Oct 21 09:19:44 2011 +0200
eliminate cpumask accessors referencing NR_CPUS
... in favor of using the new, nr_cpumask_bits-based ones.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 23982:511d5e65a302
user: Jan Beulich <jbeulich@suse.com>
date: Fri Oct 21 09:17:42 2011 +0200
introduce and use nr_cpu_ids and nr_cpumask_bits
The former is the runtime equivalent of NR_CPUS (and users of NR_CPUS,
where necessary, get adjusted accordingly), while the latter is for the
sole use of determining the allocation size when dynamically allocating
CPU masks (done later in this series).
Adjust accessors to use either of the two to bound their bitmap
operations - which one gets used depends on whether accessing the bits
in the gap between nr_cpu_ids and nr_cpumask_bits is benign but more
efficient.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 23981:6c583d35d76d
user: Tim Deegan <tim@xen.org>
date: Thu Oct 20 15:36:01 2011 +0100
x86/mm/p2m: don't leak state if nested-p2m init fails.
Signed-off-by: Tim Deegan <tim@xen.org>
========================================
commit 25378e0a76b282127e9ab8933a4defbc91db3862
Author: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Thu Oct 6 18:38:08 2011 +0100
remove blktap when building for NetBSD
NetBSD has no blktap support, so remove the use of the blktap if the
OS is NetBSD.
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
^ permalink raw reply
* [PATCH 02/15] ATA : vortex86 : fix vortex86dx/sx hardware CRC bug.
From: Paul Schilling @ 2011-10-23 5:05 UTC (permalink / raw)
To: Jeff Garzik, David S. Miller, Jesse Barnes, linux-ide,
linux-kernel, linux-pci@
Cc: Paul Schilling, Paul Schilling
In-Reply-To: <fix vortex86>
This fixes a DMA issue related to a CRC bug on
the RDC pata peripherial found on the vortex86sx and vortex86dx.
Signed-off-by: Paul Schilling <paul.s.schilling@gmail.com>
---
drivers/ata/pata_it821x.c | 22 ++++++++++++++++++----
drivers/ata/pata_rdc.c | 29 ++++++++++++++++++++++++-----
drivers/ide/it821x.c | 9 +++++++--
include/linux/pci_ids.h | 2 ++
4 files changed, 51 insertions(+), 11 deletions(-)
diff --git a/drivers/ata/pata_it821x.c b/drivers/ata/pata_it821x.c
index c5532b9..5f8a54a 100644
--- a/drivers/ata/pata_it821x.c
+++ b/drivers/ata/pata_it821x.c
@@ -897,7 +897,16 @@ static int it821x_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
static const struct ata_port_info info_rdc_11 = {
.flags = ATA_FLAG_SLAVE_POSS,
.pio_mask = ATA_PIO4,
- .mwdma_mask = ATA_MWDMA2,
+ .mwdma_mask = 0,
+ .udma_mask = 0,
+ /* No UDMA */
+ .port_ops = &it821x_rdc_port_ops
+ };
+ static const struct ata_port_info info_rdc_01 = {
+ .flags = ATA_FLAG_SLAVE_POSS,
+ .pio_mask = ATA_PIO4,
+ .mwdma_mask = 0,
+ .udma_mask = 0,
/* No UDMA */
.port_ops = &it821x_rdc_port_ops
};
@@ -911,11 +920,16 @@ static int it821x_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
return rc;
if (pdev->vendor == PCI_VENDOR_ID_RDC) {
- /* Deal with Vortex86SX */
- if (pdev->revision == 0x11)
+ if (((pdev->revision == 0x11) || (pdev->revision == 0x13)) &&
+ (pdev->device == PCI_DEVICE_ID_RDC_D1010)) {
+ /* Deal with Vortex86SX */
ppi[0] = &info_rdc_11;
- else
+ printk(KERN_INFO DRV_NAME
+ ": Detected Vortex86SX/DX Bug.\n");
+ printk(KERN_INFO DRV_NAME ": Disabling UDMA.\n");
+ } else {
ppi[0] = &info_rdc;
+ }
} else {
/* Force the card into bypass mode if so requested */
if (it8212_noraid) {
diff --git a/drivers/ata/pata_rdc.c b/drivers/ata/pata_rdc.c
index 2b38127..441521c 100644
--- a/drivers/ata/pata_rdc.c
+++ b/drivers/ata/pata_rdc.c
@@ -290,6 +290,16 @@ static struct ata_port_info rdc_port_info = {
.port_ops = &rdc_pata_ops,
};
+static struct ata_port_info vortex_port_info = {
+ .flags = ATA_FLAG_SLAVE_POSS,
+ .pio_mask = ATA_PIO4,
+ .mwdma_mask = 0,
+ .udma_mask = 0,
+ /* No UDMA */
+ .port_ops = &rdc_pata_ops,
+};
+
+
static struct scsi_host_template rdc_sht = {
ATA_BMDMA_SHT(DRV_NAME),
};
@@ -322,16 +332,25 @@ static int __devinit rdc_init_one(struct pci_dev *pdev,
ata_print_version_once(&pdev->dev, DRV_VERSION);
- port_info[0] = rdc_port_info;
- port_info[1] = rdc_port_info;
-
- port_flags = port_info[0].flags;
-
/* enable device and prepare host */
rc = pcim_enable_device(pdev);
if (rc)
return rc;
+ if ((pdev->revision == 0x01) &&
+ (pdev->device == PCI_DEVICE_ID_RDC_D1011)) {
+ /* Deal with Vortex86DX */
+ port_info[0] = vortex_port_info;
+ port_info[1] = vortex_port_info;
+ printk(KERN_INFO DRV_NAME ": Detected Vortex86DX Bug.\n");
+ printk(KERN_INFO DRV_NAME ": Disabling UDMA.\n");
+ } else {
+ port_info[0] = rdc_port_info;
+ port_info[1] = rdc_port_info;
+ }
+
+ port_flags = port_info[0].flags;
+
hpriv = devm_kzalloc(dev, sizeof(*hpriv), GFP_KERNEL);
if (!hpriv)
return -ENOMEM;
diff --git a/drivers/ide/it821x.c b/drivers/ide/it821x.c
index 2e3169f..82c6bc7 100644
--- a/drivers/ide/it821x.c
+++ b/drivers/ide/it821x.c
@@ -581,10 +581,14 @@ static void __devinit init_hwif_it821x(ide_hwif_t *hwif)
hwif->ultra_mask = ATA_UDMA6;
hwif->mwdma_mask = ATA_MWDMA2;
- /* Vortex86SX quirk: prevent Ultra-DMA mode to fix BadCRC issue */
+ /* Vortex86SX and Vortex86DX quirk: prevent
+ * Ultra-DMA mode to fix BadCRC issue when
+ * using DMA mode */
if (idev->quirks & QUIRK_VORTEX86) {
- if (dev->revision == 0x11)
+ if (((dev->revision == 0x11) || (dev->revision == 0x13))
+ || (dev->revision == 0x01)) {
hwif->ultra_mask = 0;
+ }
}
}
@@ -680,6 +684,7 @@ static const struct pci_device_id it821x_pci_tbl[] = {
{ PCI_VDEVICE(ITE, PCI_DEVICE_ID_ITE_8211), 0 },
{ PCI_VDEVICE(ITE, PCI_DEVICE_ID_ITE_8212), 0 },
{ PCI_VDEVICE(RDC, PCI_DEVICE_ID_RDC_D1010), QUIRK_VORTEX86 },
+ { PCI_VDEVICE(RDC, PCI_DEVICE_ID_RDC_D1011), QUIRK_VORTEX86 },
{ 0, },
};
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index ae96bbe..237da92 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2259,6 +2259,8 @@
#define PCI_DEVICE_ID_RDC_R6060 0x6060
#define PCI_DEVICE_ID_RDC_R6061 0x6061
#define PCI_DEVICE_ID_RDC_D1010 0x1010
+#define PCI_DEVICE_ID_RDC_D1011 0x1011
+#define PCI_DEVICE_ID_RDC_D1012 0x1012
#define PCI_VENDOR_ID_LENOVO 0x17aa
--
1.7.6.4
^ permalink raw reply related
* [PATCH 01/15] ATA : it821x and rdc : fix code formating.
From: Paul Schilling @ 2011-10-23 5:01 UTC (permalink / raw)
To: Jeff Garzik, David S. Miller, Jesse Barnes, linux-ide,
linux-kernel, linux-pci@
Cc: Paul Schilling, Paul Schilling
In-Reply-To: <ATA it821x rdc>
This fixes a DMA issue related to a CRC bug on
the RDC pata peripherial found on the vortex86sx and vortex86dx.
Signed-off-by: Paul Schilling <paul.s.schilling@gmail.com>
---
drivers/ata/pata_it821x.c | 221 ++++++++++++++++++++++-----------------------
drivers/ata/pata_rdc.c | 4 +-
2 files changed, 112 insertions(+), 113 deletions(-)
diff --git a/drivers/ata/pata_it821x.c b/drivers/ata/pata_it821x.c
index 62c5d00..c5532b9 100644
--- a/drivers/ata/pata_it821x.c
+++ b/drivers/ata/pata_it821x.c
@@ -1,5 +1,5 @@
/*
- * pata_it821x.c - IT821x PATA for new ATA layer
+ * pata_it821x.c - IT821x PATA for new ATA layer
* (C) 2005 Red Hat Inc
* Alan Cox <alan@lxorguk.ukuu.org.uk>
* (C) 2007 Bartlomiej Zolnierkiewicz
@@ -16,7 +16,7 @@
* Based in part on the ITE vendor provided SCSI driver.
*
* Documentation available from IT8212F_V04.pdf
- * http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&ID=5,91
+ * http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3&ID=5,91
* Some other documents are NDA.
*
* The ITE8212 isn't exactly a standard IDE controller. It has two
@@ -79,22 +79,20 @@
#include <scsi/scsi_host.h>
#include <linux/libata.h>
-
#define DRV_NAME "pata_it821x"
#define DRV_VERSION "0.4.2"
-struct it821x_dev
-{
- unsigned int smart:1, /* Are we in smart raid mode */
- timing10:1; /* Rev 0x10 */
- u8 clock_mode; /* 0, ATA_50 or ATA_66 */
- u8 want[2][2]; /* Mode/Pri log for master slave */
+struct it821x_dev {
+ unsigned int smart:1, /* Are we in smart raid mode */
+ timing10:1; /* Rev 0x10 */
+ u8 clock_mode; /* 0, ATA_50 or ATA_66 */
+ u8 want[2][2]; /* Mode/Pri log for master slave */
/* We need these for switching the clock when DMA goes on/off
The high byte is the 66Mhz timing */
- u16 pio[2]; /* Cached PIO values */
- u16 mwdma[2]; /* Cached MWDMA values */
- u16 udma[2]; /* Cached UDMA values (per drive) */
- u16 last_device; /* Master or slave loaded ? */
+ u16 pio[2]; /* Cached PIO values */
+ u16 mwdma[2]; /* Cached MWDMA values */
+ u16 udma[2]; /* Cached UDMA values (per drive) */
+ u16 last_device; /* Master or slave loaded ? */
};
#define ATA_66 0
@@ -124,7 +122,8 @@ static int it8212_noraid;
* the DMA start/stop sequence as with the old driver.
*/
-static void it821x_program(struct ata_port *ap, struct ata_device *adev, u16 timing)
+static void it821x_program(struct ata_port *ap, struct ata_device *adev,
+ u16 timing)
{
struct pci_dev *pdev = to_pci_dev(ap->host->dev);
struct it821x_dev *itdev = ap->private_data;
@@ -139,7 +138,6 @@ static void it821x_program(struct ata_port *ap, struct ata_device *adev, u16 tim
pci_write_config_byte(pdev, 0x54 + 4 * channel, conf);
}
-
/**
* it821x_program_udma - program the UDMA registers
* @ap: ATA port
@@ -152,7 +150,8 @@ static void it821x_program(struct ata_port *ap, struct ata_device *adev, u16 tim
* here and partly in start_dma.
*/
-static void it821x_program_udma(struct ata_port *ap, struct ata_device *adev, u16 timing)
+static void it821x_program_udma(struct ata_port *ap, struct ata_device *adev,
+ u16 timing)
{
struct it821x_dev *itdev = ap->private_data;
struct pci_dev *pdev = to_pci_dev(ap->host->dev);
@@ -227,16 +226,16 @@ static void it821x_clock_strategy(struct ata_port *ap, struct ata_device *adev)
pci_write_config_byte(pdev, 0x50, v);
/*
- * Reprogram the UDMA/PIO of the pair drive for the switch
- * MWDMA will be dealt with by the dma switcher
+ * Reprogram the UDMA/PIO of the pair drive for the switch
+ * MWDMA will be dealt with by the dma switcher
*/
- if (pair && itdev->udma[1-unit] != UDMA_OFF) {
- it821x_program_udma(ap, pair, itdev->udma[1-unit]);
- it821x_program(ap, pair, itdev->pio[1-unit]);
+ if (pair && itdev->udma[1 - unit] != UDMA_OFF) {
+ it821x_program_udma(ap, pair, itdev->udma[1 - unit]);
+ it821x_program(ap, pair, itdev->pio[1 - unit]);
}
/*
- * Reprogram the UDMA/PIO of our drive for the switch.
- * MWDMA will be dealt with by the dma switcher
+ * Reprogram the UDMA/PIO of our drive for the switch.
+ * MWDMA will be dealt with by the dma switcher
*/
if (itdev->udma[unit] != UDMA_OFF) {
it821x_program_udma(ap, adev, itdev->udma[unit]);
@@ -253,11 +252,13 @@ static void it821x_clock_strategy(struct ata_port *ap, struct ata_device *adev)
* shared by PIO and MWDMA and for both channels.
*/
-static void it821x_passthru_set_piomode(struct ata_port *ap, struct ata_device *adev)
+static void it821x_passthru_set_piomode(struct ata_port *ap,
+ struct ata_device *adev)
{
/* Spec says 89 ref driver uses 88 */
- static const u16 pio[] = { 0xAA88, 0xA382, 0xA181, 0x3332, 0x3121 };
- static const u8 pio_want[] = { ATA_66, ATA_66, ATA_66, ATA_66, ATA_ANY };
+ static const u16 pio[] = { 0xAA88, 0xA382, 0xA181, 0x3332, 0x3121 };
+ static const u8 pio_want[] = {
+ ATA_66, ATA_66, ATA_66, ATA_66, ATA_ANY };
struct it821x_dev *itdev = ap->private_data;
int unit = adev->devno;
@@ -283,12 +284,17 @@ static void it821x_passthru_set_piomode(struct ata_port *ap, struct ata_device *
* we switch devices and mode.
*/
-static void it821x_passthru_set_dmamode(struct ata_port *ap, struct ata_device *adev)
+static void it821x_passthru_set_dmamode(struct ata_port *ap,
+ struct ata_device *adev)
{
- static const u16 dma[] = { 0x8866, 0x3222, 0x3121 };
- static const u8 mwdma_want[] = { ATA_ANY, ATA_66, ATA_ANY };
- static const u16 udma[] = { 0x4433, 0x4231, 0x3121, 0x2121, 0x1111, 0x2211, 0x1111 };
- static const u8 udma_want[] = { ATA_ANY, ATA_50, ATA_ANY, ATA_66, ATA_66, ATA_50, ATA_66 };
+ static const u16 dma[] = { 0x8866, 0x3222, 0x3121 };
+ static const u8 mwdma_want[] = { ATA_ANY, ATA_66, ATA_ANY };
+ static const u16 udma[] = {
+ 0x4433, 0x4231, 0x3121,
+ 0x2121, 0x1111, 0x2211, 0x1111 };
+ static const u8 udma_want[] = {
+ ATA_ANY, ATA_50, ATA_ANY,
+ ATA_66, ATA_66, ATA_50, ATA_66 };
struct pci_dev *pdev = to_pci_dev(ap->host->dev);
struct it821x_dev *itdev = ap->private_data;
@@ -309,9 +315,9 @@ static void it821x_passthru_set_dmamode(struct ata_port *ap, struct ata_device *
/* UDMA on. Again revision 0x10 must do the pair */
pci_read_config_byte(pdev, 0x50, &conf);
if (itdev->timing10)
- conf &= channel ? 0x9F: 0xE7;
+ conf &= channel ? 0x9F : 0xE7;
else
- conf &= ~ (1 << (3 + 2 * channel + unit));
+ conf &= ~(1 << (3 + 2 * channel + unit));
pci_write_config_byte(pdev, 0x50, conf);
it821x_clock_strategy(ap, adev);
it821x_program_udma(ap, adev, itdev->udma[unit]);
@@ -326,7 +332,7 @@ static void it821x_passthru_set_dmamode(struct ata_port *ap, struct ata_device *
/* UDMA bits off - Revision 0x10 do them in pairs */
pci_read_config_byte(pdev, 0x50, &conf);
if (itdev->timing10)
- conf |= channel ? 0x60: 0x18;
+ conf |= channel ? 0x60 : 0x18;
else
conf |= 1 << (3 + 2 * channel + unit);
pci_write_config_byte(pdev, 0x50, conf);
@@ -378,7 +384,6 @@ static void it821x_passthru_bmdma_stop(struct ata_queued_cmd *qc)
it821x_program(ap, adev, itdev->pio[unit]);
}
-
/**
* it821x_passthru_dev_select - Select master/slave
* @ap: ATA port
@@ -387,8 +392,7 @@ static void it821x_passthru_bmdma_stop(struct ata_queued_cmd *qc)
* Device selection hook. If necessary perform clock switching
*/
-static void it821x_passthru_dev_select(struct ata_port *ap,
- unsigned int device)
+static void it821x_passthru_dev_select(struct ata_port *ap, unsigned int device)
{
struct it821x_dev *itdev = ap->private_data;
if (itdev && device != itdev->last_device) {
@@ -410,29 +414,29 @@ static void it821x_passthru_dev_select(struct ata_port *ap,
static unsigned int it821x_smart_qc_issue(struct ata_queued_cmd *qc)
{
- switch(qc->tf.command)
- {
+ switch (qc->tf.command) {
/* Commands the firmware supports */
- case ATA_CMD_READ:
- case ATA_CMD_READ_EXT:
- case ATA_CMD_WRITE:
- case ATA_CMD_WRITE_EXT:
- case ATA_CMD_PIO_READ:
- case ATA_CMD_PIO_READ_EXT:
- case ATA_CMD_PIO_WRITE:
- case ATA_CMD_PIO_WRITE_EXT:
- case ATA_CMD_READ_MULTI:
- case ATA_CMD_READ_MULTI_EXT:
- case ATA_CMD_WRITE_MULTI:
- case ATA_CMD_WRITE_MULTI_EXT:
- case ATA_CMD_ID_ATA:
- case ATA_CMD_INIT_DEV_PARAMS:
- case 0xFC: /* Internal 'report rebuild state' */
+ case ATA_CMD_READ:
+ case ATA_CMD_READ_EXT:
+ case ATA_CMD_WRITE:
+ case ATA_CMD_WRITE_EXT:
+ case ATA_CMD_PIO_READ:
+ case ATA_CMD_PIO_READ_EXT:
+ case ATA_CMD_PIO_WRITE:
+ case ATA_CMD_PIO_WRITE_EXT:
+ case ATA_CMD_READ_MULTI:
+ case ATA_CMD_READ_MULTI_EXT:
+ case ATA_CMD_WRITE_MULTI:
+ case ATA_CMD_WRITE_MULTI_EXT:
+ case ATA_CMD_ID_ATA:
+ case ATA_CMD_INIT_DEV_PARAMS:
+ case 0xFC: /* Internal 'report rebuild state' */
/* Arguably should just no-op this one */
- case ATA_CMD_SET_FEATURES:
- return ata_bmdma_qc_issue(qc);
+ case ATA_CMD_SET_FEATURES:
+ return ata_bmdma_qc_issue(qc);
}
- printk(KERN_DEBUG "it821x: can't process command 0x%02X\n", qc->tf.command);
+ printk(KERN_DEBUG "it821x: can't process command 0x%02X\n",
+ qc->tf.command);
return AC_ERR_DEV;
}
@@ -462,7 +466,8 @@ static unsigned int it821x_passthru_qc_issue(struct ata_queued_cmd *qc)
* and respect them.
*/
-static int it821x_smart_set_mode(struct ata_link *link, struct ata_device **unused)
+static int it821x_smart_set_mode(struct ata_link *link,
+ struct ata_device **unused)
{
struct ata_device *dev;
@@ -509,8 +514,7 @@ static void it821x_dev_config(struct ata_device *adev)
if (strstr(model_num, "Integrated Technology Express")) {
/* RAID mode */
ata_dev_info(adev, "%sRAID%d volume",
- adev->id[147] ? "Bootable " : "",
- adev->id[129]);
+ adev->id[147] ? "Bootable " : "", adev->id[129]);
if (adev->id[129] != 1)
pr_cont("(%dK stripe)", adev->id[146]);
pr_cont("\n");
@@ -535,7 +539,7 @@ static void it821x_dev_config(struct ata_device *adev)
*/
static unsigned int it821x_read_id(struct ata_device *adev,
- struct ata_taskfile *tf, u16 *id)
+ struct ata_taskfile *tf, u16 * id)
{
unsigned int err_mask;
unsigned char model_num[ATA_ID_PROD_LEN + 1];
@@ -616,7 +620,7 @@ static void it821x_display_disk(int n, u8 *buf)
if (buf[52] > 4) /* No Disk */
return;
- ata_id_c_string((u16 *)buf, id, 0, 41);
+ ata_id_c_string((u16 *) buf, id, 0, 41);
if (buf[51]) {
mode = ffs(buf[51]);
@@ -635,10 +639,10 @@ static void it821x_display_disk(int n, u8 *buf)
strcpy(mbuf, "PIO");
if (buf[52] == 4)
printk(KERN_INFO "%d: %-6s %-8s %s %s\n",
- n, mbuf, types[buf[52]], id, cbl);
+ n, mbuf, types[buf[52]], id, cbl);
else
printk(KERN_INFO "%d: %-6s %-8s Volume: %1d %s %s\n",
- n, mbuf, types[buf[52]], buf[53], id, cbl);
+ n, mbuf, types[buf[52]], buf[53], id, cbl);
if (buf[125] < 100)
printk(KERN_INFO "%d: Rebuilding: %d%%\n", n, buf[125]);
}
@@ -673,7 +677,7 @@ static u8 *it821x_firmware_command(struct ata_port *ap, u8 cmd, int len)
udelay(1);
/* This should be almost immediate but a little paranoia goes a long
way. */
- while(n++ < 10) {
+ while (n++ < 10) {
status = ioread8(ap->ioaddr.status_addr);
if (status & ATA_ERR) {
kfree(buf);
@@ -681,8 +685,8 @@ static u8 *it821x_firmware_command(struct ata_port *ap, u8 cmd, int len)
return NULL;
}
if (status & ATA_DRQ) {
- ioread16_rep(ap->ioaddr.data_addr, buf, len/2);
- return (u8 *)buf;
+ ioread16_rep(ap->ioaddr.data_addr, buf, len / 2);
+ return (u8 *) buf;
}
mdelay(1);
}
@@ -711,18 +715,13 @@ static void it821x_probe_firmware(struct ata_port *ap)
if (buf != NULL) {
printk(KERN_INFO "pata_it821x: Firmware %02X/%02X/%02X%02X\n",
- buf[505],
- buf[506],
- buf[507],
- buf[508]);
+ buf[505], buf[506], buf[507], buf[508]);
for (i = 0; i < 4; i++)
- it821x_display_disk(i, buf + 128 * i);
+ it821x_display_disk(i, buf + 128 * i);
kfree(buf);
}
}
-
-
/**
* it821x_port_start - port setup
* @ap: ATA port being set up
@@ -772,7 +771,8 @@ static int it821x_port_start(struct ata_port *ap)
itdev->timing10 = 1;
/* Need to disable ATAPI DMA for this case */
if (!itdev->smart)
- printk(KERN_WARNING DRV_NAME": Revision 0x10, workarounds activated.\n");
+ printk(KERN_WARNING DRV_NAME
+ ": Revision 0x10, workarounds activated.\n");
}
return 0;
@@ -802,57 +802,57 @@ static struct scsi_host_template it821x_sht = {
};
static struct ata_port_operations it821x_smart_port_ops = {
- .inherits = &ata_bmdma_port_ops,
+ .inherits = &ata_bmdma_port_ops,
- .check_atapi_dma= it821x_check_atapi_dma,
- .qc_issue = it821x_smart_qc_issue,
+ .check_atapi_dma = it821x_check_atapi_dma,
+ .qc_issue = it821x_smart_qc_issue,
- .cable_detect = ata_cable_80wire,
- .set_mode = it821x_smart_set_mode,
- .dev_config = it821x_dev_config,
- .read_id = it821x_read_id,
+ .cable_detect = ata_cable_80wire,
+ .set_mode = it821x_smart_set_mode,
+ .dev_config = it821x_dev_config,
+ .read_id = it821x_read_id,
- .port_start = it821x_port_start,
+ .port_start = it821x_port_start,
};
static struct ata_port_operations it821x_passthru_port_ops = {
- .inherits = &ata_bmdma_port_ops,
+ .inherits = &ata_bmdma_port_ops,
- .check_atapi_dma= it821x_check_atapi_dma,
- .sff_dev_select = it821x_passthru_dev_select,
- .bmdma_start = it821x_passthru_bmdma_start,
- .bmdma_stop = it821x_passthru_bmdma_stop,
- .qc_issue = it821x_passthru_qc_issue,
+ .check_atapi_dma = it821x_check_atapi_dma,
+ .sff_dev_select = it821x_passthru_dev_select,
+ .bmdma_start = it821x_passthru_bmdma_start,
+ .bmdma_stop = it821x_passthru_bmdma_stop,
+ .qc_issue = it821x_passthru_qc_issue,
- .cable_detect = ata_cable_unknown,
- .set_piomode = it821x_passthru_set_piomode,
- .set_dmamode = it821x_passthru_set_dmamode,
+ .cable_detect = ata_cable_unknown,
+ .set_piomode = it821x_passthru_set_piomode,
+ .set_dmamode = it821x_passthru_set_dmamode,
- .port_start = it821x_port_start,
+ .port_start = it821x_port_start,
};
static struct ata_port_operations it821x_rdc_port_ops = {
- .inherits = &ata_bmdma_port_ops,
+ .inherits = &ata_bmdma_port_ops,
- .check_atapi_dma= it821x_check_atapi_dma,
- .sff_dev_select = it821x_passthru_dev_select,
- .bmdma_start = it821x_passthru_bmdma_start,
- .bmdma_stop = it821x_passthru_bmdma_stop,
- .qc_issue = it821x_passthru_qc_issue,
+ .check_atapi_dma = it821x_check_atapi_dma,
+ .sff_dev_select = it821x_passthru_dev_select,
+ .bmdma_start = it821x_passthru_bmdma_start,
+ .bmdma_stop = it821x_passthru_bmdma_stop,
+ .qc_issue = it821x_passthru_qc_issue,
- .cable_detect = it821x_rdc_cable,
- .set_piomode = it821x_passthru_set_piomode,
- .set_dmamode = it821x_passthru_set_dmamode,
+ .cable_detect = it821x_rdc_cable,
+ .set_piomode = it821x_passthru_set_piomode,
+ .set_dmamode = it821x_passthru_set_dmamode,
- .port_start = it821x_port_start,
+ .port_start = it821x_port_start,
};
static void it821x_disable_raid(struct pci_dev *pdev)
{
/* Neither the RDC nor the IT8211 */
if (pdev->vendor != PCI_VENDOR_ID_ITE ||
- pdev->device != PCI_DEVICE_ID_ITE_8212)
- return;
+ pdev->device != PCI_DEVICE_ID_ITE_8212)
+ return;
/* Reset local CPU, and set BIOS not ready */
pci_write_config_byte(pdev, 0x5E, 0x01);
@@ -864,12 +864,11 @@ static void it821x_disable_raid(struct pci_dev *pdev)
PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER);
pci_write_config_word(pdev, 0x40, 0xA0F3);
- pci_write_config_dword(pdev,0x4C, 0x02040204);
+ pci_write_config_dword(pdev, 0x4C, 0x02040204);
pci_write_config_byte(pdev, 0x42, 0x36);
pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 0x20);
}
-
static int it821x_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
{
u8 conf;
@@ -926,8 +925,8 @@ static int it821x_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
pci_read_config_byte(pdev, 0x50, &conf);
conf &= 1;
- printk(KERN_INFO DRV_NAME": controller in %s mode.\n",
- mode[conf]);
+ printk(KERN_INFO DRV_NAME ": controller in %s mode.\n",
+ mode[conf]);
if (conf == 0)
ppi[0] = &info_passthru;
else
@@ -983,12 +982,12 @@ static void __exit it821x_exit(void)
}
MODULE_AUTHOR("Alan Cox");
-MODULE_DESCRIPTION("low-level driver for the IT8211/IT8212 IDE RAID controller");
+MODULE_DESCRIPTION
+("low-level driver for the IT8211/IT8212 IDE RAID controller");
MODULE_LICENSE("GPL");
MODULE_DEVICE_TABLE(pci, it821x);
MODULE_VERSION(DRV_VERSION);
-
module_param_named(noraid, it8212_noraid, int, S_IRUGO);
MODULE_PARM_DESC(noraid, "Force card into bypass mode");
diff --git a/drivers/ata/pata_rdc.c b/drivers/ata/pata_rdc.c
index 4d318f8..2b38127 100644
--- a/drivers/ata/pata_rdc.c
+++ b/drivers/ata/pata_rdc.c
@@ -365,8 +365,8 @@ static void rdc_remove_one(struct pci_dev *pdev)
}
static const struct pci_device_id rdc_pci_tbl[] = {
- { PCI_DEVICE(0x17F3, 0x1011), },
- { PCI_DEVICE(0x17F3, 0x1012), },
+ { PCI_VDEVICE(RDC, PCI_DEVICE_ID_RDC_D1011), },
+ { PCI_VDEVICE(RDC, PCI_DEVICE_ID_RDC_D1012), },
{ } /* terminate list */
};
--
1.7.6.4
^ permalink raw reply related
* Question about: linux-linaro-2.6.38.7 booting the ubuntu 10.10 filesystem
From: David Yang @ 2011-10-23 4:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111022133759.GB21374@n2100.arm.linux.org.uk>
No,I just ported the kernel from 2.6.33 to 2.6.38.
So I didn't select the HAVE_SCHED_CLOCK?
And I have tested it.
When I select the HAVE_SCHED_CLOCK.
the kernel will hang after uncompressing the kernel.
Best Regards,
David
On Sat, Oct 22, 2011 at 9:37 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Oct 22, 2011 at 05:35:52PM +0800, David Yang wrote:
>> ?I found in my timer driver,I didn't implement the "init_sched_clock"
>> function.
>
> Have you selected HAVE_SCHED_CLOCK ?
>
^ permalink raw reply
* git mergetool ignores configured command line
From: Alexander Vladimirov @ 2011-10-23 4:43 UTC (permalink / raw)
To: git
To configure diffuse as merge tool I set mergetool configuration using
following commands:
git config --global merge.tool diffuse
git config --global mergetool.diffuse.cmd '/usr/bin/diffuse "$LOCAL"
"$MERGED" "$REMOTE"'
Then, when I invoke mergetool during merge, I get diffuse with four
panes open as by default, instead of three specified in command line
setting.
Is this an expected behavior, and how can I force mergetool to use
provided command line?
^ permalink raw reply
* Re: [PATCH] vfs - fix automount should ignore LOOKUP_FOLLOW
From: Miklos Szeredi @ 2011-10-23 4:41 UTC (permalink / raw)
To: Ian Kent; +Cc: Linus Torvalds, Kernel Mailing List, Al Viro, David Howells
In-Reply-To: <20111022080147.11165.52913.stgit@perseus.themaw.net>
On Sat, Oct 22, 2011 at 10:01 AM, Ian Kent <raven@themaw.net> wrote:
> The recent patch by Miklos Szeredi that was meant to restore the original
> behavior of not triggering automounts on stat(2) and other symlink following
> syscalls also eliminated the unconditional triggering of automounts for
> intermediate path components by eliminating the LOOKUP_CONTUNUE flag from
> the check in fs/namei.c:follow_automount().
>
> This introduces a regression itself because it alters the original behaviour
> which was to unconditionally automount on intermediate path components.
LOOKUP_CONTINUE flag no longer exists (commit 49084c3 "kill LOOKUP_CONTINUE")
So this patch makes no sense for HEAD, it may make sense for backports.
Miklos
>
> Signed-off-by: Ian Kent <raven@themaw.net>
> ---
>
> fs/namei.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 0b3138d..e4eee7c 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -732,7 +732,7 @@ static int follow_automount(struct path *path, unsigned flags,
> * as being automount points. These will need the attentions
> * of the daemon to instantiate them before they can be used.
> */
> - if (!(flags & (LOOKUP_PARENT | LOOKUP_DIRECTORY |
> + if (!(flags & (LOOKUP_PARENT | LOOKUP_CONTINUE | LOOKUP_DIRECTORY |
> LOOKUP_OPEN | LOOKUP_CREATE | LOOKUP_AUTOMOUNT)) &&
> path->dentry->d_inode)
> return -EISDIR;
>
>
^ permalink raw reply
* [Qemu-devel] buildbot failure in qemu on xen_i386_debian_6_0
From: qemu @ 2011-10-23 5:03 UTC (permalink / raw)
To: agraf, gollub, lcapitulino, qemu-devel
The Buildbot has detected a new failure on builder xen_i386_debian_6_0 while building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/xen_i386_debian_6_0/builds/69
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: yuzuki
Build Reason: The Nightly scheduler named 'nightly_xen' triggered this build
Build Source Stamp: [branch xen-next] HEAD
Blamelist:
BUILD FAILED: failed git
sincerely,
-The Buildbot
^ permalink raw reply
* Re: NFSv4 server on ARM
From: Nigel Roberts @ 2011-10-23 3:55 UTC (permalink / raw)
To: linux-nfs
In-Reply-To: <20110529132515.GB19451@snippy.nobiscuit.com>
On 05/29/2011 11:25 PM, Nigel Roberts wrote:
> I've run into a problem with running an nfsv4 server on a Marvell
> Kirkwood (armv5tel) platform. When copying a large file (>1GB) to
> the NFS server, thewrite speed will suddenly slow down to ~750kB/s
> and the CPU wait will jump to 100% for the remainder of the transfer.
I've been doing some large file transfers recently and I've run into
another similar problem, but this time it's system CPU instead of I/O
wait. I've done some more testing and I've found the following:
* Seems to only affect nfsv4, I can't reproduce it with nfsv3
* It appears to be triggered when free memory is low i.e. the file size
is large enough to cause cache memory to reach its maximum.
* Happens with both SLAB and SLUB
* Happens with sec=krb5, krb5i and krb5p
* If I transfer a file that's small enough to fit into free memory, the
problem doesn't occur.
Here are the exports on the server (Debian squeeze + 3.0.7 kernel +
latest nfs packages from testing on an iomega ix2-200 marvell kirkwood
system)
/var/store/exports/backups
*(sec=krb5:krb5i:krb5p,rw,nohide,sync,no_subtree_check)
/var/store/exports/backups
oobie.home.nobiscuit.com(rw,async,no_subtree_check)
Here are the fstab entries on the client (Ubuntu Oneric, x86_64)
blue.home.nobiscuit.com:/var/store/exports/backups
/test/backup-nfs3 nfs rw,proto=tcp,user,noauto 0 0
blue.home.nobiscuit.com:/backups /test/backup-nfs4 nfs4
rw,proto=tcp,user,noauto,sec=krb5 0 0
Here's what a an nfsv3 transfer looks like in vmstat (vmstat 2 with swap
information removed)
procs -----------memory---------- -----io---- -system-- ----cpu----
r b swpd free buff cache bi bo in cs us sy id wa
0 0 1940 4068 8516 214252 0 0 32 10 0 0 100 0
0 0 1940 4068 8516 214252 0 0 32 11 0 0 100 0
0 0 1940 4068 8516 214252 0 0 32 9 0 0 100 0
<transfer starts here>
2 0 1940 204348 8516 16588 0 194 2139 2951 0 34 66 0
0 0 1940 190824 8516 29988 0 7522 3835 5188 0 42 59 0
1 0 1940 176148 8528 44644 0 5957 4266 5394 0 50 49 2
2 0 1940 163248 8532 57588 0 4095 3832 5006 0 34 66 0
1 0 1940 149456 8536 71308 0 5388 3972 5117 0 39 62 0
2 0 1940 137104 8544 83404 0 10068 3642 4624 0 42 56 3
4 0 1940 127336 8544 92364 0 5761 2737 3796 0 32 68 0
1 0 1940 112804 8552 107308 0 2393 4314 5613 0 42 58 1
0 0 1940 98284 8552 121612 0 8698 4131 5324 0 40 60 0
2 0 1940 84604 8552 135116 0 5316 4017 5192 0 48 52 0
0 0 1940 72244 8560 147308 0 8186 3523 4625 0 42 57 2
0 0 1940 59944 8560 159340 0 8860 3564 4602 0 41 59 0
1 0 1940 46684 8568 172396 0 2064 3824 5040 0 37 62 1
1 0 1940 33784 8568 185132 0 7026 3506 4612 0 37 63 0
1 0 1940 20824 8572 197876 0 9442 3780 4862 0 39 62 0
1 0 1940 7264 8580 211220 0 5844 3882 5133 0 42 57 2
0 0 1940 2704 8448 215824 0 4098 4271 5392 0 47 54 0
0 0 1940 2688 8452 215680 0 8450 4109 5123 1 47 50 3
0 0 1940 3064 8444 215276 0 7300 3787 4909 0 34 66 0
0 0 1940 3116 8444 215212 0 8850 3488 4524 0 37 63 0
1 0 1940 2688 8456 215564 0 8815 3982 4924 0 41 58 2
0 0 1940 2980 8448 215488 0 1 4101 5408 0 44 57 0
3 0 1940 3688 8456 214108 0 9047 3783 4880 0 44 55 2
1 0 1940 2816 8448 215636 0 8867 3285 4452 0 35 66 0
...
The transfer continues to the end with neither a sudden jump in the sy
number nor any drop in bo.
Here is a transfer with the same file to the same location, using nfsv4
with sec=krb5:
procs -----------memory---------- -----io---- -system-- ----cpu----
r b swpd free buff cache bi bo in cs us sy id wa
0 0 1940 3072 8432 215320 0 0 32 11 0 0 100 0
0 0 1940 3072 8432 215320 0 0 31 10 0 0 100 0
0 0 1940 3072 8432 215320 0 0 31 10 0 0 100 0
<transfer starts here>
0 0 1940 3072 8440 215344 6 20 75 101 0 1 97 3
0 0 1940 3072 8456 215344 0 20 125 172 1 1 93 5
0 0 1940 203404 8476 17556 0 50 2394 3514 0 44 52 5
1 0 1940 191316 8480 29216 0 9299 3333 4694 0 39 61 0
2 0 1940 179876 8496 40952 0 26 3382 4837 0 42 56 1
1 0 1940 167472 8496 53364 0 6605 3514 5091 0 37 63 0
0 0 1940 155892 8496 64948 0 5128 3249 4691 0 37 63 0
1 0 1940 144312 8504 76372 0 4664 3182 4652 0 38 61 2
1 0 1940 130856 8504 89588 0 6760 3694 5102 0 44 57 0
2 0 1940 115272 8516 104988 0 6519 4308 5937 0 50 49 2
2 0 1940 100752 8516 119220 0 5052 4062 5498 0 48 53 0
1 0 1940 85512 8516 134236 0 6425 4144 5791 0 49 51 0
0 0 1940 72192 8524 147388 0 4962 3629 5177 0 40 57 4
2 0 1940 59532 8524 159708 0 4928 3439 5080 0 33 68 0
2 0 1940 47652 8532 171452 0 15865 3290 4709 0 47 51 3
2 0 1940 33372 8532 185500 0 6142 3874 5541 0 47 54 0
3 0 1940 19632 8532 199036 0 6709 3793 5270 0 45 56 0
2 0 1940 6956 8540 211520 0 6598 3556 4900 0 40 58 2
2 0 1940 3132 8408 215328 0 4092 3494 5157 0 39 61 0
<sudden drop in performance here>
2 1 1940 2796 8540 215364 0 9439 1021 1191 0 92 9 0
1 1 1940 3096 8724 214612 0 740 429 486 0 100 0 0
1 1 1940 3096 8900 214656 0 728 424 471 0 100 0 0
1 1 1940 2856 9076 214808 0 760 449 477 0 100 0 0
1 1 1940 2616 9252 214820 0 712 420 466 0 100 0 0
1 1 1940 3096 9428 214108 0 792 467 490 0 100 0 0
1 1 1940 2976 9620 214120 0 784 456 498 0 100 0 0
1 1 1940 2556 9804 214292 0 804 461 495 0 100 0 0
...
The transfer will eventually complete, but obviously it takes much longer.
At the point where free memory reaches its lowest point, note the sudden
increase in sy and the big drop off in bo. Is it a memory allocation
problem? I've tried increasing the logging for nfsd but there's nothing
obvious that I can see.
Are there some other statistics I should be looking at? I've tried to
get ftrace working but I haven't had any luck yet (the ftrace tests fail
on boot).
Regards,
Nigel
^ permalink raw reply
* [U-Boot] [PATCH] at91: Add support for Bluewater Systems Snapper 9G45 module
From: Reinhard Meyer @ 2011-10-23 3:57 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319339348-2959-1-git-send-email-sglass@bluewatersys.com>
Dear Simon Glass,
> Snapper 9G45 is a ARM9-based CPU module with 1GB NAND and 128MB
> DDR SDRAM. This patch includes NAND and Ethernet support.
>
> Signed-off-by: Simon Glass<sglass@bluewatersys.com>
> ---
> board/bluewater/snapper9g45/Makefile | 43 +++++++
> board/bluewater/snapper9g45/snapper9g45.c | 155 +++++++++++++++++++++++
> boards.cfg | 1 +
> include/configs/snapper9g45.h | 189 +++++++++++++++++++++++++++++
> 4 files changed, 388 insertions(+), 0 deletions(-)
> create mode 100644 board/bluewater/snapper9g45/Makefile
> create mode 100644 board/bluewater/snapper9g45/snapper9g45.c
> create mode 100644 include/configs/snapper9g45.h
>
> [...]
> +
> +#ifndef NEW
> +#define CONFIG_PCA953X
> +#define CONFIG_SYS_I2C_PCA953X_ADDR 0x28
> +#define CONFIG_SYS_I2C_PCA953X_WIDTH { {0x28, 16} }
> +#endif
if that is a board variant, use something better than just "NEW" -
and where would that ever get defined?
> +/* Command line configuration */
> +#include<config_cmd_default.h>
Space missing here.
Please run checkpatch before submitting!
Best Regards,
Reinhard
^ permalink raw reply
* [PATCH] ARM: gic: fix irq_alloc_descs handling for sparse irq
From: Rob Herring @ 2011-10-23 3:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111022203635.GA30950@n2100.arm.linux.org.uk>
Russell,
On 10/22/2011 03:36 PM, Russell King - ARM Linux wrote:
> On Sat, Oct 22, 2011 at 03:20:08PM -0500, Rob Herring wrote:
>> @@ -657,7 +664,7 @@ int __init gic_of_init(struct device_node *node, struct device_node *parent)
>>
>> domain->of_node = of_node_get(node);
>>
>> - gic_init(gic_cnt, 16, dist_base, cpu_base);
>> + gic_init(gic_cnt, -1, dist_base, cpu_base);
>>
>> if (parent) {
>> irq = irq_of_parse_and_map(node, 0);
>
> You don't explain this change - '16' is used here to skip the SGI
> interrupts which will never be passed to the generic IRQ subsystem
> from the GIC.
This makes irq_alloc_descs do dynamic IRQ# assignment rather than
allocating at the specified IRQ#.
>
> Moreover, the second parameter is an unsigned integer, not a signed
> integer.
>
> And not only that, but:
>
> gic->irq_offset = (irq_start - 1) & ~31;
>
> means that irq_offset ends up being -2 & ~31, or -32. Do you really
> want the PPIs to generate IRQ numbers from -16 to -1 ? It doesn't stop
> there:
>
> for (i = irq_start; i < irq_limit; i++) {
> irq_set_chip_and_handler(i, &gic_chip, handle_fasteoi_irq);
> irq_set_chip_data(i, gic);
> set_irq_flags(i, IRQF_VALID | IRQF_PROBE);
> }
>
> This will start from -1 to irq_limit (-1 + number of GIC IRQs).
>
> Basically, -1 is not legal here - 1 is the minimum valid value that
> this function takes for proper operation - but that's just wasteful, so
> 16 is the realistic minimum value.
You're not looking at the right version of gic code. This is the basis
of this patch which has changes to the lines you reference:
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/067588.html
You are right about irq_start needing to be signed.
Rob
^ permalink raw reply
* YOUR TRANSACTION IS STOPED
From: Account Inspection service @ 2011-10-23 3:26 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 198 bytes --]
We are sorry to inform you that you package being
delivered to you has been seized please download the attachment for
information on how to receive the parcel
Best Regards,
Timothy Gale Puckett
[-- Attachment #2: upsconfirma.doc --]
[-- Type: application/msword, Size: 39936 bytes --]
^ permalink raw reply
* Re: lsusd - The Linux SUSpend Daemon
From: NeilBrown @ 2011-10-23 3:31 UTC (permalink / raw)
To: Alan Stern
Cc: John Stultz, Rafael J. Wysocki, mark gross, Linux PM list, LKML
In-Reply-To: <Pine.LNX.4.44L0.1110221223480.20346-100000@netrider.rowland.org>
[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]
On Sat, 22 Oct 2011 12:31:58 -0400 (EDT) Alan Stern
<stern@rowland.harvard.edu> wrote:
> On Fri, 21 Oct 2011, Alan Stern wrote:
>
> > > Maybe we could do something with futexes...
> >
> > Not easily -- as far as I can tell, futexes enjoy relatively little
> > support. In any case, they provide the same service as a mutex, which
> > means you'd have to build a shared lock on top of them.
>
> It occurred to me that we could create a new type of special file, one
> intended to help with interprocess synchronization. It would support
> locking (shared or exclusive, blocking or non-blocking) and the poll
> system call -- the file would appear to be ready for reading whenever a
> shared lock wouldn't block and ready for writing whenever an exclusive
> lock wouldn't block. Actual reads and writes wouldn't have to do
> anything, although maybe someone could suggest a use for them.
>
> Alan Stern
Tempting... We would need a good case to get something included, but not to
just experiment.
The approach that I would take would probably be to extent flock() with a new
flag, e.g. LOCK_POLL.
then
flock(fd, LOCK_EX | LOCK_POLL)
would try to get a non-blocking exclusive lock on 'fd'. If that didn't
succeed it would insert a 'block' anyway [locks_insert_block()] and arrange
so that when the lock might succeeds, fd gets marked to say that 'lock' might
succeed.
Then POLLPRI becomes enabled and select will trigger if the fd is listed in
the 'exceptfds'.
I would then extend that so that lease breaking and dnotify notifications
could come through select/poll rather than as signals...
But this is probably going somewhat off-topic.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [U-Boot] [PATCH] at91: Add support for Bluewater Systems Snapper 9G45 module
From: Simon Glass @ 2011-10-23 3:09 UTC (permalink / raw)
To: u-boot
Snapper 9G45 is a ARM9-based CPU module with 1GB NAND and 128MB
DDR SDRAM. This patch includes NAND and Ethernet support.
Signed-off-by: Simon Glass <sglass@bluewatersys.com>
---
board/bluewater/snapper9g45/Makefile | 43 +++++++
board/bluewater/snapper9g45/snapper9g45.c | 155 +++++++++++++++++++++++
boards.cfg | 1 +
include/configs/snapper9g45.h | 189 +++++++++++++++++++++++++++++
4 files changed, 388 insertions(+), 0 deletions(-)
create mode 100644 board/bluewater/snapper9g45/Makefile
create mode 100644 board/bluewater/snapper9g45/snapper9g45.c
create mode 100644 include/configs/snapper9g45.h
diff --git a/board/bluewater/snapper9g45/Makefile b/board/bluewater/snapper9g45/Makefile
new file mode 100644
index 0000000..9016e5a
--- /dev/null
+++ b/board/bluewater/snapper9g45/Makefile
@@ -0,0 +1,43 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB = $(obj)lib$(BOARD).o
+
+COBJS-y += snapper9g45.o
+
+SRCS := $(COBJS-y:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS-y))
+
+$(LIB): $(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/bluewater/snapper9g45/snapper9g45.c b/board/bluewater/snapper9g45/snapper9g45.c
new file mode 100644
index 0000000..f057e59
--- /dev/null
+++ b/board/bluewater/snapper9g45/snapper9g45.c
@@ -0,0 +1,155 @@
+/*
+ * (C) Copyright 2011 Bluewater Systems Ltd
+ * Author: Andre Renaud <andre@bluewatersys.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/arch/at91sam9g45_matrix.h>
+#include <asm/arch/at91sam9_smc.h>
+#include <asm/arch/at91_common.h>
+#include <asm/arch/at91_pmc.h>
+#include <asm/arch/at91_rstc.h>
+#include <asm/arch/gpio.h>
+#include <asm/arch/hardware.h>
+#include <i2c.h>
+#include <net.h>
+#include <netdev.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static void macb_hw_init(void)
+{
+ struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+ struct at91_port *pioa = (struct at91_port *)ATMEL_BASE_PIOA;
+ struct at91_rstc *rstc = (struct at91_rstc *)ATMEL_BASE_RSTC;
+ unsigned long erstl;
+
+ /* Enable clock */
+ writel(1 << ATMEL_ID_EMAC, &pmc->pcer);
+
+ /*
+ * Disable pull-up on:
+ * RXDV (PA15) => PHY normal mode (not Test mode) / CRSDV
+ * ERX0 (PA12) => PHY ADDR0 / RXD0
+ * ERX1 (PA13) => PHY ADDR1 => PHYADDR = 0x0 / RXD1
+ *
+ * PHY has internal pull-down
+ */
+ writel(pin_to_mask(AT91_PIN_PA15) |
+ pin_to_mask(AT91_PIN_PA12) |
+ pin_to_mask(AT91_PIN_PA13),
+ &pioa->pudr);
+
+ /* Need to reset PHY -> 500ms reset */
+ erstl = readl(&rstc->mr) & AT91_RSTC_MR_ERSTL_MASK;
+ writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(13) |
+ AT91_RSTC_MR_URSTEN, &rstc->mr);
+ writel(AT91_RSTC_KEY | AT91_RSTC_CR_EXTRST, &rstc->cr);
+
+ /* Wait for end hardware reset */
+ while (!(readl(&rstc->sr) & AT91_RSTC_SR_NRSTL))
+ ;
+
+ /* Restore NRST value */
+ writel(AT91_RSTC_KEY | erstl | AT91_RSTC_MR_URSTEN, &rstc->mr);
+
+ /* The phy internal reset take 21ms */
+ udelay(21 * 1000);
+
+ /* Re-enable pull-up */
+ writel(pin_to_mask(AT91_PIN_PA15) |
+ pin_to_mask(AT91_PIN_PA12) |
+ pin_to_mask(AT91_PIN_PA13),
+ &pioa->puer);
+
+ at91_macb_hw_init();
+}
+
+static void nand_hw_init(void)
+{
+ struct at91_smc *smc = (struct at91_smc *)ATMEL_BASE_SMC;
+ struct at91_matrix *matrix = (struct at91_matrix *)ATMEL_BASE_MATRIX;
+ unsigned long csa;
+
+ /* Enable CS3 as NAND/SmartMedia */
+ csa = readl(&matrix->ebicsa);
+ csa |= AT91_MATRIX_EBI_CS3A_SMC_SMARTMEDIA;
+ writel(csa, &matrix->ebicsa);
+
+ /* Configure SMC CS3 for NAND/SmartMedia */
+ writel(AT91_SMC_SETUP_NWE(2) | AT91_SMC_SETUP_NCS_WR(0) |
+ AT91_SMC_SETUP_NRD(2) | AT91_SMC_SETUP_NCS_RD(0),
+ &smc->cs[3].setup);
+ writel(AT91_SMC_PULSE_NWE(4) | AT91_SMC_PULSE_NCS_WR(4) |
+ AT91_SMC_PULSE_NRD(4) | AT91_SMC_PULSE_NCS_RD(4),
+ &smc->cs[3].pulse);
+ writel(AT91_SMC_CYCLE_NWE(7) | AT91_SMC_CYCLE_NRD(7),
+ &smc->cs[3].cycle);
+ writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
+ AT91_SMC_MODE_EXNW_DISABLE |
+ AT91_SMC_MODE_DBW_8 |
+ AT91_SMC_MODE_TDF_CYCLE(3),
+ &smc->cs[3].mode);
+
+ /* Configure RDY/BSY */
+ at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1);
+
+ /* Enable NandFlash */
+ at91_set_gpio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1);
+}
+
+int board_init(void)
+{
+ struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+
+ /* Enable PIO clocks */
+ writel((1 << ATMEL_ID_PIOA) |
+ (1 << ATMEL_ID_PIOB) |
+ (1 << ATMEL_ID_PIOC |
+ (1 << ATMEL_ID_PIODE)), &pmc->pcer);
+
+ gd->bd->bi_arch_number = MACH_TYPE_SNAPPER9G45;
+
+ /* Address of boot parameters */
+ gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
+
+ /* Initialise peripherals */
+ at91_seriald_hw_init();
+ i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+ nand_hw_init();
+
+ macb_hw_init();
+
+ return 0;
+}
+
+int board_eth_init(bd_t *bis)
+{
+ return macb_eth_initialize(0, (void *)ATMEL_BASE_EMAC, 0x1b);
+}
+
+int dram_init(void)
+{
+ gd->ram_size = get_ram_size((void *)CONFIG_SYS_SDRAM_BASE,
+ CONFIG_SYS_SDRAM_SIZE);
+ return 0;
+}
diff --git a/boards.cfg b/boards.cfg
index 738c186..b56f1d0 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -95,6 +95,7 @@ at91sam9xeek_dataflash_cs0 arm arm926ejs at91sam9260ek atmel
at91sam9xeek_dataflash_cs1 arm arm926ejs at91sam9260ek atmel at91 at91sam9260ek:AT91SAM9XE,SYS_USE_DATAFLASH_CS1
snapper9260 arm arm926ejs - bluewater at91 snapper9260:AT91SAM9260
snapper9g20 arm arm926ejs snapper9260 bluewater at91 snapper9260:AT91SAM9G20
+snapper9g45 arm arm926ejs snapper9g45 bluewater at91 snapper9g45:AT91SAM9G45
sbc35_a9g20_nandflash arm arm926ejs sbc35_a9g20 calao at91 sbc35_a9g20:AT91SAM9G20,SYS_USE_NANDFLASH
sbc35_a9g20_eeprom arm arm926ejs sbc35_a9g20 calao at91 sbc35_a9g20:AT91SAM9G20,SYS_USE_EEPROM
tny_a9g20_nandflash arm arm926ejs tny_a9260 calao at91 tny_a9260:AT91SAM9G20,SYS_USE_NANDFLASH
diff --git a/include/configs/snapper9g45.h b/include/configs/snapper9g45.h
new file mode 100644
index 0000000..23798c3
--- /dev/null
+++ b/include/configs/snapper9g45.h
@@ -0,0 +1,189 @@
+/*
+ * Bluewater Systems Snapper 9G45 modules
+ *
+ * (C) Copyright 2011 Bluewater Systems
+ * Author: Andre Renaud <andre@bluewatersys.com>
+ * Author: Ryan Mallon <ryan@bluewatersys.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/* SoC type is defined in boards.cfg */
+#include <asm/hardware.h>
+#include <asm/sizes.h>
+
+#define CONFIG_SYS_TEXT_BASE 0x70000000
+
+/* ARM asynchronous clock */
+#define CONFIG_SYS_AT91_MAIN_CLOCK 12000000 /* 12 MHz crystal */
+#define CONFIG_SYS_AT91_SLOW_CLOCK 32768
+#define CONFIG_SYS_HZ 1000
+
+/* CPU */
+#define CONFIG_ARCH_CPU_INIT
+
+#define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */
+#define CONFIG_SETUP_MEMORY_TAGS
+#define CONFIG_INITRD_TAG
+#define CONFIG_SKIP_LOWLEVEL_INIT
+
+#define CONFIG_DISPLAY_CPUINFO
+#define CONFIG_FIT
+
+/* SDRAM */
+#define CONFIG_NR_DRAM_BANKS 1
+#define CONFIG_SYS_SDRAM_BASE ATMEL_BASE_CS6
+#define CONFIG_SYS_SDRAM_SIZE (128 * 1024 * 1024) /* 128MB */
+#define CONFIG_SYS_INIT_SP_ADDR (ATMEL_BASE_SRAM + 0x1000 - \
+ GENERATED_GBL_DATA_SIZE)
+
+/* Mem test settings */
+#define CONFIG_SYS_MEMTEST_START CONFIG_SYS_SDRAM_BASE
+#define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_SDRAM_BASE + (1024 * 1024))
+
+/* NAND flash */
+#define CONFIG_NAND_ATMEL
+#define CONFIG_SYS_NO_FLASH
+#define CONFIG_SYS_MAX_NAND_DEVICE 1
+#define CONFIG_SYS_NAND_BASE ATMEL_BASE_CS3 /*0x40000000*/
+#define CONFIG_SYS_NAND_DBW_8
+#define CONFIG_SYS_NAND_MASK_ALE (1 << 21) /* AD21 */
+#define CONFIG_SYS_NAND_MASK_CLE (1 << 22) /* AD22 */
+#define CONFIG_SYS_NAND_ENABLE_PIN AT91_PIN_PC14
+#define CONFIG_SYS_NAND_READY_PIN AT91_PIN_PC8
+
+/* Ethernet */
+#define CONFIG_MACB
+#define CONFIG_RMII
+#define CONFIG_NET_RETRY_COUNT 20
+#define CONFIG_TFTP_PORT
+#define CONFIG_TFTP_TSIZE
+
+/* USB */
+#define CONFIG_USB_ATMEL
+#define CONFIG_USB_OHCI_NEW
+#define CONFIG_DOS_PARTITION
+#define CONFIG_SYS_USB_OHCI_CPU_INIT
+#define CONFIG_SYS_USB_OHCI_REGS_BASE 0x00700000 /* _UHP_OHCI_BASE */
+#define CONFIG_SYS_USB_OHCI_SLOT_NAME "at91sam9g45"
+#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 2
+#define CONFIG_USB_STORAGE
+
+/* GPIOs and IO expander */
+#define CONFIG_AT91_LEGACY
+#define CONFIG_ATMEL_LEGACY
+#define CONFIG_AT91_GPIO
+#define CONFIG_AT91_GPIO_PULLUP 1
+
+#ifndef NEW
+#define CONFIG_PCA953X
+#define CONFIG_SYS_I2C_PCA953X_ADDR 0x28
+#define CONFIG_SYS_I2C_PCA953X_WIDTH { {0x28, 16} }
+#endif
+
+/* UARTs/Serial console */
+#define CONFIG_ATMEL_USART
+#define CONFIG_USART_BASE ATMEL_BASE_DBGU
+#define CONFIG_USART_ID ATMEL_ID_SYS
+#define CONFIG_BAUDRATE 115200
+#define CONFIG_SYS_BAUDRATE_TABLE {115200 , 19200, 38400, 57600, 9600 }
+#define CONFIG_SYS_PROMPT "Snapper> "
+
+/* I2C - Bit-bashed */
+#define CONFIG_SOFT_I2C
+#define CONFIG_SYS_I2C_SPEED 100000
+#define CONFIG_SYS_I2C_SLAVE 0x7F
+#define CONFIG_SOFT_I2C_READ_REPEATED_START
+#define CONFIG_I2C_MULTI_BUS
+#define I2C_INIT do { \
+ at91_set_gpio_output(AT91_PIN_PA21, 1); \
+ at91_set_gpio_output(AT91_PIN_PA20, 1); \
+ at91_set_pio_multi_drive(AT91_PIO_PORTA, 21, 1); \
+ at91_set_pio_multi_drive(AT91_PIO_PORTA, 20, 1); \
+ } while (0)
+#define I2C_SOFT_DECLARATIONS
+#define I2C_ACTIVE
+#define I2C_TRISTATE at91_set_gpio_input(AT91_PIN_PA20, 1);
+#define I2C_READ at91_get_gpio_value(AT91_PIN_PA20);
+#define I2C_SDA(bit) do { \
+ if (bit) { \
+ at91_set_gpio_input(AT91_PIN_PA20, 1); \
+ } else { \
+ at91_set_gpio_output(AT91_PIN_PA20, 1); \
+ at91_set_gpio_value(AT91_PIN_PA20, bit); \
+ } \
+ } while (0)
+#define I2C_SCL(bit) at91_set_pio_value(AT91_PIO_PORTA, 21, bit)
+#define I2C_DELAY udelay(2)
+
+/* Boot options */
+#define CONFIG_SYS_LOAD_ADDR 0x71000000
+#define CONFIG_BOOTDELAY 3
+#define CONFIG_ZERO_BOOTDELAY_CHECK
+
+#define CONFIG_BOOTP_BOOTFILESIZE
+#define CONFIG_BOOTP_BOOTPATH
+#define CONFIG_BOOTP_GATEWAY
+#define CONFIG_BOOTP_HOSTNAME
+
+/* Environment settings */
+#define CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_OFFSET (512 << 10)
+#define CONFIG_ENV_SIZE (256 << 10)
+#define CONFIG_ENV_OVERWRITE
+#define CONFIG_BOOTARGS "console=ttyS0,115200 ip=any"
+
+/* Console settings */
+#define CONFIG_SYS_CBSIZE 256
+#define CONFIG_SYS_MAXARGS 16
+#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \
+ sizeof(CONFIG_SYS_PROMPT) + 16)
+#define CONFIG_SYS_LONGHELP
+#define CONFIG_SYS_EXTBDINFO
+#define CONFIG_CMDLINE_EDITING
+#define CONFIG_AUTO_COMPLETE
+#define CONFIG_SYS_HUSH_PARSER
+#define CONFIG_SYS_PROMPT_HUSH_PS2 "> "
+
+/* U-Boot memory settings */
+#define CONFIG_SYS_MALLOC_LEN (1 << 20)
+#define CONFIG_STACKSIZE (256 << 10)
+
+/* Command line configuration */
+#include <config_cmd_default.h>
+#undef CONFIG_CMD_BDI
+#undef CONFIG_CMD_FPGA
+#undef CONFIG_CMD_IMI
+#undef CONFIG_CMD_IMLS
+#undef CONFIG_CMD_LOADS
+#undef CONFIG_CMD_SOURCE
+
+#define CONFIG_CMD_PING
+#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_FAT
+#define CONFIG_CMD_I2C
+#undef CONFIG_CMD_GPIO
+#define CONFIG_CMD_USB
+#define CONFIG_CMD_MII
+#define CONFIG_CMD_NAND
+
+#endif
--
1.7.5.4
^ permalink raw reply related
* Re: [RFC][PATCH 0/2] PM / Sleep: Extended control of suspend/hibernate interfaces
From: NeilBrown @ 2011-10-23 2:57 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux PM list, mark gross, LKML, John Stultz, Alan Stern
In-Reply-To: <201110230007.33683.rjw@sisk.pl>
[-- Attachment #1: Type: text/plain, Size: 10096 bytes --]
On Sun, 23 Oct 2011 00:07:33 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> On Tuesday, October 18, 2011, NeilBrown wrote:
> > On Tue, 18 Oct 2011 00:02:30 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> >
> > > On Monday, October 17, 2011, NeilBrown wrote:
> > > > On Sun, 16 Oct 2011 00:10:40 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > ...
> > > > >
> > > > > > But I think it is very wrong to put some hack in the kernel like your
> > > > > > suspend_mode = disabled
> > > > >
> > > > > Why is it wrong and why do you think it is a "hack"?
> > > >
> > > > I think it is a "hack" because it is addressing a specific complaint rather
> > > > than fixing a real problem.
> > >
> > > I wonder why you think that there's no real problem here.
> > >
> > > The problem I see is that multiple processes can use the suspend/hibernate
> > > interfaces pretty much at the same time (not exactly in parallel, becuase
> > > there's some locking in there, but very well there may be two different
> > > processes operating /sys/power/state independently of each other), while
> > > the /sys/power/wakeup_count interface was designed with the assumption that
> > > there will be only one such process in mind.
> >
> > Multiple process can write to your mail box at the same time. But some how
> > they don't. This isn't because the kernel enforces anything, but because all
> > the relevant programs have an agreed protocol by which they arbitrate access.
> > One upon a time this involved creating a lock file with O_CREAT|O_EXCL.
> > These days it is fcntl locking. But it is still advisory.
> >
> > In the same way - we stop multiple processes from suspending/hibernating at
> > the same time by having an agreed protocol by which they share access to the
> > resource. The kernel does not need to be explicitly involved in this.
>
> Not really. The main difference is that such a protocol doesn't exist for
> processes that may want to suspend/hibernate the system.
>
> Moreover, the race is real, because if you have two processes trying to use
> /sys/power/wakeup_count at the same time, you can get:
>
> Process A Process B
> read from wakeup_count
> talk to apps
> write to wakeup_count
> --------- wakeup event ----------
> read from wakeup_count
> talk to apps
> write to wakeup_count
> try to suspend -> success (should be failure, because the wakeup event
> may still be processed by applications at this point and Process A hasn't
> checked that).
>
> Now, there are systems running two (or more) desktop environments each of
> which has a power manager that may want to suspend on it's own. They both
> will probably use pm-utils, but then I somehow doubt that pm-utils is well
> prepared to handle such concurrency.
I think that "upowerd" is the current "solution" to this problem. Different
desktops can communicate with it to negotiate when suspend will happen.
When upowerd decides to suspend, it calls the relevant pm_utils command.
So with modern desktops we would never expect two different processes to be
requesting pm_utils to suspend at the same time. If we did that would be a
problem but we don't. There is no race here to fix.
I'm not certain that upowerd provides good interfaces. But its existence
shows that this sort of problem that you see is not that hard to solve.
Sure: people could still design systems which exhibited racy access to
suspend, but people have always being able to write buggy code - making up
new interfaces isn't going to stop them.
>
> >
> > ...
> >
> > > > > Well, I used to think that it's better to do things in user space. Hence,
> > > > > the hibernate user space interface that's used by many people. And my
> > > > > experience with that particular thing made me think that doing things in
> > > > > the kernel may actually work better, even if they _can_ be done in user space.
> > > > >
> > > > > Obviously, that doesn't apply to everything, but sometimes it simply is worth
> > > > > discussing (if not trying). If it doesn't work out, then fine, let's do it
> > > > > differently, but I'm really not taking the "this should be done in user space"
> > > > > argument at face value any more. Sorry about that.
> > > >
> > > > :-) I have had similar mixed experiences. Sometimes it can be a lot easier
> > > > to get things working if it is all in the kernel.
> > > > But I think that doing things in user-space leads to a lot more flexibility.
> > > > Once you have the interfaces and designs worked out you can then start doing
> > > > more interesting things and experimenting with ideas more easily.
> > > >
> > > > In this case, I think the *only* barrier to a simple solution in user-space
> > > > is the pre-existing software that uses the 'old' kernel interface. It seems
> > > > that interfacing with that is as easy as adding a script or two to pm-utils.
> > >
> > > Well, assuming that we're only going to address the systems that use PM utils.
> >
> > I suspect (and claim without proof :-) that any system will have some single
> > user-space thing that is responsible for initiating suspend.
>
> Well, see above.
See also upowerd.
>
> > Every time I look at one I see a whole host of things that need to be done
> > just before suspend, and other things just after resume.
> > They used to be in /etc/apm/event.d. Now there are
> > in /usr/lib/pm-utils/sleep.d.
>
> I know of systems that don't need those hooks, however.
>
> > I think they were in /etc/acpid once.
> > I've seen one thing that uses shared-library modules instead of shell scripts
> > on the basis that it avoids forking and goes fast (and it probably does).
> > But I doubt there is any interesting system where writing to /sys/power/state
> > is the *only* thing you need to do for a clean suspend.
>
> I have such a system on my desk. :-)
:-)
I guess I would have to conclude that it is therefore not interesting :-)
Would you accept that is more of an exception than the rule?
The real point though is that lots of system do want pre/post scripts, so we
can expect that avoiding races between such scripts is a solved problem - and
this is what we find in e.g. upowerd.
>
> > So all systems will have some user-space infrastructure to support suspend,
> > and we just need to hook in to that.
> >
> >
> > >
> > > > With that problem solved, experimenting is much easier in user-space than in
> > > > the kernel.
> > >
> > > Somehow, I'm not exactly sure if we should throw all kernel-based solutions away
> > > just yet.
> >
> > My rule-of-thumb is that we should reserve kernel space for when
> > a/ it cannot be done in user space
> > b/ it cannot be done efficient in user space
> > c/ it cannot be done securely in user space
> >
> > I don't think any of those have been demonstrated yet. If/when they are it
> > would be good to get those kernel-based solutions out of the draw (so yes:
> > keep them out of the rubbish bin).
>
> I have one more rule. If my would-be user space solution has the following
> properties:
>
> * It is supposed to be used by all of the existing variants of user space
> (i.e. all existing variants of user space are expected to use the very same
> thing).
>
> * It requires all of those user space variants to be modified to work with it
> correctly.
>
> * It includes a daemon process having to be started on boot and run permanently.
>
> then it likely is better to handle the problem in the kernel.
By that set or rules, upowerd, dbus, pulse audio, bluez, and probably systemd
all need to go in the kernel. My guess is that you might not find wide
acceptance for these rules.
>
> > So I'd respond with "I'm not at all sure that we should throw away an
> > all-userspace solution just yet". Particularly because many of us seem to
> > still be working to understand what all the issues really are.
>
> OK, so perhaps we should try to implement two concurrent solutions, one
> kernel-based and one purely in user space and decide which one is better
> afterwards?
Absolutely.
My primary reason for entering this discussion is eloquently presented in
http://xkcd.com/386/
Someone said "We need to change the kernel to get race-free suspend" and this
simply is not true. I wanted to present a way to use the existing
functionality to provide race-free suspend - and now even have code to do it.
If someone else wants to write a different implementation, either in
userspace or kernel that is fine.
They can then present it as "I know this can be implemented in userspace, but
I don't like that solution for reasons X, Y, Z and so here is my better
kernel-space implementation" then that is cool. We can examine X, Y, Z and
the code and see if the argument holds up. Maybe it will, maybe not.
So far the only arguments I've seen for putting the code in the kernel are:
1/ it cannot be done in userspace - demonstrably wrong
2/ it is more efficient in the kernel - not demonstrated or even
convincingly argued
3/ doing it in user-space is too confusing - we would need a clear
demonstration that a kernel interface is less confusing - and still
correct. Also the best way to remove confusion is with clear
documentation and sample code, not by making up new interfaces.
4/ doing it in the kernel makes it more accessible to multiple desktops.
The success of freedesktop.org seems to contradict that.
So if you can do it a "better" way, please do. But also please make sure
you can quantify "better". I claim that user-space solutions are "better"
because they are more flexible and easier to experiment with. The "no
regressions" rule actively discourages experimentation in the kernel so
people should only do it if there is a clear benefit. User-space solutions
are much easier to introduce and then deprecate.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] Makefile: Remove duplicate description of "make RECORDMCOUNT_WARN=1"
From: Américo Wang @ 2011-10-23 2:52 UTC (permalink / raw)
To: Jongman Heo; +Cc: linux-kernel
In-Reply-To: <CAHFnbA=sz+_8rESX212aRphen5YCC6ikoX2riprCZBh4wp1O9Q@mail.gmail.com>
On Sat, Oct 22, 2011 at 3:32 PM, Jongman Heo <jongman.heo@gmail.com> wrote:
> Remove duplicate "make RECORDMCOUNT_WARN=1" description from "make help" output
>
> Signed-off-by: Jongman Heo <jongman.heo@gmail.com>
Hi,
I sent a same patch some days ago, I think it is already in Kbuild tree.
Thanks.
^ permalink raw reply
* Re: copy_*_user
From: Américo Wang @ 2011-10-23 2:50 UTC (permalink / raw)
To: Xin Tong; +Cc: linux-kernel
In-Reply-To: <CALKntY3Xo6R2zLs8oM=+=-VPdFXeLsdGi_YbMiA_1085xhMOQw@mail.gmail.com>
On Sun, Oct 23, 2011 at 1:06 AM, Xin Tong <xerox.time.tech@gmail.com> wrote:
> I am investigating copy_from_user and copy_to_user in linux under
> i386. These two function both take a pointer with virtual address and
> a pointer with physical address.
>
> copy_from_user calls __copy_from_user_ll and copy_to_user calls
> __copy_to_user_ll. It make sense to me that __copy_to_user_ll converts
> the virtual address to physical address using the current process's
> page table.
>
[...]
> But it seems to be that __copy_from_user_ll is not converted the
> address at all before attempting to copy. Can someone help explain to
> me why ?
>
You missed that __copy_to_user_ll() only does that when CONFIG_X86_WP_WORKS_OK
is not defined. And there is a comment right inside __copy_to_user_ll() said:
/*
* CPU does not honor the WP bit when writing
* from supervisory mode, and due to preemption or SMP,
* the page tables can change at any time.
* Do it manually. Manfred <manfred@colorfullife.com>
*/
this is why it uses kmap_atomic()+memcpy() to copy the data.
Also, all the addresses are virtual address.
^ permalink raw reply
* [PATCH 3/3] drm/i915: extract constant offset setting
From: Ben Widawsky @ 2011-10-23 2:41 UTC (permalink / raw)
To: intel-gfx; +Cc: Ben Widawsky
In-Reply-To: <1319337685-26195-1-git-send-email-ben@bwidawsk.net>
Simple refactor.
Cc: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 82 ++++++++++++++++------------
1 files changed, 46 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1589a19..a5c856b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -954,6 +954,50 @@ i915_gem_execbuffer_retire_commands(struct drm_device *dev,
}
static int
+i915_gem_set_constant_offset(struct intel_ring_buffer *ring, int mode)
+{
+ struct drm_device *dev = ring->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ uint32_t mask = I915_EXEC_CONSTANTS_MASK;
+ int ret;
+
+ switch (mode) {
+ case I915_EXEC_CONSTANTS_REL_GENERAL:
+ case I915_EXEC_CONSTANTS_ABSOLUTE:
+ case I915_EXEC_CONSTANTS_REL_SURFACE:
+ if (ring == &dev_priv->ring[RCS] &&
+ mode != dev_priv->relative_constants_mode) {
+ if (INTEL_INFO(dev)->gen < 4)
+ return -EINVAL;
+
+ if (INTEL_INFO(dev)->gen > 5 &&
+ mode == I915_EXEC_CONSTANTS_REL_SURFACE)
+ return -EINVAL;
+
+ /* The HW changed the meaning on this bit on gen6 */
+ if (INTEL_INFO(dev)->gen >= 6)
+ mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE;
+
+ ret = intel_ring_begin(ring, 4);
+ if (ret)
+ return ret;
+
+ intel_ring_emit(ring, MI_NOOP);
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, INSTPM);
+ intel_ring_emit(ring, mask << 16 | mode);
+ intel_ring_advance(ring);
+
+ dev_priv->relative_constants_mode = mode;
+ }
+ return 0;
+ default:
+ DRM_ERROR("execbuf with unknown constants: %d\n", mode);
+ return -EINVAL;
+ }
+}
+
+static int
i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file,
struct drm_i915_gem_execbuffer2 *args,
@@ -967,7 +1011,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct intel_ring_buffer *ring;
u32 exec_start, exec_len;
u32 seqno;
- u32 mask;
int ret, mode, i;
if (!i915_gem_check_execbuffer(args)) {
@@ -1128,42 +1171,9 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
}
mode = args->flags & I915_EXEC_CONSTANTS_MASK;
- mask = I915_EXEC_CONSTANTS_MASK;
- switch (mode) {
- case I915_EXEC_CONSTANTS_REL_GENERAL:
- case I915_EXEC_CONSTANTS_ABSOLUTE:
- case I915_EXEC_CONSTANTS_REL_SURFACE:
- if (ring == &dev_priv->ring[RCS] &&
- mode != dev_priv->relative_constants_mode) {
- if (INTEL_INFO(dev)->gen < 4)
- return -EINVAL;
-
- if (INTEL_INFO(dev)->gen > 5 &&
- mode == I915_EXEC_CONSTANTS_REL_SURFACE)
- return -EINVAL;
-
- /* The HW changed the meaning on this bit on gen6 */
- if (INTEL_INFO(dev)->gen >= 6)
- mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE;
-
- ret = intel_ring_begin(ring, 4);
- if (ret)
- goto err;
-
- intel_ring_emit(ring, MI_NOOP);
- intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
- intel_ring_emit(ring, INSTPM);
- intel_ring_emit(ring, mask << 16 | mode);
- intel_ring_advance(ring);
-
- dev_priv->relative_constants_mode = mode;
- }
- break;
- default:
- DRM_ERROR("execbuf with unknown constants: %d\n", mode);
- ret = -EINVAL;
+ ret = i915_gem_set_constant_offset(ring, mode);
+ if (ret)
goto err;
- }
trace_i915_gem_ring_dispatch(ring, seqno);
--
1.7.7
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.