Re: [block] allow blk_flush_policy to return REQ_FSEQ_DATA independent of *FLUSH
Hello, Re-reading the code, I see that I was wrong with the previous comment of mine. So, in summary i) If block driver does not support FLUSH and FUA, then __generic_make_request() checks will clear BIO FLUSH and FUA flags and hence blk_insert_flush() will not be invoked. ii) If block driver clears FLUSH & FUA flags while IO is in flight, then there is possibility of IO missing __generic_make_request() checks and hitting issue with blk_insert_flush() being discussed here. iii) If block driver sets only REQ_FUA without REQ_FLUSH then __generic_make_request() checks will not clear BIO flags and hence blk_insert_flush() will be invoked which will hit the blk_insert_flush() issue being discussed here. However, setting REQ_FUA without REQ_FLUSH is not as per documentation and it is invalid for block driver to do so. Thanks, Ajith On Wednesday, 9 January 2013 09:44:55 UTC+5:30, Ajith Kumar wrote: > Hello, > > Thanks for the response. > > A block device driver during initialization would decide if it is capable of > supporting FLUSH/FUA or not. Suppose driver claims FLUSH/FUA support then > any bio targeted at this driver with FLUSH bit set(which is commonly set by > file system like XFS for doing internal logging) has a data corruption > vulnerability in case of an abrupt shutdown. So, IMO the vulnerability is > not open to rare window where driver changes q->flush_flags while IO is in > flight, but for a much larger window from time driver comes up and throughout > it's life. > > > > Thanks, > > Ajith > > > > On Wednesday, 9 January 2013 00:15:31 UTC+5:30, Tejun Heo wrote: > > > Hello, > > > > > > > > > > > > On Tue, Jan 08, 2013 at 10:04:23AM -0800, ajithb.ku...@gmail.com wrote: > > > > > > > Hi, > > > > > > > Could you please provide clarity on the following. > > > > > > > "> Hmmm... yes, this can become a correctness issue if (and only if) > > > > > > > > blk_queue_flush() is called to change q->flush_flags while requests > > > > > > > > are in-flight;" > > > > > > > > > > > > > > Could you please clarify as to why is it a correctness issue only if > > > > > > > blk_queue_flush() is used to change flush_flags when requests are in > > > > > > > flight ? As I understand, XFS does set WRITE_FLUSH_FUA flag in > > > > > > > _xfs_buf_ioapply() function irrespective of whether the underlying > > > > > > > device supports flush capabilities or not which will flow into > > > > > > > blk_insert_flush(). Is my reading of the code correct and is there > > > > > > > a general correctness issue here which potentially results in XFS > > > > > > > file system corruption in case of an abrupt shutdown independent of > > > > > > > q->flush_flags getting changed while request is in flight. > > > > > > > > > > > > My memory is kinda fuzzy at this point but if a queue doesn't support > > > > > > flush, its flush_flags should be zero and > > > > > > generic_make_request_checks() will clear REQ_FLUSH|REQ_FUA from > > > > > > bio->bi_rw so we never hit blk_insert_flush() and the request will be > > > > > > processed as a normal IO one; however, if REQ_FLUSH goes off after a > > > > > > request passed generic_make_request_checks() but before > > > > > > blk_flush_policy(), it'll become null op and its data payload won't > > > > > > get written out to the underlying device, which is data corruption. > > > > > > > > > > > > Thanks. > > > > > > > > > > > > -- > > > > > > tejun > > > > > > -- > > > > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > > > > the body of a message to majord...@vger.kernel.org > > > > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nilfs2: fix very long mount time issue
On Sat, 12 Jan 2013 19:34:48 +0400, Vyacheslav Dubeyko wrote:
> From: Vyacheslav Dubeyko
> Subject: [PATCH] nilfs2: fix very long mount time issue
>
> DESCRIPTION:
> It exists situation when GC can work in background alone without any other
> filesystem activity during significant time. The nilfs_clean_segments()
> method calls nilfs_segctor_construct() that updates superblocks in the case
> of NILFS_SC_SUPER_ROOT and THE_NILFS_DISCONTINUED flags are set. But when GC
> is working alone the nilfs_clean_segments() is called with unset
> THE_NILFS_DISCONTINUED flag. As a result, the update of superblocks doesn't
> occurred all this time and in the case of SPOR superblocks keep very old
> values of last super root placement.
>
> SYMPTOMS:
> Trying to mount a NILFS2 volume after SPOR in such environment ends with very
> long mounting time (it can achieve about several hours in some cases).
>
> REPRODUCING PATH:
> 1. It needs to use external USB HDD, disable automount and doesn't make any
> additional filesystem activity on the NILFS2 volume.
> 2. Generate temporary file with size about 100 - 500 GB (for example, dd
> if=/dev/zero of= bs=1073741824 count=200). The size of file
> defines duration of GC working.
> 3. Then it needs to delete file.
> 4. Start GC manually by means of command "nilfs-clean -p 0". When you start
> GC by means of such way then, at the end, superblocks is updated by once. So,
> for simulation of SPOR, it needs to wait sometime (15 - 40 minutes) and
> simply switch off USB HDD manually.
> 5. Switch on USB HDD again and try to mount NILFS2 volume. As a result,
> NILFS2 volume will mount during very long time.
>
> REPRODUCIBILITY: 100%
>
> FIX:
> This patch adds checking that superblocks need to update and set
> THE_NILFS_DISCONTINUED flag before nilfs_clean_segments() call.
>
> Reported-by: Sergey Alexandrov
> Signed-off-by: Vyacheslav Dubeyko
> Tested-by: Vyacheslav Dubeyko
Acked-by: Ryusuke Konishi
Thanks, Vyacheslav. I confirmed the issue and could reproduce it.
Your patch fixed it.
Andrew, please apply.
Thanks,
Ryusuke Konishi
> ---
> fs/nilfs2/ioctl.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/fs/nilfs2/ioctl.c b/fs/nilfs2/ioctl.c
> index fdb1807..f385935 100644
> --- a/fs/nilfs2/ioctl.c
> +++ b/fs/nilfs2/ioctl.c
> @@ -664,8 +664,11 @@ static int nilfs_ioctl_clean_segments(struct inode
> *inode, struct file *filp,
> if (ret < 0)
> printk(KERN_ERR "NILFS: GC failed during preparation: "
> "cannot read source blocks: err=%d\n", ret);
> - else
> + else {
> + if (nilfs_sb_need_update(nilfs))
> + set_nilfs_discontinued(nilfs);
> ret = nilfs_clean_segments(inode->i_sb, argv, kbufs);
> + }
>
> nilfs_remove_all_gcinodes(nilfs);
> clear_nilfs_gc_running(nilfs);
> --
> 1.7.9.5
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mmc: vt8500: Remove erroneous __exitp in wmt_mci_driver
With the __devinit/__devexit attributes having been removed, this
__exitp attribute causes an unused function warning and should be
removed as well.
Signed-off-by: Tony Prisk
---
drivers/mmc/host/wmt-sdmmc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/wmt-sdmmc.c b/drivers/mmc/host/wmt-sdmmc.c
index 154f0e8..c6d0015 100644
--- a/drivers/mmc/host/wmt-sdmmc.c
+++ b/drivers/mmc/host/wmt-sdmmc.c
@@ -1012,7 +1012,7 @@ static const struct dev_pm_ops wmt_mci_pm = {
static struct platform_driver wmt_mci_driver = {
.probe = wmt_mci_probe,
- .remove = __exit_p(wmt_mci_remove),
+ .remove = wmt_mci_remove,
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [add to stable] ftrace: Do not function trace inlined functions
On Tue, 2013-01-08 at 16:38 -0500, Steven Rostedt wrote: > Hi Greg and Ben, > > Can you add commit 45959ee7aa645815a5ce303a0ea1e48a21e67c6a to the > stable trees. Added to the queue for 3.2, thanks. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails
On Mon, 2013-01-07 at 20:20 +0100, Stanislaw Gruszka wrote: > On Mon, Jan 07, 2013 at 07:38:35PM +0100, Andreas Hartmann wrote: > > Stanislaw Gruszka wrote: > > > On Mon, Jan 07, 2013 at 04:04:01PM +0100, Andreas Hartmann wrote: > > >> Ben Hutchings wrote: > > >>> On Mon, 2013-01-07 at 09:10 +0100, Stanislaw Gruszka wrote: > > On Mon, Jan 07, 2013 at 09:05:32AM +0100, Stanislaw Gruszka wrote: > > >> To be clear, I have all of these in the queue: > > >> > > >> be03d4a45c09 rt2x00: Don't let mac80211 send a BAR when an AMPDU > > >> subframe fails > > >> 5b632fe85ec8 mac80211: introduce > > >> IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL > > >> ab9d6e4ffe19 Revert: "rt2x00: Don't let mac80211 send a BAR when an > > >> AMPDU subframe fails" > > >> > > >> and I'm intending to drop/defer them all. > > > > > > Patch 3 is a revert of patch 1 (questioned patch). Please apply all 3 > > > patches, > > > or only patch 2. > > > > No, actually all 3 patches have to be applied. Because last one, except > > revert, include flag IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL setting in > > rt2x00 > > driver, which make patch 2 work. > > >>> > > >>> Andreas said that that after ab9d6e4ffe19 there was still a regression. > > > > > > That's not true. There will be no regression after ab9d6e4ffe20. The > > > only thing is that solution is not perfect. But perfect solution require > > > lot of changes i.e. is not -stable appropriate (and does not exist > > > currently). > > > > > >>> But maybe he was confused. I know I'm confused. > > >> :-)) > > >> > > >> No, the thing is: > > >> rt2800pci misses an appropriate handling of aggregation (which meets the > > >> requirements of mac80211). > > >> > > >> Both workarounds, mine and the new workaround from Stanislaw (which is > > >> nothing more than a restricted version of my initial workaround), work > > > > > > Your workaround broke STA mode on some environment. > > > > Why are you sure, that this workaround doesn't break some other devices > > running in AP mode? We believed at that time too, it wouldn't harm even > > STA. But this was wrong for some (which?) devices. > > Because it make behaviour the same as it was before 3.2, which introduce > those issues. After reviewing the various changes, I agree that applying the three patches looks like it will restore the old (3.1) behaviour of rt2x00. I have reinstated them in the queue for the next 3.2 update. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Re: Oops on aoe module removal
On Thu, 2013-01-03 at 15:20 -0600, Ed Cashin wrote: > On Jan 3, 2013, at 3:50 PM, Ed Cashin wrote: [...] > > Kernels with aoe v47 can use the patch I just posted. > > > > I'm going to go through the stable kernels and check, but I believe kernels > > after > > v47 but before commit 0a41409c5180 should apply the fix in 0a41409c5180: > > > > commit 0a41409c518083133e79015092585d68915865be > > Author: Ed Cashin > > Date: Mon Dec 17 16:03:58 2012 -0800 > > > > aoe: remove vestigial request queue allocation > > ... > > OK. Looks like 3.7.1 has aoe v50, exhibits the behavior in question, and > needs > the above-mentioned commit 0a41409c5180 from Linus' tree as a fix. > > The 3.6.11 kernel has aoe v47, so it and earlier stable kernels can use the > patch > I posted in this thread. > > I'm sending this to sta...@vger.kernel.org to ask Greg, Ben, and other stable > maintainers (where's the list of stable kernel maintainers?) ... There is Willy Tarreau looking after 2.6.32.y, Paul Gortmaker with 2.6.34.y and unofficially Herton Ronaldo Krzesinski with 3.5.7.y. All stable maintainers should be reading sta...@vger.kernel.org anyway. > Should I send git-generated patches to sta...@vger.kernel.org based on each > linux-stable/linux-3.x,y branch? There are only two cases, really: 3.7.y and > others. > I suppose 3.7.y can cherry pick from the mainline. > > What's the best way to do this? Given that aoe is basically unchanged between Linux 2.6.32 and 3.6 I agree that the one patch should be sufficient. However your previous patch was lacking a signoff or much of a commit message, so please do re-post it with those. The commit message should include a reference to the corresponding mainline commit as you identified above. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Re: INFO: rcu_bh detected stall on CPU 3 (t=0 jiffies)
On Wed, 2013-01-02 at 19:49 -0500, Steven Rostedt wrote: > On Wed, 2013-01-02 at 13:29 -0800, Paul E. McKenney wrote: > > On Wed, Jan 02, 2013 at 03:56:30PM -0500, Steven Rostedt wrote: > > > On Wed, Jan 02, 2013 at 08:09:20PM +0100, Ralf Hildebrandt wrote: > > > > This happened of a virtual guest (Linux mail 3.2.0-35-virtual > > > > #55-Ubuntu SMP Wed Dec 5 18:02:05 UTC 2012 x86_64 x86_64 x86_64 > > > > GNU/Linux) > > > > > > 3.2 is rather old and this looks to be a stock Ubuntu kernel. May want > > > to file a Bugzilla (or whatever they call it) with them. > > > > > > > > > > > Jan 2 13:24:08 mail kernel: [3531872.484283] INFO: rcu_bh detected > > > > stall on CPU 3 (t=0 jiffies) > > > > > > 0 jiffies? > > > > One possibility is that they are missing commit a10d206e (rcu: Fix > > day-one dyntick-idle stall-warning bug), at least assuming that > > CONFIG_PREEMPT=n. This went into 3.6, IIRC. > > If that does fix the issue, we probably should send that off to Ben for > inclusion into 3.2 stable. If I read the Ubuntu changelog correctly, Ralf's machine is running a version based on 3.2.34, which already has this change (I applied it in 3.2.32). Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Re: [RFC] ktap: Another dynamic tracing tool for Linux
On Fri, Jan 11, 2013 at 10:19 PM, Michel Dagenais wrote: > You may be interested in KGTP which implements a simple bytecode interpreter > in the kernel to accept GDB tracepoints http://code.google.com/p/kgtp/ > > The bytecode is quite limited but would be easy to extend. KGTP is still not meet my requirement on Linux tracing. ktap don't have gcc or gdb dependence, it's build from scratch, with a clean design, this is very important. You will find more differences if you watch ktap and kgtp deeply. :) > > Eventually we should be able to connect LTTng http://lttng.org/ and KGTP in > order to benefit from the efficiency of LTTng for activating probes and > retrieving data. You are right, LTTng should be possible, and I already planed it, also on some functionality of ftrace and systemtap. Let's wait public ktap for a little time, you then can get a basic overview on ktap. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: compaction: Partially revert capture of suitable high-order page
On Fri, 2013-01-11 at 09:27 +, Mel Gorman wrote:
> Eric Wong reported on 3.7 and 3.8-rc2 that ppoll() got stuck when waiting
> for POLLIN on a local TCP socket. It was easier to trigger if there was disk
> IO and dirty pages at the same time and he bisected it to commit 1fb3f8ca
> "mm: compaction: capture a suitable high-order page immediately when it
> is made available".
>
> The intention of that patch was to improve high-order allocations under
> memory pressure after changes made to reclaim in 3.6 drastically hurt
> THP allocations but the approach was flawed. For Eric, the problem was
> that page->pfmemalloc was not being cleared for captured pages leading to
> a poor interaction with swap-over-NFS support causing the packets to be
> dropped. However, I identified a few more problems with the patch including
> the fact that it can increase contention on zone->lock in some cases which
> could result in async direct compaction being aborted early.
>
> In retrospect the capture patch took the wrong approach. What it should
> have done is mark the pageblock being migrated as MIGRATE_ISOLATE if it
> was allocating for THP and avoided races that way. While the patch was
Hi Mel,
Mark pageblock being migrated as MIGRATE_ISOLATE if it was allocating
for THP and avoided races that way is a good idea. But why I can't see
you do it in this patch?
> showing to improve allocation success rates at the time, the benefit is
> marginal given the relative complexity and it should be revisited from
> scratch in the context of the other reclaim-related changes that have taken
> place since the patch was first written and tested. This patch partially
> reverts commit 1fb3f8ca "mm: compaction: capture a suitable high-order
> page immediately when it is made available".
>
> Reported-and-tested-by: Eric Wong
> Tested-by: Eric Dumazet
> Cc: sta...@vger.kernel.org
> Signed-off-by: Mel Gorman
> ---
> include/linux/compaction.h |4 +-
> include/linux/mm.h |1 -
> mm/compaction.c| 92
> +++-
> mm/internal.h |1 -
> mm/page_alloc.c| 35 -
> 5 files changed, 23 insertions(+), 110 deletions(-)
>
> diff --git a/include/linux/compaction.h b/include/linux/compaction.h
> index 6ecb6dc..cc7bdde 100644
> --- a/include/linux/compaction.h
> +++ b/include/linux/compaction.h
> @@ -22,7 +22,7 @@ extern int sysctl_extfrag_handler(struct ctl_table *table,
> int write,
> extern int fragmentation_index(struct zone *zone, unsigned int order);
> extern unsigned long try_to_compact_pages(struct zonelist *zonelist,
> int order, gfp_t gfp_mask, nodemask_t *mask,
> - bool sync, bool *contended, struct page **page);
> + bool sync, bool *contended);
> extern int compact_pgdat(pg_data_t *pgdat, int order);
> extern void reset_isolation_suitable(pg_data_t *pgdat);
> extern unsigned long compaction_suitable(struct zone *zone, int order);
> @@ -75,7 +75,7 @@ static inline bool compaction_restarting(struct zone *zone,
> int order)
> #else
> static inline unsigned long try_to_compact_pages(struct zonelist *zonelist,
> int order, gfp_t gfp_mask, nodemask_t *nodemask,
> - bool sync, bool *contended, struct page **page)
> + bool sync, bool *contended)
> {
> return COMPACT_CONTINUE;
> }
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 6320407..66e2f7c 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -455,7 +455,6 @@ void put_pages_list(struct list_head *pages);
>
> void split_page(struct page *page, unsigned int order);
> int split_free_page(struct page *page);
> -int capture_free_page(struct page *page, int alloc_order, int migratetype);
>
> /*
> * Compound pages have a destructor function. Provide a
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 6b807e4..2c57043 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -816,6 +816,7 @@ static isolate_migrate_t isolate_migratepages(struct zone
> *zone,
> static int compact_finished(struct zone *zone,
> struct compact_control *cc)
> {
> + unsigned int order;
> unsigned long watermark;
>
> if (fatal_signal_pending(current))
> @@ -850,22 +851,16 @@ static int compact_finished(struct zone *zone,
> return COMPACT_CONTINUE;
>
> /* Direct compactor: Is a suitable page free? */
> - if (cc->page) {
> - /* Was a suitable page captured? */
> - if (*cc->page)
> + for (order = cc->order; order < MAX_ORDER; order++) {
> + struct free_area *area = >free_area[order];
> +
> + /* Job done if page is free of the right migratetype */
> + if (!list_empty(>free_list[cc->migratetype]))
> + return COMPACT_PARTIAL;
> +
> + /* Job done if allocation
[PATCH] scripts: kconfig: qconf.cc: fix a compiliation error when using make xconfig
When using make xconfig, the following compilation error appears : /usr/include/qt3/qvaluelist.h:427:13: error: ‘ptrdiff_t’ does not name a type Including stddef.h in scripts/kconfig/qconf.cc permits to avoid this error. Signed-off-by: Tiana Rakotovao Andriamahefa --- scripts/kconfig/qconf.cc |1 + 1 file changed, 1 insertion(+) diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc index df274fe..1500c38 100644 --- a/scripts/kconfig/qconf.cc +++ b/scripts/kconfig/qconf.cc @@ -6,6 +6,7 @@ #include #if QT_VERSION < 0x04 +#include #include #include #include -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] staging/comedi/das08_cs: Convert to module_comedi_pcmcia_driver
This patch removes the boring init/exit functions with the new
module_comedi_pcmcia_driver macro.
Signed-off-by: Peter Huewe
---
drivers/staging/comedi/drivers/das08_cs.c | 26 +-
1 files changed, 1 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/comedi/drivers/das08_cs.c
b/drivers/staging/comedi/drivers/das08_cs.c
index 0242623..73a2418 100644
--- a/drivers/staging/comedi/drivers/das08_cs.c
+++ b/drivers/staging/comedi/drivers/das08_cs.c
@@ -181,31 +181,7 @@ static struct pcmcia_driver das08_cs_driver = {
.id_table = das08_cs_id_table,
};
-static int __init das08_cs_init_module(void)
-{
- int ret;
-
- ret = comedi_driver_register(_das08_cs);
- if (ret < 0)
- return ret;
-
- ret = pcmcia_register_driver(_cs_driver);
- if (ret < 0) {
- comedi_driver_unregister(_das08_cs);
- return ret;
- }
-
- return 0;
-
-}
-module_init(das08_cs_init_module);
-
-static void __exit das08_cs_exit_module(void)
-{
- pcmcia_unregister_driver(_cs_driver);
- comedi_driver_unregister(_das08_cs);
-}
-module_exit(das08_cs_exit_module);
+module_comedi_pcmcia_driver(driver_das08_cs, das08_cs_driver);
MODULE_AUTHOR("David A. Schleef , "
"Frank Mori Hess ");
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/8] staging/comedi/cb_das16_cs: Convert to module_comedi_pcmcia_driver
This patch removes the boring init/exit functions with the new
module_comedi_pcmcia_driver macro.
Signed-off-by: Peter Huewe
---
drivers/staging/comedi/drivers/cb_das16_cs.c | 25 +
1 files changed, 1 insertions(+), 24 deletions(-)
diff --git a/drivers/staging/comedi/drivers/cb_das16_cs.c
b/drivers/staging/comedi/drivers/cb_das16_cs.c
index 93731de..e253fc0 100644
--- a/drivers/staging/comedi/drivers/cb_das16_cs.c
+++ b/drivers/staging/comedi/drivers/cb_das16_cs.c
@@ -548,30 +548,7 @@ static struct pcmcia_driver das16cs_driver = {
.id_table = das16cs_id_table,
};
-static int __init das16cs_init(void)
-{
- int ret;
-
- ret = comedi_driver_register(_das16cs);
- if (ret < 0)
- return ret;
-
- ret = pcmcia_register_driver(_driver);
- if (ret < 0) {
- comedi_driver_unregister(_das16cs);
- return ret;
- }
-
- return 0;
-}
-module_init(das16cs_init);
-
-static void __exit das16cs_exit(void)
-{
- pcmcia_unregister_driver(_driver);
- comedi_driver_unregister(_das16cs);
-}
-module_exit(das16cs_exit);
+module_comedi_pcmcia_driver(driver_das16cs, das16cs_driver);
MODULE_AUTHOR("David A. Schleef ");
MODULE_DESCRIPTION("Comedi driver for Computer Boards PC-CARD DAS16/16");
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] staging/comedi/ni_daq_700: Convert to module_comedi_pcmcia_driver
This patch removes the boring init/exit functions with the new
module_comedi_pcmcia_driver macro.
Signed-off-by: Peter Huewe
---
drivers/staging/comedi/drivers/ni_daq_700.c | 25 +
1 files changed, 1 insertions(+), 24 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_daq_700.c
b/drivers/staging/comedi/drivers/ni_daq_700.c
index 68d7c6a..ff0e199 100644
--- a/drivers/staging/comedi/drivers/ni_daq_700.c
+++ b/drivers/staging/comedi/drivers/ni_daq_700.c
@@ -334,30 +334,7 @@ static struct pcmcia_driver daq700_cs_driver = {
.id_table = daq700_cs_ids,
};
-static int __init daq700_cs_init(void)
-{
- int ret;
-
- ret = comedi_driver_register(_driver);
- if (ret < 0)
- return ret;
-
- ret = pcmcia_register_driver(_cs_driver);
- if (ret < 0) {
- comedi_driver_unregister(_driver);
- return ret;
- }
-
- return 0;
-}
-module_init(daq700_cs_init);
-
-static void __exit daq700_cs_exit(void)
-{
- pcmcia_unregister_driver(_cs_driver);
- comedi_driver_unregister(_driver);
-}
-module_exit(daq700_cs_exit);
+module_comedi_pcmcia_driver(daq700_driver, daq700_cs_driver);
MODULE_AUTHOR("Fred Brooks ");
MODULE_DESCRIPTION(
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] staging/comedi/ni_labpc_cs: Convert to module_comedi_pcmcia_driver
This patch removes the boring init/exit functions with the new
module_comedi_pcmcia_driver macro.
Signed-off-by: Peter Huewe
---
drivers/staging/comedi/drivers/ni_labpc_cs.c | 31 +-
1 files changed, 1 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_labpc_cs.c
b/drivers/staging/comedi/drivers/ni_labpc_cs.c
index bfe19fa..b26496d 100644
--- a/drivers/staging/comedi/drivers/ni_labpc_cs.c
+++ b/drivers/staging/comedi/drivers/ni_labpc_cs.c
@@ -282,33 +282,4 @@ static struct pcmcia_driver labpc_cs_driver = {
.name = "daqcard-1200",
};
-static int __init init_labpc_cs(void)
-{
- pcmcia_register_driver(_cs_driver);
- return 0;
-}
-
-static void __exit exit_labpc_cs(void)
-{
- pcmcia_unregister_driver(_cs_driver);
-}
-
-static int __init labpc_init_module(void)
-{
- int ret;
-
- ret = init_labpc_cs();
- if (ret < 0)
- return ret;
-
- return comedi_driver_register(_labpc_cs);
-}
-
-static void __exit labpc_exit_module(void)
-{
- exit_labpc_cs();
- comedi_driver_unregister(_labpc_cs);
-}
-
-module_init(labpc_init_module);
-module_exit(labpc_exit_module);
+module_comedi_pcmcia_driver(driver_labpc_cs, labpc_cs_driver);
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] staging/comedi/ni_mio_cs: Convert to module_comedi_pcmcia_driver
This patch removes the boring init/exit functions with the new
module_comedi_pcmcia_driver macro.
Also removed the superflous #ifdef MODULE
Signed-off-by: Peter Huewe
---
drivers/staging/comedi/drivers/ni_mio_cs.c | 20 +---
1 files changed, 1 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_mio_cs.c
b/drivers/staging/comedi/drivers/ni_mio_cs.c
index 76c6a13..b5c5d58 100644
--- a/drivers/staging/comedi/drivers/ni_mio_cs.c
+++ b/drivers/staging/comedi/drivers/ni_mio_cs.c
@@ -408,8 +408,6 @@ static int ni_getboardtype(struct comedi_device *dev,
return 0;
}
-#ifdef MODULE
-
static const struct pcmcia_device_id ni_mio_cs_ids[] = {
PCMCIA_DEVICE_MANF_CARD(0x010b, 0x010d),/* DAQCard-ai-16xe-50 */
PCMCIA_DEVICE_MANF_CARD(0x010b, 0x010c),/* DAQCard-ai-16e-4 */
@@ -434,20 +432,4 @@ static struct pcmcia_driver ni_mio_cs_driver = {
.name = "ni_mio_cs",
};
-int init_module(void)
-{
- pcmcia_register_driver(_mio_cs_driver);
- comedi_driver_register(_ni_mio_cs);
- return 0;
-}
-
-void cleanup_module(void)
-{
- pcmcia_unregister_driver(_mio_cs_driver);
-#if 0
- while (cur_dev != NULL)
- cs_detach(cur_dev->handle);
-#endif
- comedi_driver_unregister(_ni_mio_cs);
-}
-#endif
+module_comedi_pcmcia_driver(driver_ni_mio_cs, ni_mio_cs_driver);
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8] staging/comedi/quatech_daqp_cs: Convert to module_comedi_pcmcia_driver
This patch removes the boring init/exit functions with the new
module_comedi_pcmcia_driver macro.
Also removed the superflous #ifdef MODULE
Signed-off-by: Peter Huewe
---
drivers/staging/comedi/drivers/quatech_daqp_cs.c | 18 +-
1 files changed, 1 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/comedi/drivers/quatech_daqp_cs.c
b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
index ef0cdaa..55d8cc6 100644
--- a/drivers/staging/comedi/drivers/quatech_daqp_cs.c
+++ b/drivers/staging/comedi/drivers/quatech_daqp_cs.c
@@ -1038,9 +1038,6 @@ static int daqp_cs_resume(struct pcmcia_device *link)
}
/**/
-
-#ifdef MODULE
-
static const struct pcmcia_device_id daqp_cs_id_table[] = {
PCMCIA_DEVICE_MANF_CARD(0x0137, 0x0027),
PCMCIA_DEVICE_NULL
@@ -1061,17 +1058,4 @@ static struct pcmcia_driver daqp_cs_driver = {
.name = "quatech_daqp_cs",
};
-int __init init_module(void)
-{
- pcmcia_register_driver(_cs_driver);
- comedi_driver_register(_daqp);
- return 0;
-}
-
-void __exit cleanup_module(void)
-{
- comedi_driver_unregister(_daqp);
- pcmcia_unregister_driver(_cs_driver);
-}
-
-#endif
+module_comedi_pcmcia_driver(driver_daqp, daqp_cs_driver);
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] staging/comedi/ni_daq_dio24: Convert to module_comedi_pcmcia_driver
This patch removes the boring init/exit functions with the new
module_comedi_pcmcia_driver macro.
Signed-off-by: Peter Huewe
---
drivers/staging/comedi/drivers/ni_daq_dio24.c | 29 +
1 files changed, 1 insertions(+), 28 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_daq_dio24.c
b/drivers/staging/comedi/drivers/ni_daq_dio24.c
index 7b5..dd22691 100644
--- a/drivers/staging/comedi/drivers/ni_daq_dio24.c
+++ b/drivers/staging/comedi/drivers/ni_daq_dio24.c
@@ -318,31 +318,4 @@ static struct pcmcia_driver dio24_cs_driver = {
.name = "ni_daq_dio24",
};
-static int __init init_dio24_cs(void)
-{
- printk("ni_daq_dio24: HOLA SOY YO!\n");
- pcmcia_register_driver(_cs_driver);
- return 0;
-}
-
-static void __exit exit_dio24_cs(void)
-{
- pcmcia_unregister_driver(_cs_driver);
-}
-
-int __init init_module(void)
-{
- int ret;
-
- ret = init_dio24_cs();
- if (ret < 0)
- return ret;
-
- return comedi_driver_register(_dio24);
-}
-
-void __exit cleanup_module(void)
-{
- exit_dio24_cs();
- comedi_driver_unregister(_dio24);
-}
+module_comedi_pcmcia_driver(driver_dio24, dio24_cs_driver);
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] staging/comedi: Add macro for registering a comedi PCMCIA driver
This patch introduces a new macro 'module_comedi_pcmcia_driver'
for comedi PCMCIA drivers which do not do anything special in module
init/exit. This eliminates a lot of boilerplate.
Adapted from 'module_comedi_pci_driver'
Signed-off-by: Peter Huewe
---
drivers/staging/comedi/comedidev.h | 22 ++
drivers/staging/comedi/drivers.c | 34 ++
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/comedi/comedidev.h
b/drivers/staging/comedi/comedidev.h
index 692e1e6..ccb22dd 100644
--- a/drivers/staging/comedi/comedidev.h
+++ b/drivers/staging/comedi/comedidev.h
@@ -41,6 +41,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include "comedi.h"
@@ -342,6 +345,25 @@ void comedi_pci_driver_unregister(struct comedi_driver *,
struct pci_driver *);
module_driver(__comedi_driver, comedi_pci_driver_register, \
comedi_pci_driver_unregister, &(__pci_driver))
+int comedi_pcmcia_driver_register(struct comedi_driver *,
+ struct pcmcia_driver *);
+void comedi_pcmcia_driver_unregister(struct comedi_driver *,
+ struct pcmcia_driver *);
+
+/**
+ * module_comedi_pcmcia_driver() - Helper macro for registering a comedi
PCMCIA driver
+ * @__comedi_driver: comedi_driver struct
+ * @__pcmcia_driver: pcmcia_driver struct
+ *
+ * Helper macro for comedi PCMCIA drivers which do not do anything special
+ * in module init/exit. This eliminates a lot of boilerplate. Each
+ * module may only use this macro once, and calling it replaces
+ * module_init() and module_exit()
+ */
+#define module_comedi_pcmcia_driver(__comedi_driver, __pcmcia_driver) \
+ module_driver(__comedi_driver, comedi_pcmcia_driver_register, \
+ comedi_pcmcia_driver_unregister, &(__pcmcia_driver))
+
struct usb_driver;
int comedi_usb_driver_register(struct comedi_driver *, struct usb_driver *);
diff --git a/drivers/staging/comedi/drivers.c b/drivers/staging/comedi/drivers.c
index 50cf498..17a9e35 100644
--- a/drivers/staging/comedi/drivers.c
+++ b/drivers/staging/comedi/drivers.c
@@ -24,6 +24,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
#include
@@ -958,6 +961,37 @@ void comedi_pci_driver_unregister(struct comedi_driver
*comedi_driver,
}
EXPORT_SYMBOL_GPL(comedi_pci_driver_unregister);
+int comedi_pcmcia_driver_register(struct comedi_driver *comedi_driver,
+ struct pcmcia_driver *pcmcia_driver)
+{
+ int ret;
+
+ ret = comedi_driver_register(comedi_driver);
+ if (ret < 0)
+ return ret;
+
+ /* FIXME: Remove this test after auditing all comedi pci drivers */
+ if (!pcmcia_driver->name)
+ pcmcia_driver->name = comedi_driver->driver_name;
+
+ ret = pcmcia_register_driver(pcmcia_driver);
+ if (ret < 0) {
+ comedi_driver_unregister(comedi_driver);
+ return ret;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(comedi_pcmcia_driver_register);
+
+void comedi_pcmcia_driver_unregister(struct comedi_driver *comedi_driver,
+ struct pcmcia_driver *pcmcia_driver)
+{
+ pcmcia_unregister_driver(pcmcia_driver);
+ comedi_driver_unregister(comedi_driver);
+}
+EXPORT_SYMBOL_GPL(comedi_pcmcia_driver_unregister);
+
#if IS_ENABLED(CONFIG_USB)
int comedi_usb_driver_register(struct comedi_driver *comedi_driver,
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
radeon causing sleeping function called from invalid context
BUG: sleeping function called from invalid context at mm/slub.c:925 in_atomic(): 1, irqs_disabled(): 0, pid: 566, name: Xorg INFO: lockdep is turned off. Pid: 566, comm: Xorg Not tainted 3.8.0-rc3+ #49 Call Trace: [] __might_sleep+0x141/0x200 [] kmem_cache_alloc_trace+0x4b/0x2a0 [] ttm_bo_move_accel_cleanup+0x1d3/0x330 [ttm] [] radeon_move_blit.isra.4+0xf8/0x160 [radeon] [] radeon_bo_move+0xb0/0x1f0 [radeon] [] ttm_bo_handle_move_mem+0x27d/0x5d0 [ttm] [] ? get_parent_ip+0x11/0x50 [] ttm_bo_move_buffer+0x127/0x140 [ttm] [] ? ttm_eu_list_ref_sub+0x3d/0x60 [ttm] [] ttm_bo_validate+0xa2/0x120 [ttm] [] radeon_bo_list_validate+0x75/0x90 [radeon] [] radeon_cs_ioctl+0x582/0x950 [radeon] [] drm_ioctl+0x4d3/0x580 [drm] [] ? radeon_cs_finish_pages+0xf0/0xf0 [radeon] [] do_vfs_ioctl+0x99/0x5a0 [] ? file_has_perm+0x97/0xb0 [] ? rcu_eqs_exit+0x65/0xb0 [] sys_ioctl+0x91/0xb0 [] tracesys+0xdd/0xe2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Nouveau hang on 3.6.11
Hello, I recently upgraded to 3.6.11, and just saw this hang for the first time. It happened within a minute of the monitor going to sleep (which in turn coincides with a non-GL screensaver running). It should be noted that Chrome is running with --ignore-gpu-blacklist, but I've been doing that for quite a while. I know that there's perf stuff in the NMI trace, but I was not (knowingly) running perf at the time. The CPU is an Intel Core i7-920, the video card is a NVIDIA Corporation G96 [GeForce 9500 GT] [10de:0640] (rev a1). I can upgrade to the latest kernel if necessary, but this is the first time I've seen this so I have no reliable way of triggering it. Messages on boot: [4.339304] [drm] Initialized drm 1.1.0 20060810 [4.355779] MXM: GUID detected in BIOS [4.356203] [drm] nouveau :02:00.0: Detected an NV50 generation card (0x096000c1) [4.359084] [drm] nouveau :02:00.0: Checking PRAMIN for VBIOS [4.418932] [drm] nouveau :02:00.0: ... appears to be valid [4.418934] [drm] nouveau :02:00.0: Using VBIOS from PRAMIN [4.418937] [drm] nouveau :02:00.0: BIT BIOS found [4.418939] [drm] nouveau :02:00.0: Bios version 62.94.2a.00 [4.418941] [drm] nouveau :02:00.0: TMDS table version 2.0 [4.419348] [drm] nouveau :02:00.0: MXM: no VBIOS data, nothing to do [4.419350] [drm] nouveau :02:00.0: DCB version 4.0 [4.419352] [drm] nouveau :02:00.0: DCB outp 00: 02000300 0028 [4.419354] [drm] nouveau :02:00.0: DCB outp 01: 01000302 00020030 [4.419355] [drm] nouveau :02:00.0: DCB outp 02: 04011310 0028 [4.419356] [drm] nouveau :02:00.0: DCB outp 03: 02011312 00020030 [4.419358] [drm] nouveau :02:00.0: DCB conn 00: 1030 [4.419360] [drm] nouveau :02:00.0: DCB conn 01: 2130 [4.419363] [drm] nouveau :02:00.0: Parsing VBIOS init table 0 at offset 0xD0BE [4.444655] [drm] nouveau :02:00.0: Parsing VBIOS init table 1 at offset 0xD4D3 [4.447676] [drm] nouveau :02:00.0: Parsing VBIOS init table 2 at offset 0xE4C4 [4.447685] [drm] nouveau :02:00.0: Parsing VBIOS init table 3 at offset 0xE60D [4.448761] [drm] nouveau :02:00.0: Parsing VBIOS init table 4 at offset 0xE849 [4.448763] [drm] nouveau :02:00.0: Parsing VBIOS init table at offset 0xE8AE [4.468757] [drm] nouveau :02:00.0: 0xE8AE: Condition still not met after 20ms, skipping following opcodes [4.473557] [TTM] Zone kernel: Available graphics memory: 3050182 kiB [4.473561] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [4.473563] [TTM] Initializing pool allocator [4.473568] [TTM] Initializing DMA pool allocator [4.473580] [drm] nouveau :02:00.0: Detected 1024MiB VRAM (DDR2) [4.473586] mtrr: type mismatch for d000,1000 old: write-back new: write-combining [4.473600] [drm] nouveau :02:00.0: 512 MiB GART (aperture) [4.517920] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [4.517923] [drm] No driver support for vblank timestamp query. [4.522957] [drm] nouveau :02:00.0: 1 available performance level(s) [4.522962] [drm] nouveau :02:00.0: 3: core 550MHz shader 1375MHz memory 400MHz fanspeed 100% [4.522966] [drm] nouveau :02:00.0: c: core 400MHz shader 800MHz memory 499MHz fanspeed 100% [4.567071] [drm] nouveau :02:00.0: MM: using CRYPT for buffer copies [4.686942] [drm] nouveau :02:00.0: allocated 1920x1200 fb: 0x2c, bo 8801a628e800 [4.687095] fbcon: nouveaufb (fb0) is primary device [4.711940] Console: switching to colour frame buffer device 240x75 [4.714822] fb0: nouveaufb frame buffer device [4.714824] drm: registered panic notifier [4.714857] [drm] Initialized nouveau 1.0.0 20120316 for :02:00.0 on minor 0 Message on hang: [837686.468812] [drm] nouveau :02:00.0: nv50cal_space: -16 [837686.490446] [drm] nouveau :02:00.0: nv50cal_space: -16 [837686.511742] [drm] nouveau :02:00.0: nv50cal_space: -16 [837725.012153] SysRq : Emergency Sync [837725.045587] Emergency Sync complete [837725.380953] [ cut here ] [837725.380962] WARNING: at kernel/watchdog.c:242 watchdog_overflow_callback+0x9b/0xa6() [837725.380964] Hardware name: EX58-UD3R [837725.380966] Watchdog detected hard LOCKUP on cpu 4 [837725.380967] Modules linked in: it87 hwmon_vid bridge stp llc btusb bluetooth crc16 nouveau fbcon font bitblit softcursor tt backlight i2c_algo_bit cfbcopyarea mxm_wmi wmi cfbimgblt cfbfillrect [837725.380994] Pid: 23949, comm: chrome Not tainted 3.6.11-gentoo #3 [837725.380996] Call Trace: [837725.380998][] ? watchdog_overflow_callback+0x9b/0xa6 [837725.381008] [] warn_slowpath_common+0x85/0x9d [837725.381012] [] warn_slowpath_fmt+0x46/0x48 [837725.381016] [] ? sched_cloc_cpu+0x42/0xc6 [837725.381020] [] watchdog_overflow_callback+0x9b/0xa6 [837725.381025] [] __perf_event_overflow+0x134/0x1be
Re: [PATCH] mm: wait for congestion to clear on all zones
On Fri, 2013-01-11 at 12:25 +0100, Zlatko Calusic wrote: > On 11.01.2013 02:25, Simon Jeons wrote: > > On Wed, 2013-01-09 at 22:41 +0100, Zlatko Calusic wrote: > >> From: Zlatko Calusic > >> > >> Currently we take a short nap (HZ/10) and wait for congestion to clear > >> before taking another pass with lower priority in balance_pgdat(). But > >> we do that only for the highest zone that we encounter is unbalanced > >> and congested. > >> > >> This patch changes that to wait on all congested zones in a single > >> pass in the hope that it will save us some scanning that way. Also we > >> take a nap as soon as congested zone is encountered and sc.priority < > >> DEF_PRIORITY - 2 (aka kswapd in trouble). > > > > But you still didn't explain what's the problem you meat and what > > scenario can get benefit from your change. > > > > I did in my reply to Andrew. Here's the relevant part: > > > I have an observation that without it, under some circumstances that > > are VERY HARD to repeat (many days need to pass and some stars to align > > to see the effect), the page cache gets hit hard, 2/3 of it evicted in > > a split second. And it's not even under high load! So, I'm still > > monitoring it, but so far the memory utilization really seems better > > with the patch applied (no more mysterious page cache shootdowns). > > The scenario that should get benefit is everyday. I observed problems during > light but constant reading from disk (< 10MB/s). And sending that data > over the network at the same time. Think backup that compresses data on the > fly before pushing it over the network (so it's not very fast). > > The trouble is that you can't just fix up a quick benchmark and measure the > impact, because many days need to pass for the bug to show up in all it's > beauty. > > Is there anybody out there who'd like to comment on the patch logic? I.e. do > you think that waiting on every congested zone is the more correct solution > than waiting on only one (only the highest one, and ignoring the fact that > there may be other even more congested zones)? What's the benefit of waiting on every congested zone than waiting on only one against your scenario? > > Regards, -- Simon Jeons -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fb: Rework locking to fix lock ordering on takeover
On Sat, Jan 12, 2013 at 01:13:23PM -0800, Andrew Morton wrote: > Florian has been taking a month or two's downtime (now expired, I > think) so I've been waiting for him to reappear to process this one for > 3.8. > > Meanwhile, I guess we could put it into mainline ;) It has been in > -next for a month. > > From: Alan Cox > Subject: fb: rework locking to fix lock ordering on takeover > > Adjust the console layer to allow a take over call where the caller > already holds the locks. Make the fb layer lock in order. > > This is partly a band aid, the fb layer is terminally confused about the > locking rules it uses for its notifiers it seems. > > [a...@linux-foundation.org: remove stray non-ascii char, tidy comment] > [a...@linux-foundation.org: export do_take_over_console()] > Signed-off-by: Alan Cox > Cc: Florian Tobias Schandinat > Cc: Stephen Rothwell > Signed-off-by: Andrew Morton Yes, that's the one, modulo Andrew's fixes, which I've been running. Irregardless, I'll run this one tomorrow just in case, because it triggers here so easily. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why is the kfree() argument const?
On Wednesday, January 16, 2008 8:39:48 PM UTC+2, Linus Torvalds wrote:
> "const" has *never* been about the thing not being modified. Forget all
> that claptrap. C does not have such a notion.
I beg your pardon?!
C has had that very notion ever since its first standard (1989). Here is an
excerpt from that standard (ISO/IEC 9899:1990, section 6.5.3):
"If an attempt is made to modify an object defined with a const-qualified
type through use of an lvalue with non-const-qualified type, the behavior is
undefined."
> "const" is a pointer type issue, and is meant to make certain mis-uses
> more visible at compile time. It has *no* other meaning, and anybody who
> thinks it has is just setting himself up for problems.
'const' is also a pointer issue, but not only - see above quote from the C
Standard.
Defining an object 'const' can have an impact on optimization (and also on
whether the object is placed in read-only memory). Here are trivial examples to
illustrate:
void foo1(const int* pi)
{
*(int*)pi = 1;
}
#include
void foo1(const int* pi);
int main(void)
{
int i = 0;
foo1();
printf("i = %d\n", i);
return 0;
}
Program1 defines 'i' non-const, and modifies it through a const pointer, by
casting const away in foo1(). This is allowed - although not necessarily wise.
Program1 has well defined behavior: it prints "i = 1". The generated code
dutifully retrieves the value of 'i' before passing it to printf().
void foo2(const int* pi)
{
}
#include
void foo2(const int* pi);
int main(void)
{
const int i = 0;
foo2();
printf("i = %d\n", i);
return 0;
}
Program2 defines 'i' const. A pointer to 'i' is passed to foo2(), which does
not modify 'i'.
Program2 has well defined behavior: it prints "i = 0". When it generates code
for main1.c, the compiler can assume that 'i' is not modified, because 'i' is
defined const.
When compiling main2.c with gcc 4.4.7 with optimizations turned off (-O0), the
generated code retrieves the value of 'i' before passing it to printf(). With
optimizations turned on (-O3), it inlines the value of 'i', 0, in the call to
printf(). Both versions have the same, correct behavior.
void foo3(const int* pi)
{
*(int*)pi = 1;
}
#include
void foo3(const int* pi);
int main(void)
{
const int i = 0;
foo3();
printf("i = %d\n", i);
return 0;
}
Program3 defines 'i' const, and attempts to modify it through a const pointer,
by casting const away in foo3().
On my particular system, when compiling Program3 with gcc 4.4.7 with
optimizations turned off (-O0), the program prints "i = 1". With optimizations
turned on (-O3), it prints "i = 0".
The question of which of these two behaviors is "correct" would be pointless,
since Program3 has undefined behavior.
Antoine
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 22/22] PCI: move device_add out of pci_bus_add_device()
On Friday, January 11, 2013 02:40:49 PM Yinghai Lu wrote:
> Move out device registering out of pci_bus_add_devices, so we could
> put new created pci devices in device tree early.
>
> new pci_bus_add_devices will do the device_attach work to load pci drivers
> instead.
I wonder what problem it solves?
> Signed-off-by: Yinghai Lu
> ---
> drivers/pci/bus.c | 47 +++
> drivers/pci/iov.c |7 ---
> drivers/pci/probe.c | 34 +++---
> 3 files changed, 30 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
> index 1f5916a..0a55845 100644
> --- a/drivers/pci/bus.c
> +++ b/drivers/pci/bus.c
> @@ -178,22 +178,9 @@ static void pci_bus_attach_device(struct pci_dev *dev)
> */
> int pci_bus_add_device(struct pci_dev *dev)
> {
> - int retval;
> -
> - pci_fixup_device(pci_fixup_final, dev);
> -
> - retval = pcibios_add_device(dev);
> - if (retval)
> - return retval;
> -
> - retval = device_add(>dev);
> - if (retval)
> - return retval;
> -
> pci_bus_attach_device(dev);
> dev->is_added = 1;
> - pci_proc_attach_device(dev);
> - pci_create_sysfs_dev_files(dev);
> +
> return 0;
> }
>
> @@ -205,21 +192,9 @@ int pci_bus_add_device(struct pci_dev *dev)
> */
> int pci_bus_add_child(struct pci_bus *bus)
> {
> - int retval;
> -
> - if (bus->bridge)
> - bus->dev.parent = bus->bridge;
> -
> - retval = device_add(>dev);
> - if (retval)
> - return retval;
> -
> bus->is_added = 1;
>
> - /* Create legacy_io and legacy_mem files for this bus */
> - pci_create_legacy_files(bus);
> -
> - return retval;
> + return 0;
> }
>
> /**
> @@ -245,36 +220,20 @@ void pci_bus_add_devices(const struct pci_bus *bus)
> if (dev->is_added)
> continue;
> retval = pci_bus_add_device(dev);
> - if (retval)
> - dev_err(>dev, "Error adding device, continuing\n");
> }
>
> list_for_each_entry(dev, >devices, bus_list) {
> BUG_ON(!dev->is_added);
>
> child = dev->subordinate;
> - /*
> - * If there is an unattached subordinate bus, attach
> - * it and then scan for unattached PCI devices.
> - */
> +
> if (!child)
> continue;
> - if (list_empty(>node)) {
> - down_write(_bus_sem);
> - list_add_tail(>node, >bus->children);
> - up_write(_bus_sem);
> - }
> pci_bus_add_devices(child);
>
> - /*
> - * register the bus with sysfs as the parent is now
> - * properly registered.
> - */
> if (child->is_added)
> continue;
> retval = pci_bus_add_child(child);
> - if (retval)
> - dev_err(>dev, "Error adding bus, continuing\n");
> }
> }
>
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index bafd2bb..dbad72e 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -48,12 +48,7 @@ static struct pci_bus *virtfn_add_bus(struct pci_bus *bus,
> int busnr)
> return NULL;
>
> pci_bus_insert_busn_res(child, busnr, busnr);
> - child->dev.parent = bus->bridge;
> rc = pci_bus_add_child(child);
> - if (rc) {
> - pci_remove_bus(child);
> - return NULL;
> - }
>
> return child;
> }
> @@ -123,8 +118,6 @@ static int virtfn_add(struct pci_dev *dev, int id, int
> reset)
> virtfn->is_virtfn = 1;
>
> rc = pci_bus_add_device(virtfn);
> - if (rc)
> - goto failed1;
> sprintf(buf, "virtfn%u", id);
> rc = sysfs_create_link(>dev.kobj, >dev.kobj, buf);
> if (rc)
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index dc4fde3..84c92a0 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -623,6 +623,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus
> *parent,
> {
> struct pci_bus *child;
> int i;
> + int ret;
>
> /*
>* Allocate a new bus, and inherit stuff from the parent..
> @@ -637,8 +638,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus
> *parent,
> child->bus_flags = parent->bus_flags;
>
> /* initialize some portions of the bus device, but don't register it
> - * now as the parent is not properly set up yet. This device will get
> - * registered later in pci_bus_add_devices()
> + * now as the parent is not properly set up yet.
>*/
> child->dev.class = _class;
> dev_set_name(>dev, "%04x:%02x", pci_domain_nr(child), busnr);
> @@ -652,11 +652,14 @@ static struct pci_bus *pci_alloc_child_bus(struct
> pci_bus *parent,
>
Re: [PATCH v8 21/22] PCI: add match_driver in struct pci_dev
On Friday, January 11, 2013 02:40:48 PM Yinghai Lu wrote:
> with that we could move out attaching driver for pci device,
> out of device_add for pci hot add path.
>
> pci_bus_attach_device() will attach driver to pci device.
Clever, but I wonder why exactly we need to do that?
Rafael
> Signed-off-by: Yinghai Lu
> ---
> drivers/pci/bus.c| 10 ++
> drivers/pci/pci-driver.c |6 +-
> include/linux/pci.h |1 +
> 3 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
> index 5f9c728..1f5916a 100644
> --- a/drivers/pci/bus.c
> +++ b/drivers/pci/bus.c
> @@ -160,6 +160,15 @@ pci_bus_alloc_resource(struct pci_bus *bus, struct
> resource *res,
>
> void __weak pcibios_resource_survey_bus(struct pci_bus *bus) { }
>
> +static void pci_bus_attach_device(struct pci_dev *dev)
> +{
> + int ret;
> +
> + dev->match_driver = true;
> + ret = device_attach(>dev);
> + WARN_ON(ret < 0);
> +}
> +
> /**
> * pci_bus_add_device - add a single device
> * @dev: device to add
> @@ -181,6 +190,7 @@ int pci_bus_add_device(struct pci_dev *dev)
> if (retval)
> return retval;
>
> + pci_bus_attach_device(dev);
> dev->is_added = 1;
> pci_proc_attach_device(dev);
> pci_create_sysfs_dev_files(dev);
> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
> index f79cbcd..acdcc3c 100644
> --- a/drivers/pci/pci-driver.c
> +++ b/drivers/pci/pci-driver.c
> @@ -1186,9 +1186,13 @@ pci_dev_driver(const struct pci_dev *dev)
> static int pci_bus_match(struct device *dev, struct device_driver *drv)
> {
> struct pci_dev *pci_dev = to_pci_dev(dev);
> - struct pci_driver *pci_drv = to_pci_driver(drv);
> + struct pci_driver *pci_drv;
> const struct pci_device_id *found_id;
>
> + if (!pci_dev->match_driver)
> + return 0;
> +
> + pci_drv = to_pci_driver(drv);
> found_id = pci_match_device(pci_drv, pci_dev);
> if (found_id)
> return 1;
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 907b455..d73af08 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -286,6 +286,7 @@ struct pci_dev {
> unsigned intirq;
> struct resource resource[DEVICE_COUNT_RESOURCE]; /* I/O and memory
> regions + expansion ROMs */
>
> + bool match_driver;
> /* These fields are used by common fixups */
> unsigned inttransparent:1; /* Transparent PCI bridge */
> unsigned intmultifunction:1;/* Part of multi-function device */
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 17/22] PCI, ACPI: Add alloc_acpi_hp_work()
On Friday, January 11, 2013 02:40:44 PM Yinghai Lu wrote:
> Will use it with acpiphp and pci_root_hp events handling
I think it would be better if you folded patches [17-20/22] together.
Thanks,
Rafael
> Signed-off-by: Yinghai Lu
> Cc: Len Brown
> Cc: linux-a...@vger.kernel.org
> ---
> drivers/acpi/osl.c | 21 +
> include/acpi/acpiosxf.h |9 +
> 2 files changed, 30 insertions(+)
>
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index 3ff2678..e6539a3 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -1778,3 +1778,24 @@ void acpi_os_set_prepare_sleep(int (*func)(u8
> sleep_state,
> {
> __acpi_os_prepare_sleep = func;
> }
> +
> +void alloc_acpi_hp_work(acpi_handle handle, u32 type, void *context,
> + void (*func)(struct work_struct *work))
> +{
> + struct acpi_hp_work *hp_work;
> + int ret;
> +
> + hp_work = kmalloc(sizeof(*hp_work), GFP_KERNEL);
> + if (!hp_work)
> + return;
> +
> + hp_work->handle = handle;
> + hp_work->type = type;
> + hp_work->context = context;
> +
> + INIT_WORK(_work->work, func);
> + ret = queue_work(kacpi_hotplug_wq, _work->work);
> + if (!ret)
> + kfree(hp_work);
> +}
> +EXPORT_SYMBOL(alloc_acpi_hp_work);
> diff --git a/include/acpi/acpiosxf.h b/include/acpi/acpiosxf.h
> index 4315274..2a64da5 100644
> --- a/include/acpi/acpiosxf.h
> +++ b/include/acpi/acpiosxf.h
> @@ -195,6 +195,15 @@ void acpi_os_fixed_event_count(u32 fixed_event_number);
> */
> extern struct workqueue_struct *kacpi_hotplug_wq;
>
> +struct acpi_hp_work {
> + struct work_struct work;
> + acpi_handle handle;
> + u32 type;
> + void *context;
> +};
> +void alloc_acpi_hp_work(acpi_handle handle, u32 type, void *context,
> + void (*func)(struct work_struct *work));
> +
> acpi_thread_id acpi_os_get_thread_id(void);
>
> acpi_status
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 16/22] PCI, acpiphp: Don't bailout even no slots found yet.
On Friday, January 11, 2013 02:40:43 PM Yinghai Lu wrote:
> Could have root bus hot addde later and there may be slots that need acpiphp.
s/addde/added/
The changes look reasonable to me, but I'm not very familiar with the code in
question.
Thanks,
Rafael
> Signed-off-by: Yinghai Lu
> ---
> drivers/pci/hotplug/acpiphp.h |1 -
> drivers/pci/hotplug/acpiphp_core.c | 23 ++-
> drivers/pci/hotplug/acpiphp_glue.c | 22 --
> 3 files changed, 2 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/pci/hotplug/acpiphp.h b/drivers/pci/hotplug/acpiphp.h
> index a1afb5b..b3ead7a 100644
> --- a/drivers/pci/hotplug/acpiphp.h
> +++ b/drivers/pci/hotplug/acpiphp.h
> @@ -193,7 +193,6 @@ extern void acpiphp_unregister_hotplug_slot(struct
> acpiphp_slot *slot);
> /* acpiphp_glue.c */
> extern int acpiphp_glue_init (void);
> extern void acpiphp_glue_exit (void);
> -extern int acpiphp_get_num_slots (void);
> typedef int (*acpiphp_callback)(struct acpiphp_slot *slot, void *data);
>
> extern int acpiphp_enable_slot (struct acpiphp_slot *slot);
> diff --git a/drivers/pci/hotplug/acpiphp_core.c
> b/drivers/pci/hotplug/acpiphp_core.c
> index 96316b7..c2fd309 100644
> --- a/drivers/pci/hotplug/acpiphp_core.c
> +++ b/drivers/pci/hotplug/acpiphp_core.c
> @@ -50,7 +50,6 @@
> bool acpiphp_debug;
>
> /* local variables */
> -static int num_slots;
> static struct acpiphp_attention_info *attention_info;
>
> #define DRIVER_VERSION "0.5"
> @@ -272,25 +271,6 @@ static int get_adapter_status(struct hotplug_slot
> *hotplug_slot, u8 *value)
> return 0;
> }
>
> -static int __init init_acpi(void)
> -{
> - int retval;
> -
> - /* initialize internal data structure etc. */
> - retval = acpiphp_glue_init();
> -
> - /* read initial number of slots */
> - if (!retval) {
> - num_slots = acpiphp_get_num_slots();
> - if (num_slots == 0) {
> - acpiphp_glue_exit();
> - retval = -ENODEV;
> - }
> - }
> -
> - return retval;
> -}
> -
> /**
> * release_slot - free up the memory used by a slot
> * @hotplug_slot: slot to free
> @@ -379,7 +359,8 @@ static int __init acpiphp_init(void)
> return 0;
>
> /* read all the ACPI info from the system */
> - return init_acpi();
> + /* initialize internal data structure etc. */
> + return acpiphp_glue_init();
> }
>
>
> diff --git a/drivers/pci/hotplug/acpiphp_glue.c
> b/drivers/pci/hotplug/acpiphp_glue.c
> index 02c41ab..30467ec 100644
> --- a/drivers/pci/hotplug/acpiphp_glue.c
> +++ b/drivers/pci/hotplug/acpiphp_glue.c
> @@ -1446,28 +1446,6 @@ void acpiphp_glue_exit(void)
> acpi_pci_unregister_driver(_pci_hp_driver);
> }
>
> -
> -/**
> - * acpiphp_get_num_slots - count number of slots in a system
> - */
> -int __init acpiphp_get_num_slots(void)
> -{
> - struct acpiphp_bridge *bridge;
> - int num_slots = 0;
> -
> - list_for_each_entry(bridge, _list, list) {
> - dbg("Bus %04x:%02x has %d slot%s\n",
> - pci_domain_nr(bridge->pci_bus),
> - bridge->pci_bus->number, bridge->nr_slots,
> - bridge->nr_slots == 1 ? "" : "s");
> - num_slots += bridge->nr_slots;
> - }
> -
> - dbg("Total %d slots\n", num_slots);
> - return num_slots;
> -}
> -
> -
> /**
> * acpiphp_enable_slot - power on slot
> * @slot: ACPI PHP slot
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 13/22] PCI, ACPI: remove acpi_root_bridge in pci_root_hp
On Friday, January 11, 2013 02:40:40 PM Yinghai Lu wrote:
> Tang noticed that hotplug through container will not update acpi_root_bridge
> list.
>
> After closely checking, we don't need that for struct for tracking and
> could use acpi_pci_root directly.
Well, precisely, so please modify your patches [08-09/22] accordingly instead
of adding this one.
Thanks,
Rafael
> Reported-by: Tang Chen
> Signed-off-by: Yinghai Lu
> ---
> drivers/acpi/pci_root.c | 109
> +--
> 1 file changed, 20 insertions(+), 89 deletions(-)
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 862abcc..697ec65 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -679,73 +679,12 @@ int __init acpi_pci_root_init(void)
> * only support root bridge
> */
>
> -static LIST_HEAD(acpi_root_bridge_list);
> -struct acpi_root_bridge {
> - struct list_head list;
> - acpi_handle handle;
> - u32 flags;
> -};
> -
> /* bridge flags */
> #define ROOT_BRIDGE_HAS_EJ0 (0x0002)
> #define ROOT_BRIDGE_HAS_PS3 (0x0080)
>
> #define ACPI_STA_FUNCTIONING (0x0008)
>
> -static struct acpi_root_bridge *acpi_root_handle_to_bridge(acpi_handle
> handle)
> -{
> - struct acpi_root_bridge *bridge;
> -
> - list_for_each_entry(bridge, _root_bridge_list, list)
> - if (bridge->handle == handle)
> - return bridge;
> -
> - return NULL;
> -}
> -
> -/* allocate and initialize host bridge data structure */
> -static void add_acpi_root_bridge(acpi_handle handle)
> -{
> - struct acpi_root_bridge *bridge;
> - acpi_handle dummy_handle;
> - acpi_status status;
> -
> - /* if the bridge doesn't have _STA, we assume it is always there */
> - status = acpi_get_handle(handle, "_STA", _handle);
> - if (ACPI_SUCCESS(status)) {
> - unsigned long long tmp;
> -
> - status = acpi_evaluate_integer(handle, "_STA", NULL, );
> - if (ACPI_FAILURE(status)) {
> - printk(KERN_DEBUG "%s: _STA evaluation failure\n",
> - __func__);
> - return;
> - }
> - if ((tmp & ACPI_STA_FUNCTIONING) == 0)
> - /* don't register this object */
> - return;
> - }
> -
> - bridge = kzalloc(sizeof(struct acpi_root_bridge), GFP_KERNEL);
> - if (!bridge)
> - return;
> -
> - bridge->handle = handle;
> -
> - if (ACPI_SUCCESS(acpi_get_handle(handle, "_EJ0", _handle)))
> - bridge->flags |= ROOT_BRIDGE_HAS_EJ0;
> - if (ACPI_SUCCESS(acpi_get_handle(handle, "_PS3", _handle)))
> - bridge->flags |= ROOT_BRIDGE_HAS_PS3;
> -
> - list_add(>list, _root_bridge_list);
> -}
> -
> -static void remove_acpi_root_bridge(struct acpi_root_bridge *bridge)
> -{
> - list_del(>list);
> - kfree(bridge);
> -}
> -
> struct acpi_root_hp_work {
> struct work_struct work;
> acpi_handle handle;
> @@ -827,28 +766,25 @@ static int acpi_root_evaluate_object(acpi_handle
> handle, char *cmd, int val)
> return 0;
> }
>
> -static void handle_root_bridge_removal(acpi_handle handle,
> - struct acpi_root_bridge *bridge)
> +static void handle_root_bridge_removal(struct acpi_device *device)
> {
> + int ret_val;
> u32 flags = 0;
> - struct acpi_device *device;
> + acpi_handle dummy_handle;
> + acpi_handle handle = device->handle;
>
> - if (bridge) {
> - flags = bridge->flags;
> - remove_acpi_root_bridge(bridge);
> - }
> + if (ACPI_SUCCESS(acpi_get_handle(handle, "_EJ0", _handle)))
> + flags |= ROOT_BRIDGE_HAS_EJ0;
> + if (ACPI_SUCCESS(acpi_get_handle(handle, "_PS3", _handle)))
> + flags |= ROOT_BRIDGE_HAS_PS3;
>
> - if (!acpi_bus_get_device(handle, )) {
> - int ret_val;
> + /* remove pci devices at first */
> + ret_val = acpi_bus_trim(device, 0);
> + printk(KERN_DEBUG "acpi_bus_trim stop return %x\n", ret_val);
>
> - /* remove pci devices at first */
> - ret_val = acpi_bus_trim(device, 0);
> - printk(KERN_DEBUG "acpi_bus_trim stop return %x\n", ret_val);
> -
> - /* remove acpi devices */
> - ret_val = acpi_bus_trim(device, 1);
> - printk(KERN_DEBUG "acpi_bus_trim remove return %x\n", ret_val);
> - }
> + /* remove acpi devices */
> + ret_val = acpi_bus_trim(device, 1);
> + printk(KERN_DEBUG "acpi_bus_trim remove return %x\n", ret_val);
>
> if (flags & ROOT_BRIDGE_HAS_PS3) {
> acpi_status status;
> @@ -863,7 +799,7 @@ static void handle_root_bridge_removal(acpi_handle handle,
>
> static void _handle_hotplug_event_root(struct work_struct *work)
> {
> - struct acpi_root_bridge *bridge;
> + struct acpi_pci_root *root;
> char objname[64];
>
Re: [PATCH v8 15/22] ACPI, PCI: Simplify handle_root_bridge_removal()
On Friday, January 11, 2013 02:40:42 PM Yinghai Lu wrote:
> Tang Chen found handle_root_bridge_removal is very similiar to
> acpi_bus_hot_remove_device().
> Only difference is that it call trim two times.
>
> Change to handle_root_bridge_removal to call trim one time and then
> use acpi_bus_hot_remove_device.
Please fold these changes into your previous patches instead of adding a new
one to modify them.
Thanks,
Rafael
> Signed-off-by: Yinghai Lu
> ---
> drivers/acpi/pci_root.c | 49
> ---
> 1 file changed, 8 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 697ec65..8a0e2e2 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -745,56 +745,23 @@ static void handle_root_bridge_insertion(acpi_handle
> handle)
> printk(KERN_ERR "cannot add bridge to acpi list\n");
> }
>
> -static int acpi_root_evaluate_object(acpi_handle handle, char *cmd, int val)
> -{
> - acpi_status status;
> - struct acpi_object_list arg_list;
> - union acpi_object arg;
> -
> - arg_list.count = 1;
> - arg_list.pointer =
> - arg.type = ACPI_TYPE_INTEGER;
> - arg.integer.value = val;
> -
> - status = acpi_evaluate_object(handle, cmd, _list, NULL);
> - if (ACPI_FAILURE(status)) {
> - pr_warn("%s: %s to %d failed\n",
> - __func__, cmd, val);
> - return -1;
> - }
> -
> - return 0;
> -}
> -
> static void handle_root_bridge_removal(struct acpi_device *device)
> {
> int ret_val;
> - u32 flags = 0;
> - acpi_handle dummy_handle;
> - acpi_handle handle = device->handle;
> + struct acpi_eject_event *ej_event;
> +
> + ej_event = kmalloc(sizeof(*ej_event), GFP_KERNEL);
> + if (!ej_event)
> + return;
>
> - if (ACPI_SUCCESS(acpi_get_handle(handle, "_EJ0", _handle)))
> - flags |= ROOT_BRIDGE_HAS_EJ0;
> - if (ACPI_SUCCESS(acpi_get_handle(handle, "_PS3", _handle)))
> - flags |= ROOT_BRIDGE_HAS_PS3;
> + ej_event->device = device;
> + ej_event->event = ACPI_NOTIFY_EJECT_REQUEST;
>
> /* remove pci devices at first */
> ret_val = acpi_bus_trim(device, 0);
> printk(KERN_DEBUG "acpi_bus_trim stop return %x\n", ret_val);
>
> - /* remove acpi devices */
> - ret_val = acpi_bus_trim(device, 1);
> - printk(KERN_DEBUG "acpi_bus_trim remove return %x\n", ret_val);
> -
> - if (flags & ROOT_BRIDGE_HAS_PS3) {
> - acpi_status status;
> -
> - status = acpi_evaluate_object(handle, "_PS3", NULL, NULL);
> - if (ACPI_FAILURE(status))
> - pr_warn("%s: _PS3 failed\n", __func__);
> - }
> - if (flags & ROOT_BRIDGE_HAS_EJ0)
> - acpi_root_evaluate_object(handle, "_EJ0", 1);
> + acpi_bus_hot_remove_device(ej_event);
> }
>
> static void _handle_hotplug_event_root(struct work_struct *work)
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 14/22] ACPI: update ej_event interface to take acpi_device
On Friday, January 11, 2013 02:40:41 PM Yinghai Lu wrote:
> Should use acpi_device pointer directly instead of use handle and
> get the device pointer again later.
Looks good.
I can take this one right now if you want.
Thanks,
Rafael
> Signed-off-by: Yinghai Lu
> ---
> drivers/acpi/acpi_memhotplug.c |2 +-
> drivers/acpi/processor_driver.c |2 +-
> drivers/acpi/scan.c | 14 --
> include/acpi/acpi_bus.h |2 +-
> 4 files changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index 327ab44..eaddb7a 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -361,7 +361,7 @@ static void acpi_memory_device_notify(acpi_handle handle,
> u32 event, void *data)
> break;
> }
>
> - ej_event->handle = handle;
> + ej_event->device = device;
> ej_event->event = ACPI_NOTIFY_EJECT_REQUEST;
> acpi_os_hotplug_execute(acpi_bus_hot_remove_device,
> (void *)ej_event);
> diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
> index 0777663..a24ee43 100644
> --- a/drivers/acpi/processor_driver.c
> +++ b/drivers/acpi/processor_driver.c
> @@ -733,7 +733,7 @@ static void acpi_processor_hotplug_notify(acpi_handle
> handle,
> break;
> }
>
> - ej_event->handle = handle;
> + ej_event->device = device;
> ej_event->event = ACPI_NOTIFY_EJECT_REQUEST;
> acpi_os_hotplug_execute(acpi_bus_hot_remove_device,
> (void *)ej_event);
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 8883539..f4c6305 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -116,20 +116,14 @@ static DEVICE_ATTR(modalias, 0444,
> acpi_device_modalias_show, NULL);
> void acpi_bus_hot_remove_device(void *context)
> {
> struct acpi_eject_event *ej_event = (struct acpi_eject_event *) context;
> - struct acpi_device *device;
> - acpi_handle handle = ej_event->handle;
> + struct acpi_device *device = ej_event->device;
> + acpi_handle handle = device->handle;
> acpi_handle temp;
> struct acpi_object_list arg_list;
> union acpi_object arg;
> acpi_status status = AE_OK;
> u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
>
> - if (acpi_bus_get_device(handle, ))
> - goto err_out;
> -
> - if (!device)
> - goto err_out;
> -
> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
> "Hot-removing device %s...\n", dev_name(>dev)));
>
> @@ -215,7 +209,7 @@ acpi_eject_store(struct device *d, struct
> device_attribute *attr,
> goto err;
> }
>
> - ej_event->handle = acpi_device->handle;
> + ej_event->device = acpi_device;
> if (acpi_device->flags.eject_pending) {
> /* event originated from ACPI eject notification */
> ej_event->event = ACPI_NOTIFY_EJECT_REQUEST;
> @@ -223,7 +217,7 @@ acpi_eject_store(struct device *d, struct
> device_attribute *attr,
> } else {
> /* event originated from user */
> ej_event->event = ACPI_OST_EC_OSPM_EJECT;
> - (void) acpi_evaluate_hotplug_ost(ej_event->handle,
> + (void) acpi_evaluate_hotplug_ost(acpi_device->handle,
> ej_event->event, ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
> }
>
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 2246ba9..181ff2d 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -309,7 +309,7 @@ struct acpi_bus_event {
> };
>
> struct acpi_eject_event {
> - acpi_handle handle;
> + struct acpi_device *device;
> u32 event;
> };
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 12/22] PCI, ACPI: debug print for installation of acpi root bridge's notifier
On Friday, January 11, 2013 02:40:39 PM Yinghai Lu wrote:
> From: Tang Chen
>
> acpi_install_notify_handler() could fail. So check the exit status
> and give a better debug info.
>
> Signed-off-by: Tang Chen
> Signed-off-by: Yinghai Lu
> ---
> drivers/acpi/pci_root.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index d30fb94..862abcc 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -943,6 +943,7 @@ static bool acpi_is_root_bridge_object(acpi_handle handle)
> static acpi_status __init
> find_root_bridges(acpi_handle handle, u32 lvl, void *context, void **rv)
> {
> + acpi_status status;
> char objname[64];
> struct acpi_buffer buffer = { .length = sizeof(objname),
> .pointer = objname };
> @@ -955,9 +956,14 @@ find_root_bridges(acpi_handle handle, u32 lvl, void
> *context, void **rv)
>
> acpi_get_name(handle, ACPI_FULL_PATHNAME, );
>
> - acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
> - handle_hotplug_event_root, NULL);
> - printk(KERN_DEBUG "acpi root: %s notify handler installed\n", objname);
> + status = acpi_install_notify_handler(handle, ACPI_SYSTEM_NOTIFY,
> + handle_hotplug_event_root, NULL);
> + if (ACPI_FAILURE(status))
> + printk(KERN_DEBUG "acpi root: %s notify handler is not
> installed, exit status: %u\n",
> + objname, (unsigned int)status);
If we print a message on failure, I don't think we need one on success.
Besides, please use pr_debug().
> + else
> + printk(KERN_DEBUG "acpi root: %s notify handler is installed\n",
> + objname);
>
> add_acpi_root_bridge(handle);
And I wonder what sens does this make to call add_acpi_root_bridge() here if we
haven't installed the notify handler for handle?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 11/22] PCI: correctly detect ACPI PCI host bridge objects
On Friday, January 11, 2013 02:40:38 PM Yinghai Lu wrote:
> From: Jiang Liu
>
> The code in pci_root_hp.c depends on function acpi_is_root_bridge()
> to check whether an ACPI object is a PCI host bridge or not.
> If an ACPI device hasn't been created for the ACPI object yet,
> function acpi_is_root_bridge() will return false even if the object
> is a PCI host bridge object. That behavior will cause two issues:
> 1) No ACPI notification handler installed for PCI host bridges absent
>at startup, so hotplug events for those bridges won't be handled.
> 2) rescan_root_bridge() can't reenumerate offlined PCI host bridges
>because the ACPI devices have been already destroyed.
>
> So use acpi_match_object_info_ids() to correctly detect PCI host bridges.
>
> -v2: update to use acpi_match_object_info_ids() from Tang Chen - Yinghai
> -v3: drop the PNP0A008, according to Bjorn.
>
> Signed-off-by: Jiang Liu
> Signed-off-by: Yinghai Lu
> Cc: Len Brown
> Cc: linux-a...@vger.kernel.org
> ---
> drivers/acpi/pci_root.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 5ae36d8..d30fb94 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -923,6 +923,23 @@ static void handle_hotplug_event_root(acpi_handle
> handle, u32 type,
> _handle_hotplug_event_root);
> }
>
> +static bool acpi_is_root_bridge_object(acpi_handle handle)
> +{
> + struct acpi_device_info *info = NULL;
> + acpi_status status;
> + bool ret;
> +
> + status = acpi_get_object_info(handle, );
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + ret = !acpi_match_object_info_ids(info, root_device_ids);
> +
Well, I kind of don't understand why don't we check info->flags
against ACPI_PCI_ROOT_BRIDGE that acpi_get_object_info() sets for us if it
finds a PCI root bridge?
> + kfree(info);
> +
> + return ret;
> +}
> +
> static acpi_status __init
> find_root_bridges(acpi_handle handle, u32 lvl, void *context, void **rv)
> {
> @@ -931,7 +948,7 @@ find_root_bridges(acpi_handle handle, u32 lvl, void
> *context, void **rv)
> .pointer = objname };
> int *count = (int *)context;
>
> - if (!acpi_is_root_bridge(handle))
> + if (!acpi_is_root_bridge_object(handle))
> return AE_OK;
>
> (*count)++;
>
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 10/22] ACPI: Introduce a new acpi handle to determine HID match.
On Friday, January 11, 2013 02:40:37 PM Yinghai Lu wrote:
> From: Tang Chen
>
> We need to find out if one handle is for root bridge, and install notify
> handler for it to handle pci root bus hot add.
> At that time, root bridge acpi device is not created yet.
>
> So acpi_match_device_ids() will not work.
>
> This patch add a function to check if new acpi handle's HID matches a list
> of IDs. The new api use acpi_device_info instead acpi_device.
>
> -v2: updated changelog, also check length for string info...
> change checking sequence by moving string comaring close to for loop.
> - Yinghai
> -v3: change to _GPL according to Rafael
Please fold this into [11/22]. Otherwise one has to look at these two patches
at the same time to understand how the code is supposed to work, which is less
than useful.
Thanks,
Rafael
> Signed-off-by: Tang Chen
> Signed-off-by: Yinghai Lu
> Cc: Len Brown
> Cc: linux-a...@vger.kernel.org
> ---
> drivers/acpi/scan.c | 33 +
> include/acpi/acpi_bus.h |2 ++
> 2 files changed, 35 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index db7664e..8883539 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -470,6 +470,39 @@ int acpi_match_device_ids(struct acpi_device *device,
> }
> EXPORT_SYMBOL(acpi_match_device_ids);
>
> +int acpi_match_object_info_ids(struct acpi_device_info *info,
> +const struct acpi_device_id *ids)
> +{
> + const struct acpi_device_id *id;
> + char *str;
> + u32 len;
> + int i;
> +
> + len = info->hardware_id.length;
> + if (len) {
> + str = info->hardware_id.string;
> + if (str)
> + for (id = ids; id->id[0]; id++)
> + if (!strcmp((char *)id->id, str))
> + return 0;
> + }
> +
> + for (i = 0; i < info->compatible_id_list.count; i++) {
> + len = info->compatible_id_list.ids[i].length;
> + if (!len)
> + continue;
> + str = info->compatible_id_list.ids[i].string;
> + if (!str)
> + continue;
> + for (id = ids; id->id[0]; id++)
> + if (!strcmp((char *)id->id, str))
> + return 0;
> + }
> +
> + return -ENOENT;
> +}
> +EXPORT_SYMBOL_GPL(acpi_match_object_info_ids);
> +
> static void acpi_free_ids(struct acpi_device *device)
> {
> struct acpi_hardware_id *id, *tmp;
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index a9e1421..2246ba9 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -355,6 +355,8 @@ int acpi_bus_trim(struct acpi_device *start, int
> rmdevice);
> acpi_status acpi_bus_get_ejd(acpi_handle handle, acpi_handle * ejd);
> int acpi_match_device_ids(struct acpi_device *device,
> const struct acpi_device_id *ids);
> +int acpi_match_object_info_ids(struct acpi_device_info *info,
> +const struct acpi_device_id *ids);
> int acpi_create_dir(struct acpi_device *);
> void acpi_remove_dir(struct acpi_device *);
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 09/22] PCI, ACPI: Add pci_root_hp hot removal notification support.
On Friday, January 11, 2013 02:40:36 PM Yinghai Lu wrote:
> Add missing hot_remove support for root device.
>
> How to test it?
> Find out root bus number to acpi root name mapping from dmesg or /sys
>
> echo "\_SB.PCIB 3" > /sys/kernel/debug/acpi/sci_notify
> to remove root bus
>
> -v2: separate stop and remove, so it will be safe for comingi
> acpi_pci_bind_notify() changes.
>
> Signed-off-by: Yinghai Lu
> Cc: Len Brown
> Cc: linux-a...@vger.kernel.org
> ---
> drivers/acpi/pci_root.c | 67
> +++
> 1 file changed, 67 insertions(+)
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 5c1f462c..5ae36d8 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -740,6 +740,12 @@ static void add_acpi_root_bridge(acpi_handle handle)
> list_add(>list, _root_bridge_list);
> }
>
> +static void remove_acpi_root_bridge(struct acpi_root_bridge *bridge)
> +{
> + list_del(>list);
> + kfree(bridge);
> +}
> +
> struct acpi_root_hp_work {
> struct work_struct work;
> acpi_handle handle;
> @@ -800,6 +806,61 @@ static void handle_root_bridge_insertion(acpi_handle
> handle)
> printk(KERN_ERR "cannot add bridge to acpi list\n");
> }
>
> +static int acpi_root_evaluate_object(acpi_handle handle, char *cmd, int val)
> +{
> + acpi_status status;
> + struct acpi_object_list arg_list;
> + union acpi_object arg;
> +
> + arg_list.count = 1;
> + arg_list.pointer =
> + arg.type = ACPI_TYPE_INTEGER;
> + arg.integer.value = val;
> +
> + status = acpi_evaluate_object(handle, cmd, _list, NULL);
> + if (ACPI_FAILURE(status)) {
> + pr_warn("%s: %s to %d failed\n",
> + __func__, cmd, val);
> + return -1;
Please use a meaningful error code.
> + }
> +
> + return 0;
> +}
> +
> +static void handle_root_bridge_removal(acpi_handle handle,
> + struct acpi_root_bridge *bridge)
> +{
> + u32 flags = 0;
> + struct acpi_device *device;
> +
> + if (bridge) {
> + flags = bridge->flags;
> + remove_acpi_root_bridge(bridge);
> + }
> +
> + if (!acpi_bus_get_device(handle, )) {
> + int ret_val;
> +
> + /* remove pci devices at first */
> + ret_val = acpi_bus_trim(device, 0);
> + printk(KERN_DEBUG "acpi_bus_trim stop return %x\n", ret_val);
> +
> + /* remove acpi devices */
> + ret_val = acpi_bus_trim(device, 1);
> + printk(KERN_DEBUG "acpi_bus_trim remove return %x\n", ret_val);
First of all, I don't agree with the way acpi_bus_trim() is used here, as
I said in the previous message.
Second, this code duplicates the code you're adding on [08/22] almost exactly.
Please put it into a one separate function instead of duplicating it like this.
> + }
> +
> + if (flags & ROOT_BRIDGE_HAS_PS3) {
> + acpi_status status;
> +
> + status = acpi_evaluate_object(handle, "_PS3", NULL, NULL);
> + if (ACPI_FAILURE(status))
> + pr_warn("%s: _PS3 failed\n", __func__);
No, please. acpi_device_set_power() is for that.
> + }
> + if (flags & ROOT_BRIDGE_HAS_EJ0)
> + acpi_root_evaluate_object(handle, "_EJ0", 1);
That seems to duplicate some code from scan.c.
> +}
> +
> static void _handle_hotplug_event_root(struct work_struct *work)
> {
> struct acpi_root_bridge *bridge;
> @@ -840,6 +901,12 @@ static void _handle_hotplug_event_root(struct
> work_struct *work)
> }
> break;
>
> + case ACPI_NOTIFY_EJECT_REQUEST:
> + /* request device eject */
> + printk(KERN_DEBUG "%s: Device eject notify on %s\n", __func__,
> + objname);
> + handle_root_bridge_removal(handle, bridge);
> + break;
> default:
> printk(KERN_WARNING "notify_handler: unknown event type 0x%x
> for %s\n",
>type, objname);
>
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 08/22] PCI, acpiphp: Separate out hot-add support of pci host bridge
On Friday, January 11, 2013 02:40:35 PM Yinghai Lu wrote:
> It causes confusion.
>
> We may only need acpi hp for pci host bridge.
What does this mean?
> Split host bridge hot-add support to pci_root_hp, and keep acpiphp simple.
s/Split/Move/ I suppose?
In any case that's not telling the whole story, because the patch doesn't just
move code from one file to another.
> -v2: put back pci_root_hp change in one patch
> -v3: add pcibios_resource_survey_bus() calling
> -v4: remove not needed code with remove_bridge
> -v5: put back support for acpiphp support for slots just on root bus.
> -v6: change some functions to *_p2p_* to make it more clean.
> -v7: split hot_added change out.
> -v8: Move to pci_root.c instead of adding another file requested by Bjorn.
>
> Signed-off-by: Yinghai Lu
> ---
> drivers/acpi/pci_root.c| 220
>
> drivers/pci/hotplug/acpiphp_glue.c | 59 +++---
> 2 files changed, 235 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 471b2dc..5c1f462c 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -673,3 +673,223 @@ int __init acpi_pci_root_init(void)
>
> return 0;
> }
> +
> +/*
> + * Separated from drivers/pci/hotplug/acpiphp_glue.c
> + * only support root bridge
> + */
This comment will be useless after applying the patch.
> +
> +static LIST_HEAD(acpi_root_bridge_list);
> +struct acpi_root_bridge {
> + struct list_head list;
> + acpi_handle handle;
> + u32 flags;
> +};
We have struct acpi_pci_root already. Why do we need this in addition?
Also, we have acpi_pci_roots, so why do we need another list of root bridges?
> +
> +/* bridge flags */
> +#define ROOT_BRIDGE_HAS_EJ0 (0x0002)
> +#define ROOT_BRIDGE_HAS_PS3 (0x0080)
What is that needed for?
> +
> +#define ACPI_STA_FUNCTIONING (0x0008)
> +
> +static struct acpi_root_bridge *acpi_root_handle_to_bridge(acpi_handle
> handle)
> +{
> + struct acpi_root_bridge *bridge;
> +
> + list_for_each_entry(bridge, _root_bridge_list, list)
> + if (bridge->handle == handle)
> + return bridge;
> +
> + return NULL;
> +}
> +
> +/* allocate and initialize host bridge data structure */
> +static void add_acpi_root_bridge(acpi_handle handle)
> +{
> + struct acpi_root_bridge *bridge;
> + acpi_handle dummy_handle;
> + acpi_status status;
> +
Why do we need to evaluate all of the methods directly here?
Don't we have a struct acpi_device for handle already?
> + /* if the bridge doesn't have _STA, we assume it is always there */
> + status = acpi_get_handle(handle, "_STA", _handle);
> + if (ACPI_SUCCESS(status)) {
> + unsigned long long tmp;
> +
> + status = acpi_evaluate_integer(handle, "_STA", NULL, );
> + if (ACPI_FAILURE(status)) {
> + printk(KERN_DEBUG "%s: _STA evaluation failure\n",
> + __func__);
> + return;
> + }
> + if ((tmp & ACPI_STA_FUNCTIONING) == 0)
> + /* don't register this object */
> + return;
> + }
> +
> + bridge = kzalloc(sizeof(struct acpi_root_bridge), GFP_KERNEL);
> + if (!bridge)
> + return;
> +
> + bridge->handle = handle;
> +
> + if (ACPI_SUCCESS(acpi_get_handle(handle, "_EJ0", _handle)))
> + bridge->flags |= ROOT_BRIDGE_HAS_EJ0;
> + if (ACPI_SUCCESS(acpi_get_handle(handle, "_PS3", _handle)))
> + bridge->flags |= ROOT_BRIDGE_HAS_PS3;
All of this attempts to duplicate the scanning code from scan.c in a very
incomplete and questionable way.
For example, what if the root bridge has _PR0?
> +
> + list_add(>list, _root_bridge_list);
> +}
> +
> +struct acpi_root_hp_work {
> + struct work_struct work;
> + acpi_handle handle;
> + u32 type;
> + void *context;
> +};
> +
> +static void alloc_acpi_root_hp_work(acpi_handle handle, u32 type,
> + void *context,
> + void (*func)(struct work_struct *work))
> +{
> + struct acpi_root_hp_work *hp_work;
> + int ret;
> +
> + hp_work = kmalloc(sizeof(*hp_work), GFP_KERNEL);
> + if (!hp_work)
> + return;
> +
> + hp_work->handle = handle;
> + hp_work->type = type;
> + hp_work->context = context;
> +
> + INIT_WORK(_work->work, func);
> + ret = queue_work(kacpi_hotplug_wq, _work->work);
> + if (!ret)
> + kfree(hp_work);
> +}
The function above is called only once and used by __init stuff only.
Why don't we move it to the caller and mark that caller as __init too?
> +
> +static void handle_root_bridge_insertion(acpi_handle handle)
> +{
> + struct acpi_device *device, *pdevice;
> + acpi_handle phandle;
> + int ret_val;
> +
> +
Re: [PATCH] linux-firmware: add MISSING file
On Sat, Jan 12, 2013 at 11:39 PM, Xose Vazquez Perez wrote: > to document the reason why a firmware is not present > > Cc: Daniel Drake > Cc: Ulrich Kunitz > Cc: David Woodhouse > Cc: Ben Hutchings > Cc: > Cc: > Signed-off-by: Xose Vazquez Perez > --- > MISSING | 20 > 1 file changed, 20 insertions(+) > create mode 100644 MISSING > > diff --git a/MISSING b/MISSING > new file mode 100644 > index 000..f228099 > --- /dev/null > +++ b/MISSING > @@ -0,0 +1,20 @@ > + *** > + * MISSING * > + *** > + > +This file attempts to document the reason why a firmware is not present > +in this bundle. >From the user's point of view this not really helpful. Wouldn't a in-kernel table of known but missing firmware files make more sense? The kernel could write a log like "Yeah, I know this firmware but sadly I don't have it because of ..." -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Sat, 12 Jan 2013, Alex Riesen wrote: > On Sat, Jan 12, 2013 at 8:39 PM, Alex Riesen wrote: > > On Sat, Jan 12, 2013 at 6:37 PM, Alan Stern > > wrote: > >> On Sat, 12 Jan 2013, Alex Riesen wrote: > >>> One more detail: I usually use the "noop" elevator. That time it was > >>> the "deadline". And I just reproduced it easily with "deadline". > >> > >> I doubt the elevator has anything to do with this. > > > > But it looks like it does: just using the deadline elevator is a sure way > > to reproduce the bug. The system always recovers (sometimes after a while) > > with "noop". > > And no, it does not. Not by itself, but the fact that deadline elevator was > compiled as module certainly helped! > > This explains the hanging modprobe in the dmesg output (the part after device > connect). I still wonder, why didn't it froze at boot, mounting SATA devices > (the root, /var, and /home are on an SSD connected by SATA)? And why hanging > khubd at reboot? > > Anyway, building the elevator in the kernel avoids the problem. Sorry for > not spotting this earlier. > > Now, who would be interested to handle this kind of misconfiguration ... So the whole thing was a false alarm? Maybe you should report to the block-layer maintainers that it's possible to mess up the system by building an elevator as a module. That sounds like the sort of thing they'd be interested to hear. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 3.8 broken for MacBookAir5,1
Hello, Today I tried to update my kernel from 3.7.2 to 3.8-rc3 and I had no success; I used localmodconfig to generate the .config for my machine but keyboard does not work. Using same generated .config with 3.7.2 works fine. Anyone has a clue about? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] linux-firmware: add MISSING file
to document the reason why a firmware is not present Cc: Daniel Drake Cc: Ulrich Kunitz Cc: David Woodhouse Cc: Ben Hutchings Cc: Cc: Signed-off-by: Xose Vazquez Perez --- MISSING | 20 1 file changed, 20 insertions(+) create mode 100644 MISSING diff --git a/MISSING b/MISSING new file mode 100644 index 000..f228099 --- /dev/null +++ b/MISSING @@ -0,0 +1,20 @@ + *** + * MISSING * + *** + +This file attempts to document the reason why a firmware is not present +in this bundle. + +-- + +Driver: zd1211rw -- ZyDAS/Atheros ZD1211/ZD1211B/AR5007UG wireless driver + +Trouble: Allegedly GPLv2, but no source visible. Found in hex form in the + vendor driver. + +URL: http://sf.net/projects/zd1211/files/ + +Implication: CRITICAL, hardware undetected. + +-- + -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Dove: move CuBox led pinctrl to gpio-leds node
On Thu, Dec 27, 2012 at 11:21:10PM +0100, Sebastian Hesselbarth wrote: > gpio-leds has support for pinctrl allocation, make use of it. > > Signed-off-by: Sebastian Hesselbarth > --- > Cc: Russell King > Cc: Jason Cooper > Cc: Andrew Lunn > Cc: Sebastian Hesselbarth > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > arch/arm/boot/dts/dove-cubox.dts |5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Applied to mvebu/dt thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Dove: add fixed regulator for CuBox USB power
On Thu, Dec 27, 2012 at 11:21:59PM +0100, Sebastian Hesselbarth wrote: > CuBox needs to enable USB power on a gpio pin. Add a fixed regulator > to always enable usb power on boot. > > Signed-off-by: Sebastian Hesselbarth > --- > Cc: Russell King > Cc: Jason Cooper > Cc: Andrew Lunn > Cc: Sebastian Hesselbarth > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > arch/arm/boot/dts/dove-cubox.dts | 25 - > arch/arm/mach-dove/Kconfig |2 ++ > 2 files changed, 26 insertions(+), 1 deletion(-) Applied to mvebu/dt thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 07/22] ACPI: Separate acpi_bus_trim to support two steps.
On Friday, January 11, 2013 02:40:34 PM Yinghai Lu wrote: > Current all acpi_bus_trim callers have rmdevice to 1. > that means it will remove all acpi devices. > > When 0, is passed, it will keep the parent. > > For root bus hotremove support, we need to have pci device to be > removed before acpi devices. > > So try to keep all acpi devices, and only stop drivers with them. > > This change should be safe because all current callers all have 1 passed. I'm not sure how the chanelog is related to the patch itself. The patch modifies the behavior of acpi_bus_trim() to avoid removing all devices (not just the start point) for rmdevice==0, which doesn't really change the functionality, because all callers pass rmdevice=1 anyway. Yes, we can make this change, but why is it necessary? And why don't we remove the rmdevice argument from acpi_bus_trim() altogether? Rafael > Signed-off-by: Yinghai Lu > Cc: Len Brown > Cc: linux-a...@vger.kernel.org > --- > drivers/acpi/scan.c |5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c > index e380345..db7664e 100644 > --- a/drivers/acpi/scan.c > +++ b/drivers/acpi/scan.c > @@ -1669,10 +1669,7 @@ int acpi_bus_trim(struct acpi_device *start, int > rmdevice) > child = parent; > parent = parent->parent; > > - if (level == 0) > - err = acpi_bus_remove(child, rmdevice); > - else > - err = acpi_bus_remove(child, 1); > + err = acpi_bus_remove(child, rmdevice); > > continue; > } > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MODSIGN: Modules fail signature verification with -ENOKEY
/* Please CC, not on LKML */ On 13/01/13 00:08, Josh Boyer wrote: On Sat, Jan 12, 2013 at 1:28 AM, Chris Samuel wrote: > >> [...Debian kernel-build...] I'll file a bug against it asking for the it to not strip if CONFIG_MODULE_SIG is set. Thanks for the pointer! Great. Glad you figured it out. It raises a question - if we have CONFIG_MODULE_SIG should we disable stripping modules in the top level Makefile as it's going to break things? The parsing for CONFIG_MODULE_SIG happens right after that for INSTALL_MOD_STRIP so the stripping could be disabled with with: mod_strip_cmd = true export strip_cmd cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Dove: move CuBox led pinctrl to gpio-leds node
On Sat, Jan 12, 2013 at 10:51:35PM +0100, Sebastian Hesselbarth wrote:
> On 01/12/2013 10:42 PM, Jason Cooper wrote:
> >On Thu, Dec 27, 2012 at 11:21:10PM +0100, Sebastian Hesselbarth wrote:
> >>gpio-leds has support for pinctrl allocation, make use of it.
> >>
> >>Signed-off-by: Sebastian Hesselbarth
> >> ...
> >> {
> >>- pinctrl-0 =<_gpio_12_gpio_18>;
> >>+ pinctrl-0 =<_gpio_12>;
> >>pinctrl-names = "default";
> >>
> >>pmx_gpio_12: pmx-gpio-12 {
> >>--
> >>1.7.10.4
> >
> >I'm getting a merge conflict wit hthe above:
> >
> > {
> ><<< HEAD
> > pinctrl-0 =<_gpio_18>;
> >===
> > pinctrl-0 =<_gpio_12>;
> ARM: Dove: move CuBox led pinctrl to gpio-leds node
> > pinctrl-names = "default";
> >
> > pmx_gpio_18: pmx-gpio-18 {
> > marvell,pins = "mpp18";
> > marvell,function = "gpio";
> > };
> >};
> >
> >Am I missing something?
>
> Jason,
>
> it depends on "ARM: Dove: move CuBox led pinctrl to gpio-leds node"
> that you applied to mvebu/fixes two days ago.
Ahhh, ok, I'll include it in this pull.
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 06/22] PCI: split registration of PCI bus devices into two stages
On Friday, January 11, 2013 02:40:33 PM Yinghai Lu wrote:
> From: Jiang Liu
>
> When handling BUS_NOTIFY_ADD_DEVICE event for a PCI bridge device,
> the notification handler can't hold reference count to the new PCI bus
> because the device object for the new bus (pci_dev->subordinate->dev)
> hasn't been initialized yet.
It doesn't look like BUS_NOTIFY_ADD_DEVICE is used by the PCI bus type
in the mainline.
Is it in linux-next?
If not, then I don't see why we need this patch.
Thanks,
Rafael
> Split the registration of PCI bus device into two stages as below,
> so that the event handler could hold reference count to the new PCI bus
> when handling BUS_NOTIFY_ADD_DEVICE event.
>
> 1) device_initialize(_dev->dev)
> 2) device_initialize(_dev->subordinate->dev)
> 3) notify BUS_NOTIFY_ADD_DEVICE event for pci_dev
> 4) device_add(_dev->dev)
> 5) device_add(_dev->subordinate->dev)
>
> Signed-off-by: Jiang Liu
> Signed-off-by: Yinghai Lu
> ---
> drivers/pci/bus.c|2 +-
> drivers/pci/probe.c |4 +++-
> drivers/pci/remove.c | 10 +-
> 3 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
> index 847f3ca..5f9c728 100644
> --- a/drivers/pci/bus.c
> +++ b/drivers/pci/bus.c
> @@ -200,7 +200,7 @@ int pci_bus_add_child(struct pci_bus *bus)
> if (bus->bridge)
> bus->dev.parent = bus->bridge;
>
> - retval = device_register(>dev);
> + retval = device_add(>dev);
> if (retval)
> return retval;
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 48b35e1..dc4fde3 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -642,6 +642,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus
> *parent,
>*/
> child->dev.class = _class;
> dev_set_name(>dev, "%04x:%02x", pci_domain_nr(child), busnr);
> + device_initialize(>dev);
>
> /*
>* Set up the primary, secondary and subordinate
> @@ -1678,7 +1679,8 @@ struct pci_bus *pci_create_root_bus(struct device
> *parent, int bus,
> b->dev.class = _class;
> b->dev.parent = b->bridge;
> dev_set_name(>dev, "%04x:%02x", pci_domain_nr(b), bus);
> - error = device_register(>dev);
> + device_initialize(>dev);
> + error = device_add(>dev);
> if (error)
> goto class_dev_reg_err;
>
> diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
> index fc38c48..a1fdd0f 100644
> --- a/drivers/pci/remove.c
> +++ b/drivers/pci/remove.c
> @@ -48,11 +48,11 @@ void pci_remove_bus(struct pci_bus *bus)
> list_del(>node);
> pci_bus_release_busn_res(bus);
> up_write(_bus_sem);
> - if (!bus->is_added)
> - return;
> -
> - pci_remove_legacy_files(bus);
> - device_unregister(>dev);
> + if (bus->is_added) {
> + pci_remove_legacy_files(bus);
> + device_del(>dev);
> + }
> + put_device(>dev);
> }
> EXPORT_SYMBOL(pci_remove_bus);
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fb: udlfb: fix hang at disconnect
Hi Alexander, On Sat, Jan 12, 2013 at 5:20 AM, Alexander Holler wrote: > When a device was disconnected the driver may hang at waiting for urbs it > never > will get. Fix this by using a timeout while waiting for the used semaphore. The code used to be this way, but it used to cause nasty shutdown hangs: http://git.plugable.com/gitphp/index.php?p=udlfb=commitdiff=1dd39a65001deb5a84088dfabb788d3274fbb6b6 Which is why the code is the way it is today. Can you say under what situations you're hitting hangs on device disconnect? Have you tested extensively to confirm no shutdown hangs with your patch? Stepping back, there was another recent patch from the community to udlfb to work around issues of sleeping in the wrong context. The fix involved introducing another scheduled workitem. This slows everything down when it's in the main path, and isn't really desirable if we can avoid it. Another option to eliminate all these problems -- long considered but never implemented -- is to get rid of all semaphores and potential sleeps in udlfb entirely. That would require a strategy to throttle rendering in some way other than by waiting in kernel (without some throttling strategy, the USB bus can be a bottleneck which can flood the system with rendered but untransmitted pixels). Options might be: 1) When transfer buffers are full, keep track of dirty rectangles for the rest and pick up where we left off the next time we're entered (avoiding flooding by potentially having pixels in the dirty regions be written over multiple times before we get to rendering them once) 2 ) If we "bet" on page-fault-based defio dirty pixel detection, we could allocate buffers dynamically but increase the scheduling time to transfer as our outstanding buffer count grows, and reduce the latency only when the buffer count goes down (again, pixels will be potentially rendered many times before being transfered once, avoiding flooding). Any other ideas on the specific or general case are welcome. Also note that udlfb is being largely superceeded by the udl DRM driver - so any decisions here should also be considered in that codebase. In any case, thanks for giving the DisplayLink USB 2.0 graphics drivers attention - it's much appreciated! Bernie Thompson http://plugable.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7u1 08/31] x86, 64bit: early #PF handler set page table
On 01/10/2013 12:27 PM, Borislav Petkov wrote: So at that time how can the Signed-off from them? And there are commits in the upstream does not have Signed-off from the Author. I certainly hope those are a very very small number, if any. There are indeed a handful, at which point the first Signed-off-by: indicates that he, *based on his own first-hand knowledge* knows the author is intending and allowed to release this patch under the appropriate licensing term (see the Developer's Certificate of Origin document for the exact details.) -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] NULL pointer dereference in udf_sb_free_partitions
Hi, I've encountered a reproducable kernel bug which makes the screen switch to a console and display the kernel log below. This is what I did: * Insert a particular DVD-R I have which appears to be corrupt. It then makes the DVD drive make some unpleasant noises (my TV also makes unpleasant noises when it's inserted). * I go to mount it in KDE, it continues making noises and outputs some of the errors in the kernel log below (things like Mechanical positioning error, which makes sense since it's making unusual noises).. * After a while it says the mount failed. * After a while I typed the eject command, and pressed eject button * After a while longer the DVD is eventually ejected and at that point the kernel log is displayed on screen. * I can use VT switch to get back to desktop. i tried running sync as I wanted the log to be saved, but it never returned, although most other things seemed to continue working. Rebooted fine. First observed on v3.7 vanilla kernel (tried twice, happened both times), now running v3.8-rc3 and it happened when I tried it again. I haven't tried debugging it any further, but am happy to provide more info as required or test patches. Cheers James (told it to mount) [ 1300.219641] sr 8:0:0:0: [sr0] Unhandled sense code [ 1300.219652] sr 8:0:0:0: [sr0] [ 1300.219658] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 1300.219664] sr 8:0:0:0: [sr0] [ 1300.219668] Sense Key : Hardware Error [current] [ 1300.219675] Info fld=0x119368 [ 1300.219680] sr 8:0:0:0: [sr0] [ 1300.219686] Add. Sense: Mechanical positioning error [ 1300.219692] sr 8:0:0:0: [sr0] CDB: [ 1300.219695] Read(10): 28 00 00 11 93 68 00 00 01 00 [ 1300.219711] end_request: I/O error, dev sr0, sector 4607392 [ 1300.219766] UDF-fs: error (device sr0): udf_read_tagged: read failed, block=1151848, location=1151576 [ 1300.219780] UDF-fs: error (device sr0): __udf_read_inode: (ino 1151848) failed !bh [ 1310.294257] sr 8:0:0:0: [sr0] Unhandled sense code [ 1310.294268] sr 8:0:0:0: [sr0] [ 1310.294274] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 1310.294279] sr 8:0:0:0: [sr0] [ 1310.294283] Sense Key : Hardware Error [current] [ 1310.294289] Info fld=0x119367 [ 1310.294294] sr 8:0:0:0: [sr0] [ 1310.294300] Add. Sense: Mechanical positioning error [ 1310.294305] sr 8:0:0:0: [sr0] CDB: [ 1310.294308] Read(10): 28 00 00 11 93 67 00 00 01 00 [ 1310.294324] end_request: I/O error, dev sr0, sector 4607388 [ 1310.294388] UDF-fs: error (device sr0): udf_read_tagged: read failed, block=1151847, location=1151575 [ 1310.294400] UDF-fs: error (device sr0): __udf_read_inode: (ino 1151847) failed !bh [ 1320.324070] sr 8:0:0:0: [sr0] Unhandled sense code [ 1320.324081] sr 8:0:0:0: [sr0] [ 1320.324087] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 1320.324093] sr 8:0:0:0: [sr0] [ 1320.324097] Sense Key : Hardware Error [current] [ 1320.324104] Info fld=0x119366 [ 1320.324109] sr 8:0:0:0: [sr0] [ 1320.324115] Add. Sense: Mechanical positioning error [ 1320.324121] sr 8:0:0:0: [sr0] CDB: [ 1320.324124] Read(10): 28 00 00 11 93 66 00 00 01 00 [ 1320.324140] end_request: I/O error, dev sr0, sector 4607384 [ 1320.324195] UDF-fs: error (device sr0): udf_read_tagged: read failed, block=1151846, location=1151574 [ 1320.324208] UDF-fs: error (device sr0): __udf_read_inode: (ino 1151846) failed !bh [ 1330.432689] sr 8:0:0:0: [sr0] Unhandled sense code [ 1330.432701] sr 8:0:0:0: [sr0] [ 1330.432706] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 1330.432712] sr 8:0:0:0: [sr0] [ 1330.432716] Sense Key : Hardware Error [current] [ 1330.432722] Info fld=0x119365 [ 1330.432728] sr 8:0:0:0: [sr0] [ 1330.432733] Add. Sense: Mechanical positioning error [ 1330.432739] sr 8:0:0:0: [sr0] CDB: [ 1330.432742] Read(10): 28 00 00 11 93 65 00 00 01 00 [ 1330.432758] end_request: I/O error, dev sr0, sector 4607380 [ 1330.432814] UDF-fs: error (device sr0): udf_read_tagged: read failed, block=1151845, location=1151573 [ 1330.432827] UDF-fs: error (device sr0): __udf_read_inode: (ino 1151845) failed !bh [ 1330.432842] UDF-fs: Failed to read VAT inode from the last recorded block (1151848), retrying with the last block of the device (2295103). [ 1340.483225] sr 8:0:0:0: [sr0] Unhandled sense code [ 1340.483237] sr 8:0:0:0: [sr0] [ 1340.483242] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 1340.483247] sr 8:0:0:0: [sr0] [ 1340.483251] Sense Key : Hardware Error [current] [ 1340.483257] Info fld=0x23053f [ 1340.483263] sr 8:0:0:0: [sr0] [ 1340.483268] Add. Sense: Mechanical positioning error [ 1340.483273] sr 8:0:0:0: [sr0] CDB: [ 1340.483276] Read(10): 28 00 00 23 05 3f 00 00 01 00 [ 1340.483292] end_request: I/O error, dev sr0, sector 9180412 [ 1340.483373] UDF-fs: error (device sr0): udf_read_tagged: read failed, block=2295103, location=2294831 [ 1340.483385] UDF-fs: error (device sr0): __udf_read_inode: (ino 2295103) failed !bh some point around here I tried to eject [
Re: [PATCH] ARM: Dove: move CuBox led pinctrl to gpio-leds node
On 01/12/2013 10:42 PM, Jason Cooper wrote:
On Thu, Dec 27, 2012 at 11:21:10PM +0100, Sebastian Hesselbarth wrote:
gpio-leds has support for pinctrl allocation, make use of it.
Signed-off-by: Sebastian Hesselbarth
...
{
- pinctrl-0 =<_gpio_12_gpio_18>;
+ pinctrl-0 =<_gpio_12>;
pinctrl-names = "default";
pmx_gpio_12: pmx-gpio-12 {
--
1.7.10.4
I'm getting a merge conflict wit hthe above:
{
<<< HEAD
pinctrl-0 =<_gpio_18>;
===
pinctrl-0 =<_gpio_12>;
ARM: Dove: move CuBox led pinctrl to gpio-leds node
pinctrl-names = "default";
pmx_gpio_18: pmx-gpio-18 {
marvell,pins = "mpp18";
marvell,function = "gpio";
};
};
Am I missing something?
Jason,
it depends on "ARM: Dove: move CuBox led pinctrl to gpio-leds node"
that you applied to mvebu/fixes two days ago.
You can postpone the patch another rc if that helps as it just moves
led pinctrl but still works when on pinctrl hog.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: Dove: move CuBox led pinctrl to gpio-leds node
Sebastian,
On Thu, Dec 27, 2012 at 11:21:10PM +0100, Sebastian Hesselbarth wrote:
> gpio-leds has support for pinctrl allocation, make use of it.
>
> Signed-off-by: Sebastian Hesselbarth
> ---
> Cc: Russell King
> Cc: Jason Cooper
> Cc: Andrew Lunn
> Cc: Sebastian Hesselbarth
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/boot/dts/dove-cubox.dts |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/dove-cubox.dts
> b/arch/arm/boot/dts/dove-cubox.dts
> index cdee96f..bed5b62 100644
> --- a/arch/arm/boot/dts/dove-cubox.dts
> +++ b/arch/arm/boot/dts/dove-cubox.dts
> @@ -17,6 +17,9 @@
>
> leds {
> compatible = "gpio-leds";
> + pinctrl-0 = <_gpio_18>;
> + pinctrl-names = "default";
> +
> power {
> label = "Power";
> gpios = < 18 1>;
> @@ -47,7 +50,7 @@
> };
>
> {
> - pinctrl-0 = <_gpio_12 _gpio_18>;
> + pinctrl-0 = <_gpio_12>;
> pinctrl-names = "default";
>
> pmx_gpio_12: pmx-gpio-12 {
> --
> 1.7.10.4
I'm getting a merge conflict wit hthe above:
{
<<< HEAD
pinctrl-0 = <_gpio_18>;
===
pinctrl-0 = <_gpio_12>;
>>> ARM: Dove: move CuBox led pinctrl to gpio-leds node
pinctrl-names = "default";
pmx_gpio_18: pmx-gpio-18 {
marvell,pins = "mpp18";
marvell,function = "gpio";
};
};
Am I missing something?
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 05/22] PCI: make PCI device create/destroy logic symmetric
On Friday, January 11, 2013 02:40:32 PM Yinghai Lu wrote:
> From: Jiang Liu
>
> According to device model documentation, the way to create/destroy PCI
> devices should be symmetric.
>
> /**
> * device_del - delete device from system.
> * @dev: device.
> *
> * This is the first part of the device unregistration
> * sequence. This removes the device from the lists we control
> * from here, has it removed from the other driver model
> * subsystems it was added to in device_add(), and removes it
> * from the kobject hierarchy.
> *
> * NOTE: this should be called manually _iff_ device_add() was
> * also called manually.
> */
>
> The rule is to either use
> 1) device_register()/device_unregister()
> or
> 2) device_initialize()/device_add()/device_del()/put_device().
>
> So change PCI core logic to follow the rule and get rid of the redundant
> pci_dev_get()/pci_dev_put() pair.
>
> Signed-off-by: Jiang Liu
> Acked-by: Bjorn Helgaas
> Signed-by: Yinghai Lu
Signed-off-by I suppose?
Apart from this:
Acked-by: Rafael J. Wysocki
> ---
> drivers/pci/probe.c |1 -
> drivers/pci/remove.c |4 ++--
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index b97dea5..48b35e1 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1298,7 +1298,6 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus
> *bus)
> {
> device_initialize(>dev);
> dev->dev.release = pci_release_dev;
> - pci_dev_get(dev);
>
> set_dev_node(>dev, pcibus_to_node(bus));
> dev->dev.dma_mask = >dma_mask;
> diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
> index 7c0fd92..fc38c48 100644
> --- a/drivers/pci/remove.c
> +++ b/drivers/pci/remove.c
> @@ -22,7 +22,7 @@ static void pci_stop_dev(struct pci_dev *dev)
> if (dev->is_added) {
> pci_proc_detach_device(dev);
> pci_remove_sysfs_dev_files(dev);
> - device_unregister(>dev);
> + device_del(>dev);
> dev->is_added = 0;
> }
>
> @@ -37,7 +37,7 @@ static void pci_destroy_dev(struct pci_dev *dev)
> up_write(_bus_sem);
>
> pci_free_resources(dev);
> - pci_dev_put(dev);
> + put_device(>dev);
> }
>
> void pci_remove_bus(struct pci_bus *bus)
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 04/22] PCI: Fix a device reference count leakage issue in pci_dev_present()
On Friday, January 11, 2013 02:40:31 PM Yinghai Lu wrote:
> From: Jiang Liu
>
> Function pci_get_dev_by_id() will hold a reference count on the pci device
> returned, so pci_dev_present() should release the corresponding reference
> count to avoid memory leakage.
>
> Signed-off-by: Jiang Liu
Acked-by: Rafael J. Wysocki
> ---
> drivers/pci/search.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/search.c b/drivers/pci/search.c
> index bf969ba..d0627fa 100644
> --- a/drivers/pci/search.c
> +++ b/drivers/pci/search.c
> @@ -319,13 +319,13 @@ int pci_dev_present(const struct pci_device_id *ids)
> WARN_ON(in_interrupt());
> while (ids->vendor || ids->subvendor || ids->class_mask) {
> found = pci_get_dev_by_id(ids, NULL);
> - if (found)
> - goto exit;
> + if (found) {
> + pci_dev_put(found);
> + return 1;
> + }
> ids++;
> }
> -exit:
> - if (found)
> - return 1;
> +
> return 0;
> }
> EXPORT_SYMBOL(pci_dev_present);
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 03/22] PCI: Set dev_node early for pci_dev
On Friday, January 11, 2013 02:40:30 PM Yinghai Lu wrote: > Otherwise irq_desc for pci bridge with hot-added ioapic can not be on > local node. > > Signed-off-by: Yinghai Lu Acked-by: Rafael J. Wysocki > --- > drivers/pci/probe.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > index 2dcd22d..b97dea5 100644 > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -1300,6 +1300,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus > *bus) > dev->dev.release = pci_release_dev; > pci_dev_get(dev); > > + set_dev_node(>dev, pcibus_to_node(bus)); > dev->dev.dma_mask = >dma_mask; > dev->dev.dma_parms = >dma_parms; > dev->dev.coherent_dma_mask = 0xull; > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 02/22] PCI: Add root bus children dev's res to fail list
On Friday, January 11, 2013 02:40:29 PM Yinghai Lu wrote:
> We can stop trying according to try number now and do not need to use
> root_bus checking as stop sign anymore.
>
> In extreme case we could need to reallocate resource for device just
> under root bus.
Well, the above says that we _can_ do the change, but it doesn't explain why it
is needed. So what's the reason why we need to do that?
Rafael
> Signed-off-by: Yinghai Lu
> ---
> drivers/pci/setup-bus.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index 6d3591d..7e8739e 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -283,7 +283,7 @@ static void assign_requested_resources_sorted(struct
> list_head *head,
> idx = res - _res->dev->resource[0];
> if (resource_size(res) &&
> pci_assign_resource(dev_res->dev, idx)) {
> - if (fail_head && !pci_is_root_bus(dev_res->dev->bus)) {
> + if (fail_head) {
> /*
>* if the failed res is for ROM BAR, and it will
>* be enabled later, don't add it to the list
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 01/22] PCI, acpiphp: Add is_hotplug_bridge detection
On Friday, January 11, 2013 02:40:28 PM Yinghai Lu wrote:
> When system support hotplug bridge with children hotplug slots, we need
> to make sure that parent bridge get preallocated resource so later when
> device is plugged into children slot, those children devices will get
> resource allocated.
>
> We do not meet this problem, because for pcie hotplug card, when acpiphp
> is used, pci_scan_bridge will set that for us when detect hotplug bit in
> slot cap.
>
> Reported-and-tested-by: Jason Baron
> Signed-off-by: Yinghai Lu
> Acked-by: Jason Baron
Acked-by: Rafael J. Wysocki
> ---
> drivers/pci/hotplug/acpiphp_glue.c | 27 ++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/hotplug/acpiphp_glue.c
> b/drivers/pci/hotplug/acpiphp_glue.c
> index 91b5ad8..1e5c5df 100644
> --- a/drivers/pci/hotplug/acpiphp_glue.c
> +++ b/drivers/pci/hotplug/acpiphp_glue.c
> @@ -797,6 +797,29 @@ static void acpiphp_set_acpi_region(struct acpiphp_slot
> *slot)
> }
> }
>
> +static void check_hotplug_bridge(struct acpiphp_slot *slot, struct pci_dev
> *dev)
> +{
> + struct acpiphp_func *func;
> +
> + if (!dev->subordinate)
> + return;
> +
> + /* quirk, or pcie could set it already */
> + if (dev->is_hotplug_bridge)
> + return;
> +
> + if (PCI_SLOT(dev->devfn) != slot->device)
> + return;
> +
> + list_for_each_entry(func, >funcs, sibling) {
> + if (PCI_FUNC(dev->devfn) == func->function) {
> + /* check if this bridge has ejectable slots */
> + if ((detect_ejectable_slots(func->handle) > 0))
> + dev->is_hotplug_bridge = 1;
> + break;
> + }
> + }
> +}
> /**
> * enable_device - enable, configure a slot
> * @slot: slot to be enabled
> @@ -831,8 +854,10 @@ static int __ref enable_device(struct acpiphp_slot *slot)
> if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
> dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
> max = pci_scan_bridge(bus, dev, max, pass);
> - if (pass && dev->subordinate)
> + if (pass && dev->subordinate) {
> + check_hotplug_bridge(slot, dev);
> pci_bus_size_bridges(dev->subordinate);
> + }
> }
> }
> }
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 00/22] PCI, ACPI: pci root bus hotplug support / pci match_driver
On Friday, January 11, 2013 02:40:27 PM Yinghai Lu wrote: > It includes > 1. preparing patches for pci root bus hotadd/hotremove support > 2. move root bus hotadd from acpiphp to pci_root.c > 3. add hot-remove support > 4. clean up hotadd/remove with common functions > 5. add acpi_hp_work to be shared with acpiphp and root-bus hotplug > 6. add match_driver to add pci device to device tree early but >not attach driver for hotplug path. > > based on pci/next > > could get from > > git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > for-pci-root-bus-hotplug > > After this patchset, will send out >for_each_host_bridge support >for_each_dev_addon_res > > Jiang Liu (4): > PCI: Fix a device reference count leakage issue in pci_dev_present() > PCI: make PCI device create/destroy logic symmetric > PCI: split registration of PCI bus devices into two stages > PCI: correctly detect ACPI PCI host bridge objects > > Tang Chen (2): > ACPI: Introduce a new acpi handle to determine HID match. > PCI, ACPI: debug print for installation of acpi root bridge's notifier > > Yinghai Lu (16): > PCI, acpiphp: Add is_hotplug_bridge detection > PCI: Add root bus children dev's res to fail list > PCI: Set dev_node early for pci_dev > ACPI: Separate acpi_bus_trim to support two steps. > PCI, acpiphp: Separate out hot-add support of pci host bridge > PCI, ACPI: Add pci_root_hp hot removal notification support. > PCI, ACPI: remove acpi_root_bridge in pci_root_hp > ACPI: update ej_event interface to take acpi_device > ACPI, PCI: Simplify handle_root_bridge_removal() > PCI, acpiphp: Don't bailout even no slots found yet. > PCI, ACPI: Add alloc_acpi_hp_work() > PCI, acpiphp: Use acpi_hp_work > PCI, pci_root_hp: Use acpi_hp_work > PCI, ACPI: Make kacpi_hotplug_wq static > PCI: add match_driver in struct pci_dev > PCI: move device_add out of pci_bus_add_device() It looks good overall, but I have a few questions and comments. I'll reply to the individual patches where applicable. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] ARM: use clockevents_config_and_register() where possible
On Sat, Jan 12, 2013 at 07:50:05PM +0800, Shawn Guo wrote: > The clockevent core is able to figure out the best mult and shift, > calculate min_delta_ns and max_delta_ns, with the necessary info passed > into clockevents_config_and_register(). Use this combined configure > and register function where possible to make the codes less error prone > and gain some positive diff stat. > > Signed-off-by: Shawn Guo > Cc: Nicolas Ferre > Reviewed-by: Anton Vorontsov > Acked-by: Kukjin Kim > Cc: Russell King > Cc: Sascha Hauer > Cc: Jason Cooper > Tested-by: Roland Stigge > Acked-by: Eric Miao > Cc: Haojian Zhuang > Cc: David Brown > Tested-by: Tony Lindgren > Acked-by: Barry Song > Tested-by: Stephen Warren > Acked-by: Tony Prisk > Cc: Lennert Buytenhek > Cc: Wan ZongShun > Acked-by: Viresh Kumar > Acked-by: Arnd Bergmann > --- ... > arch/arm/plat-orion/time.c |6 +- ... Acked-by: Jason Cooper thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] modpost: Add flag -f for making section mismatches fatal
On 3.1.2013 22:39, Jonathan Kliegman wrote: > I'm not sure what you mean about configs failing. After adding this > option to init/Kconfig I was able to build fine using old and new > configs with and without the option set. Is there something specific > you'd like me to test for? We still have section mismatches in allmodconfig. With a Kconfig option to make them fatal, allmodconfig would select it and fail. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] Use helper clockevents_config_and_register()
On Saturday 12 January 2013, Shawn Guo wrote: > The clockevent core is able to figure out the best mult and shift, > calculate min_delta_ns and max_delta_ns, with the necessary info passed > into clockevents_config_and_register(). Use this handy helper to make > the drivers less error prone and save some LOC. > > Changes since v1: > - Add one patch to export clockevents_config_and_register for fixing >the error [1] reported by Fengguang. > - Add Acked-by and Tested-by tags given by people (Thanks!) > > [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/209152 Very nice series! Acked-by: Arnd Bergmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
On Saturday 12 January 2013, Thierry Reding wrote: > > I already hinted at that in one of the other subthreads. Having such a > > multiplex would also allow the driver to be built as a module. I had > > already thought about this when I was working on an earlier version of > > these patches. Basically these would be two ops attached to the host > > bridge, and the generic arch_setup_msi_irq() could then look that up > > given the struct pci_dev that is passed to it and call this new per- > > host bridge .setup_msi_irq(). > > struct pci_ops looks like a good place to put these. They'll be > available from each struct pci_bus, so should be easy to call from > arch_setup_msi_irq(). > > Any objections? > struct pci_ops has a long history of being specifically about config space read/write operations, so on the one hand it does not feel like the right place to put interrupt specific operations, but on the other hand, the name sounds appropriate and I cannot think of any other place to put this, so it's fine with me. The only alternative I can think of is to introduce a new structure next to it in struct pci_bus, but that feels a bit pointless. Maybe Bjorn has a preference one way or the other. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fb: Rework locking to fix lock ordering on takeover
On Sat, 12 Jan 2013 12:51:49 -0800 Linus Torvalds
wrote:
> On Sat, Jan 12, 2013 at 10:36 AM, Borislav Petkov wrote:
> > On Mon, Jan 07, 2013 at 10:37:15AM +0100, Jiri Kosina wrote:
> >> Still seeing it with current Linus' tree.
> >>
> >> Tested-by: Jiri Kosina
> >>
> >> Anyone applying this, please?
> >
> > Yeah, I'm still seeing it in -rc3. Linus, can you pick up Alan's patch
> > from https://patchwork.kernel.org/patch/1757061/ please?
>
> Christ people.
>
> I already reported that it DOES NOT EVEN COMPILE. See the other thread
> here on lkml ("Re: 3.8-rc2: EFI framebuffer lock inversion...").
>
> Alan apparently doesn't care about the patch he wrote to even bother
> fixing that, and the only person who does seem to care enough to carry
> two fixes around (Andrew) apparently doesn't feel that he's
> comfortable forwarding it to me (he's been sending other patches, so
> it's not like Andrew is offline either)..
>
> I'm not picking up random patches from people who don't care enough
> about those patches to even bother fixing compile errors when
> reportyed and didn't even send them to me to begin with.
>
> So I'm trusting that Andrew is right, and is waiting for something.
>
Florian has been taking a month or two's downtime (now expired, I
think) so I've been waiting for him to reappear to process this one for
3.8.
Meanwhile, I guess we could put it into mainline ;) It has been in
-next for a month.
From: Alan Cox
Subject: fb: rework locking to fix lock ordering on takeover
Adjust the console layer to allow a take over call where the caller
already holds the locks. Make the fb layer lock in order.
This is partly a band aid, the fb layer is terminally confused about the
locking rules it uses for its notifiers it seems.
[a...@linux-foundation.org: remove stray non-ascii char, tidy comment]
[a...@linux-foundation.org: export do_take_over_console()]
Signed-off-by: Alan Cox
Cc: Florian Tobias Schandinat
Cc: Stephen Rothwell
Signed-off-by: Andrew Morton
---
drivers/tty/vt/vt.c | 91
drivers/video/console/fbcon.c | 30 ++
drivers/video/fbmem.c |5 -
drivers/video/fbsysfs.c |3 +
include/linux/console.h |1
5 files changed, 104 insertions(+), 26 deletions(-)
diff -puN
drivers/tty/vt/vt.c~fb-rework-locking-to-fix-lock-ordering-on-takeover
drivers/tty/vt/vt.c
--- a/drivers/tty/vt/vt.c~fb-rework-locking-to-fix-lock-ordering-on-takeover
+++ a/drivers/tty/vt/vt.c
@@ -2987,7 +2987,7 @@ int __init vty_init(const struct file_op
static struct class *vtconsole_class;
-static int bind_con_driver(const struct consw *csw, int first, int last,
+static int do_bind_con_driver(const struct consw *csw, int first, int last,
int deflt)
{
struct module *owner = csw->owner;
@@ -2998,7 +2998,7 @@ static int bind_con_driver(const struct
if (!try_module_get(owner))
return -ENODEV;
- console_lock();
+ WARN_CONSOLE_UNLOCKED();
/* check if driver is registered */
for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
@@ -3083,11 +3083,22 @@ static int bind_con_driver(const struct
retval = 0;
err:
- console_unlock();
module_put(owner);
return retval;
};
+
+static int bind_con_driver(const struct consw *csw, int first, int last,
+ int deflt)
+{
+ int ret;
+
+ console_lock();
+ ret = do_bind_con_driver(csw, first, last, deflt);
+ console_unlock();
+ return ret;
+}
+
#ifdef CONFIG_VT_HW_CONSOLE_BINDING
static int con_is_graphics(const struct consw *csw, int first, int last)
{
@@ -3199,9 +3210,9 @@ int unbind_con_driver(const struct consw
if (!con_is_bound(csw))
con_driver->flag &= ~CON_DRIVER_FLAG_INIT;
- console_unlock();
/* ignore return value, binding should not fail */
- bind_con_driver(defcsw, first, last, deflt);
+ do_bind_con_driver(defcsw, first, last, deflt);
+ console_unlock();
err:
module_put(owner);
return retval;
@@ -3492,28 +3503,18 @@ int con_debug_leave(void)
}
EXPORT_SYMBOL_GPL(con_debug_leave);
-/**
- * register_con_driver - register console driver to console layer
- * @csw: console driver
- * @first: the first console to take over, minimum value is 0
- * @last: the last console to take over, maximum value is MAX_NR_CONSOLES -1
- *
- * DESCRIPTION: This function registers a console driver which can later
- * bind to a range of consoles specified by @first and @last. It will
- * also initialize the console driver by calling con_startup().
- */
-int register_con_driver(const struct consw *csw, int first, int last)
+static int do_register_con_driver(const struct consw *csw, int first, int last)
{
struct module *owner = csw->owner;
struct con_driver *con_driver;
const char *desc;
int i, retval = 0;
+
Re: [PATCH] fb: Rework locking to fix lock ordering on takeover
Alan is dealing with family stuff that is far more important. Someone who has the time needs to own this and the fb layer. Not a don't care - a don't have time. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
* Eric Paris (epa...@redhat.com) wrote: > Getting an EPERM/EACCES in userspace really kinda blows. As a user you > don't have any idea why you got it. It could be SELinux, it could be > rwx bits on the file, it could be a missing capability, it could be an > ACL, it could be who knows what. We'd like to start figuring out the > who knows what and hopefully find a way to expose that to userspace. My > initial thought is a small buffer in the task struct in which the kernel > can dump some data when it is going to send back an EPERM. I was > thinking of exposing that data via a /proc/self/task/[tid]/file which > userspace could poll after an EPERM. The hope would be to all userspace > a better understanding of why it failed. Wouldn't it be nice if instead > of httpd log just saying 'permission denied' it would be able to say > 'permision denied because the file was 640"? It's not just file access that's the problem (although with all the security layers it's probably one of the more complex ones). I've wasted way too much time trying to figure out why mmap (for example) has given me an EINVAL; there are just too many holes you can fall into. I've wondered in the past about using more bits of errno; making the standard syscalls mask those out (when -ve), and making a new syscall that returns the whole lot; that probably doesn't provide you enough for file stuff though (unless it provided an index into your buffer?). So that shouldn't break an existing libc, but a new one would have a chance at a better errno. Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux | Happy \ \ gro.gilbert @ treblig.org | | In Hex / \ _|_ http://www.treblig.org |___/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] [regmap] [RESEND] Add "no-bus" configuration for regmap API
Second version of the initial patchset(can be found here: https://lkml.org/lkml/2012/12/21/98) This version contains following improvements: - Provisions to switch between mutexes and spinlocks for locking in "no-bus" configuration - "reg_read" and "reg_write" have "void *context" as a first argument in all the patches - Minor improvements in documentation Andrey Smirnov (3): Add provisions to have user-defined read operation Add provisions to have user-defined write operation Add "no-bus" option for regmap API drivers/base/regmap/internal.h |5 ++ drivers/base/regmap/regmap.c | 156 +--- include/linux/regmap.h | 18 - 3 files changed, 135 insertions(+), 44 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] [regmap] [RESEND] Add provisions to have user-defined write operation
This commit is a preparatory commit to provide "no-bus" configuration
option for regmap API. It adds necessary plumbing needed to have the
ability to provide user define register write function.
Signed-off-by: Andrey Smirnov
---
drivers/base/regmap/internal.h |1 +
drivers/base/regmap/regmap.c | 83 ++--
2 files changed, 55 insertions(+), 29 deletions(-)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 471eb90..51f0574 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -75,6 +75,7 @@ struct regmap {
const struct regmap_access_table *precious_table;
int (*reg_read)(void *context, unsigned int reg, unsigned int *val);
+ int (*reg_write)(void *context, unsigned int reg, unsigned int val);
u8 read_flag_mask;
u8 write_flag_mask;
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index ceaefcf..6845a07 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -36,6 +36,10 @@ static int _regmap_update_bits(struct regmap *map, unsigned
int reg,
static int _regmap_bus_read(void *context, unsigned int reg,
unsigned int *val);
+static int _regmap_bus_formatted_write(void *context, unsigned int reg,
+ unsigned int val);
+static int _regmap_bus_raw_write(void *context, unsigned int reg,
+unsigned int val);
bool regmap_reg_in_ranges(unsigned int reg,
const struct regmap_range *ranges,
@@ -580,6 +584,11 @@ struct regmap *regmap_init(struct device *dev,
goto err_map;
}
+ if (map->format.format_write)
+ map->reg_write = _regmap_bus_formatted_write;
+ else if (map->format.format_val)
+ map->reg_write = _regmap_bus_raw_write;
+
map->range_tree = RB_ROOT;
for (i = 0; i < config->num_ranges; i++) {
const struct regmap_range_cfg *range_cfg = >ranges[i];
@@ -986,12 +995,54 @@ static int _regmap_raw_write(struct regmap *map, unsigned
int reg,
return ret;
}
+static int _regmap_bus_formatted_write(void *context, unsigned int reg,
+ unsigned int val)
+{
+ int ret;
+ struct regmap_range_node *range;
+ struct regmap *map = context;
+
+ BUG_ON(!map->format.format_write);
+
+ range = _regmap_range_lookup(map, reg);
+ if (range) {
+ ret = _regmap_select_page(map, , range, 1);
+ if (ret != 0)
+ return ret;
+ }
+
+ map->format.format_write(map, reg, val);
+
+ trace_regmap_hw_write_start(map->dev, reg, 1);
+
+ ret = map->bus->write(map->bus_context, map->work_buf,
+ map->format.buf_size);
+
+ trace_regmap_hw_write_done(map->dev, reg, 1);
+
+ return ret;
+}
+
+static int _regmap_bus_raw_write(void *context, unsigned int reg,
+unsigned int val)
+{
+ struct regmap *map = context;
+
+ BUG_ON(!map->format.format_val);
+
+ map->format.format_val(map->work_buf + map->format.reg_bytes
+ + map->format.pad_bytes, val, 0);
+ return _regmap_raw_write(map, reg,
+map->work_buf +
+map->format.reg_bytes +
+map->format.pad_bytes,
+map->format.val_bytes);
+}
+
int _regmap_write(struct regmap *map, unsigned int reg,
unsigned int val)
{
- struct regmap_range_node *range;
int ret;
- BUG_ON(!map->format.format_write && !map->format.format_val);
if (!map->cache_bypass && map->format.format_write) {
ret = regcache_write(map, reg, val);
@@ -1010,33 +1061,7 @@ int _regmap_write(struct regmap *map, unsigned int reg,
trace_regmap_reg_write(map->dev, reg, val);
- if (map->format.format_write) {
- range = _regmap_range_lookup(map, reg);
- if (range) {
- ret = _regmap_select_page(map, , range, 1);
- if (ret != 0)
- return ret;
- }
-
- map->format.format_write(map, reg, val);
-
- trace_regmap_hw_write_start(map->dev, reg, 1);
-
- ret = map->bus->write(map->bus_context, map->work_buf,
- map->format.buf_size);
-
- trace_regmap_hw_write_done(map->dev, reg, 1);
-
- return ret;
- } else {
- map->format.format_val(map->work_buf + map->format.reg_bytes
- + map->format.pad_bytes, val, 0);
- return _regmap_raw_write(map, reg,
-map->work_buf +
-
[PATCH 3/3] [regmap] [RESEND] Add "no-bus" option for regmap API
This commit adds provision for "no-bus" usage of the regmap API. In
this configuration user can provide API with two callbacks 'reg_read'
and 'reg_write' which are to be called when reads and writes to one of
device's registers is performed. This is useful for devices that
expose registers but whose register access sequence does not fit the 'bus'
abstraction.
Signed-off-by: Andrey Smirnov
---
drivers/base/regmap/internal.h |2 ++
drivers/base/regmap/regmap.c | 52 ++--
include/linux/regmap.h | 18 +-
3 files changed, 59 insertions(+), 13 deletions(-)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 51f0574..3b1f74b 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -77,6 +77,8 @@ struct regmap {
int (*reg_read)(void *context, unsigned int reg, unsigned int *val);
int (*reg_write)(void *context, unsigned int reg, unsigned int val);
+ bool cache_registers;
+
u8 read_flag_mask;
u8 write_flag_mask;
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 6845a07..4f7fcec 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -379,7 +379,7 @@ struct regmap *regmap_init(struct device *dev,
enum regmap_endian reg_endian, val_endian;
int i, j;
- if (!bus || !config)
+ if (!config)
goto err;
map = kzalloc(sizeof(*map), GFP_KERNEL);
@@ -393,7 +393,8 @@ struct regmap *regmap_init(struct device *dev,
map->unlock = config->unlock;
map->lock_arg = config->lock_arg;
} else {
- if (bus->fast_io) {
+ if ((bus && bus->fast_io) ||
+ config->fast_io) {
spin_lock_init(>spinlock);
map->lock = regmap_lock_spinlock;
map->unlock = regmap_unlock_spinlock;
@@ -433,11 +434,19 @@ struct regmap *regmap_init(struct device *dev,
if (config->read_flag_mask || config->write_flag_mask) {
map->read_flag_mask = config->read_flag_mask;
map->write_flag_mask = config->write_flag_mask;
- } else {
+ } else if (bus) {
map->read_flag_mask = bus->read_flag_mask;
}
- map->reg_read = _regmap_bus_read;
+ if (!bus) {
+ map->reg_read = config->reg_read;
+ map->reg_write = config->reg_write;
+
+ map->cache_registers = true;
+ goto skip_format_initialization;
+ } else {
+ map->reg_read = _regmap_bus_read;
+ }
reg_endian = config->reg_format_endian;
if (reg_endian == REGMAP_ENDIAN_DEFAULT)
@@ -584,10 +593,14 @@ struct regmap *regmap_init(struct device *dev,
goto err_map;
}
- if (map->format.format_write)
+ if (map->format.format_write) {
+ map->cache_registers = true;
map->reg_write = _regmap_bus_formatted_write;
- else if (map->format.format_val)
+ } else if (map->format.format_val) {
map->reg_write = _regmap_bus_raw_write;
+ }
+
+skip_format_initialization:
map->range_tree = RB_ROOT;
for (i = 0; i < config->num_ranges; i++) {
@@ -790,7 +803,7 @@ void regmap_exit(struct regmap *map)
regcache_exit(map);
regmap_debugfs_exit(map);
regmap_range_exit(map);
- if (map->bus->free_context)
+ if (map->bus && map->bus->free_context)
map->bus->free_context(map->bus_context);
kfree(map->work_buf);
kfree(map);
@@ -893,6 +906,8 @@ static int _regmap_raw_write(struct regmap *map, unsigned
int reg,
size_t len;
int i;
+ BUG_ON(!map->bus);
+
/* Check for unwritable registers before we start */
if (map->writeable_reg)
for (i = 0; i < val_len / map->format.val_bytes; i++)
@@ -1002,7 +1017,7 @@ static int _regmap_bus_formatted_write(void *context,
unsigned int reg,
struct regmap_range_node *range;
struct regmap *map = context;
- BUG_ON(!map->format.format_write);
+ BUG_ON(!map->bus || !map->format.format_write);
range = _regmap_range_lookup(map, reg);
if (range) {
@@ -1028,7 +1043,7 @@ static int _regmap_bus_raw_write(void *context, unsigned
int reg,
{
struct regmap *map = context;
- BUG_ON(!map->format.format_val);
+ BUG_ON(!map->bus || !map->format.format_val);
map->format.format_val(map->work_buf + map->format.reg_bytes
+ map->format.pad_bytes, val, 0);
@@ -1043,8 +1058,9 @@ int _regmap_write(struct regmap *map, unsigned int reg,
unsigned int val)
{
int ret;
+ void *context = (map->bus) ? map : map->bus_context;
- if (!map->cache_bypass &&
[PATCH 1/3] [regmap] [RESEND] Add provisions to have user-defined read operation
This commit is a preparatory commit to provide "no-bus" configuration
option for regmap API. It adds necessary plumbing needed to have the
ability to provide user define register read function.
Signed-off-by: Andrey Smirnov
---
drivers/base/regmap/internal.h |2 ++
drivers/base/regmap/regmap.c | 35 ++-
2 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 401d191..471eb90 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -74,6 +74,8 @@ struct regmap {
const struct regmap_access_table *volatile_table;
const struct regmap_access_table *precious_table;
+ int (*reg_read)(void *context, unsigned int reg, unsigned int *val);
+
u8 read_flag_mask;
u8 write_flag_mask;
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 42d5cb0..ceaefcf 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -34,6 +34,9 @@ static int _regmap_update_bits(struct regmap *map, unsigned
int reg,
unsigned int mask, unsigned int val,
bool *change);
+static int _regmap_bus_read(void *context, unsigned int reg,
+ unsigned int *val);
+
bool regmap_reg_in_ranges(unsigned int reg,
const struct regmap_range *ranges,
unsigned int nranges)
@@ -430,6 +433,8 @@ struct regmap *regmap_init(struct device *dev,
map->read_flag_mask = bus->read_flag_mask;
}
+ map->reg_read = _regmap_bus_read;
+
reg_endian = config->reg_format_endian;
if (reg_endian == REGMAP_ENDIAN_DEFAULT)
reg_endian = bus->reg_format_endian_default;
@@ -1202,10 +1207,27 @@ static int _regmap_raw_read(struct regmap *map,
unsigned int reg, void *val,
return ret;
}
+static int _regmap_bus_read(void *context, unsigned int reg,
+ unsigned int *val)
+{
+ int ret;
+ struct regmap *map = context;
+
+ if (!map->format.parse_val)
+ return -EINVAL;
+
+ ret = _regmap_raw_read(map, reg, map->work_buf, map->format.val_bytes);
+ if (ret == 0)
+ *val = map->format.parse_val(map->work_buf);
+
+ return ret;
+}
+
static int _regmap_read(struct regmap *map, unsigned int reg,
unsigned int *val)
{
int ret;
+ BUG_ON(!map->reg_read);
if (!map->cache_bypass) {
ret = regcache_read(map, reg, val);
@@ -1213,26 +1235,21 @@ static int _regmap_read(struct regmap *map, unsigned
int reg,
return 0;
}
- if (!map->format.parse_val)
- return -EINVAL;
-
if (map->cache_only)
return -EBUSY;
- ret = _regmap_raw_read(map, reg, map->work_buf, map->format.val_bytes);
+ ret = map->reg_read(map, reg, val);
if (ret == 0) {
- *val = map->format.parse_val(map->work_buf);
-
#ifdef LOG_DEVICE
if (strcmp(dev_name(map->dev), LOG_DEVICE) == 0)
dev_info(map->dev, "%x => %x\n", reg, *val);
#endif
trace_regmap_reg_read(map->dev, reg, *val);
- }
- if (ret == 0 && !map->cache_bypass)
- regcache_write(map, reg, *val);
+ if (!map->cache_bypass)
+ regcache_write(map, reg, *val);
+ }
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fb: Rework locking to fix lock ordering on takeover
On Sat, Jan 12, 2013 at 10:36 AM, Borislav Petkov wrote:
> On Mon, Jan 07, 2013 at 10:37:15AM +0100, Jiri Kosina wrote:
>> Still seeing it with current Linus' tree.
>>
>> Tested-by: Jiri Kosina
>>
>> Anyone applying this, please?
>
> Yeah, I'm still seeing it in -rc3. Linus, can you pick up Alan's patch
> from https://patchwork.kernel.org/patch/1757061/ please?
Christ people.
I already reported that it DOES NOT EVEN COMPILE. See the other thread
here on lkml ("Re: 3.8-rc2: EFI framebuffer lock inversion...").
Alan apparently doesn't care about the patch he wrote to even bother
fixing that, and the only person who does seem to care enough to carry
two fixes around (Andrew) apparently doesn't feel that he's
comfortable forwarding it to me (he's been sending other patches, so
it's not like Andrew is offline either)..
I'm not picking up random patches from people who don't care enough
about those patches to even bother fixing compile errors when
reportyed and didn't even send them to me to begin with.
So I'm trusting that Andrew is right, and is waiting for something.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.7-rc7: BUG: MAX_STACK_TRACE_ENTRIES too low!
On Wed, 28 Nov 2012 at 16:41, Li Zhong wrote: > On Tue, 2012-11-27 at 19:22 -0800, Christian Kujau wrote: > > On Tue, 27 Nov 2012 at 19:06, Christian Kujau wrote: > > > the same thing[0] happened again in 3.7-rc7, after ~20h uptime: > > > > I found the following on patchwork, but this seems to deal with powerpc64 > > only, while this PowerBook G4 of mine is powerpc32: > > > > http://patchwork.ozlabs.org/patch/193414/ > > > > It looks related, but then again, I fail to parse assember... > > Hi Christian, > > Would you please help to try the following fix? I don't have a powerpc32 > machine for test... The patch hasn't made it into mainline yet. Any chance that this will be included in 3.8? Thanks, Christian. > == > diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S > index 9499385..cadebfd 100644 > --- a/arch/powerpc/kernel/entry_32.S > +++ b/arch/powerpc/kernel/entry_32.S > @@ -439,6 +439,8 @@ ret_from_fork: > ret_from_kernel_thread: > REST_NVGPRS(r1) > bl schedule_tail > + li r3,0 > + stw r3,0(r1) > mtlrr14 > mr r3,r15 > PPC440EP_ERR42 > == > > > > > Christian. > > > > > [40007.339487] [sched_delayed] sched: RT throttling activated > > > [69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low! > > > [69731.390371] turning off the locking correctness validator. > > > [69731.391942] Call Trace: > > > [69731.393525] [c9a61c10] [c0009064] show_stack+0x70/0x1bc (unreliable) > > > [69731.395152] [c9a61c50] [c0077460] save_trace+0xfc/0x114 > > > [69731.396735] [c9a61c60] [c007be20] __lock_acquire+0x1568/0x19b8 > > > [69731.398296] [c9a61d00] [c007c2c0] lock_acquire+0x50/0x70 > > > [69731.399857] [c9a61d20] [c0550e28] _raw_spin_lock_irq+0x5c/0x78 > > > [69731.401419] [c9a61d40] [c054fb58] __schedule+0xd8/0x534 > > > [69731.402972] [c9a61da0] [c0550094] _cond_resched+0x50/0x68 > > > [69731.404527] [c9a61db0] [c0479908] dst_gc_task+0xbc/0x258 > > > [69731.406070] [c9a61e40] [c004eeb8] process_one_work+0x1f4/0x49c > > > [69731.407585] [c9a61e80] [c004f644] worker_thread+0x14c/0x400 > > > [69731.409075] [c9a61eb0] [c0057634] kthread+0xbc/0xc0 > > > [69731.410521] [c9a61f40] [c0011ad4] ret_from_kernel_thread+0x5c/0x64 > > > [...repeated 54 times...] > > > > > > Anyone knows what this is about? > > > > > > Thanks, > > > Christian. > > > > > > [0] http://lkml.indiana.edu/hypermail/linux/kernel/1211.0/03025.html > > > -- BOFH excuse #258: That's easy to fix, but I can't be bothered. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.7.X vs 3.6.11 HP Folio 9470m brightness regression?
well, I tried to do that, bisecting between 3.6.10 and 3.7. I'm not sure to have done that properly, as the result seems quite harmless, however here it is: d978348b300595b067b80980f6a78db09fcd584c is the first bad commit commit d978348b300595b067b80980f6a78db09fcd584c Author: Bob Moore Date: Fri Aug 17 10:51:47 2012 +0800 ACPICA: Split ACPICA initialization functions to new file, utxfinit.c Split utxface.c to improve modularity and reduce file size. Signed-off-by: Bob Moore Signed-off-by: Feng Tang Signed-off-by: Len Brown :04 04 57bc8451026afe02fdbc2970b152164ff4e5412a 55311ce2f9fed66501b06f93f67fa99b54d46e86 M drivers Please let me know If I've done something wrong or if I can help in other ways. Many thanks for the hint. 2013/1/12 Daniel Vetter : > On Sat, Jan 12, 2013 at 12:22 PM, Fabio Coatti wrote: >> I'm seeing the same behaviour on 3.7.2; even >> echo "NN" > brightness has no effect. >> I've tried to look at changes between 3.6.11 and 3.7.2 but probably >> this is beyond my skills ;) > > If the regression is with the acpi_video backlight, then it's very > likely not a bug in drm/i915. Quickest way to figure that out is to do > a git bisect between 3.6 and 3.7, my favourite howto is: > http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ > > Cheers, Daniel > >> 2012/12/20 Fabio Coatti : >>> In data mercoledì 19 dicembre 2012 17:10:29, hai scritto: - Original Message - > From: "Fabio Coatti" > To: linux-kernel@vger.kernel.org > Sent: Wednesday, 19 December, 2012 5:01:30 PM > Subject: 3.7.X vs 3.6.11 HP Folio 9470m brightness regression? > > Hi, > I'm testing kernels 3.7.X vs 3.6.11 on an HP Folio 9470m machine, > i915 > driver for a VGA compatible controller: Intel Corporation 3rd Gen > Core > processor Graphics Controller (rev 09) 8086:0166 > > With 3.6.11, the brightness can be correctly set using fn+f9/10: kde > shows the bar and brightness changes. > > With 3.7.1 kde shows the percentage bar and > /sys/class/backlight/acpi_video0/brightness is updated, but the > screen > brightness does not changes. I had a similar problem with my Dell laptop and i915/acpi... Is there another acpi_video? device? In my case two showed up in 3.7 whereas in 3.6 there was one. In 3.7 it was controlling the wrong one apparently. >>> >>> Well, this seems not to be the case, I have only one acpi_video: >>> >>> calvin ~ # ls -l /sys/class/backlight/ >>> totale 0 >>> lrwxrwxrwx 1 root root 0 20 dic 09.20 acpi_video0 -> >>> ../../devices/pci:00/:00:02.0/backlight/acpi_video0 >>> >>> calvin ~ # ls -l /sys/devices/pci:00/:00:02.0/backlight >>> totale 0 >>> drwxr-xr-x 3 root root 0 20 dic 09.20 acpi_video0 >>> >>> >>> >>> -- >>> Fabio >> >> >> >> -- >> Fabio > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Fabio -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Sat, Jan 12, 2013 at 8:39 PM, Alex Riesen wrote: > On Sat, Jan 12, 2013 at 6:37 PM, Alan Stern wrote: >> On Sat, 12 Jan 2013, Alex Riesen wrote: >>> One more detail: I usually use the "noop" elevator. That time it was >>> the "deadline". And I just reproduced it easily with "deadline". >> >> I doubt the elevator has anything to do with this. > > But it looks like it does: just using the deadline elevator is a sure way > to reproduce the bug. The system always recovers (sometimes after a while) > with "noop". And no, it does not. Not by itself, but the fact that deadline elevator was compiled as module certainly helped! This explains the hanging modprobe in the dmesg output (the part after device connect). I still wonder, why didn't it froze at boot, mounting SATA devices (the root, /var, and /home are on an SSD connected by SATA)? And why hanging khubd at reboot? Anyway, building the elevator in the kernel avoids the problem. Sorry for not spotting this earlier. Now, who would be interested to handle this kind of misconfiguration ... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Sat, Jan 12, 2013 at 6:37 PM, Alan Stern wrote: > On Sat, 12 Jan 2013, Alex Riesen wrote: > >> On Fri, Jan 11, 2013 at 10:04 PM, Alex Riesen wrote: >> > >> > the USB stick (an Cruzer Titanium 2GB) was not recognized at any of >> > the USB ports of this system (an System76 lemu4 laptop, XHCI device) >> > after it was removed. [...] > > To make testing simpler, use only the USB-2 ports. The xHCI driver is > not as mature as the EHCI driver. I used the USB2 port, but enabled the debugging for xHCI too, just because it is not as mature as you say, but in the same machine. And there are some traces from it, even though I didn't touch the USB3 ports. Might be unrelated, but just in case... >> > The kernel is v3.8-rc3. I never had this problem in 3.7. I could almost For the record, I just retested: the problem persists with 3.7.1. >> > reproduce the problem later in a simplified setup (init=/bin/bash) on >> > USB3 ports by inserting and removing the stick quickly. Almost - because >> > the USB3 ports recovered after some time, while the USB2 port never >> > experienced the problem. > > For testing, use a kernel with CONFIG_USB_DEBUG and CONFIG_PRINTK_TIME > enabled. Do the following: > > After a normal boot, run "dmesg -C" to clear the log buffer. > > Then plug in the stick. After a couple of seconds, type Alt-SysRq-W. > > Then unplug the stick. After a couple of seconds, type Alt-SysRq-W > again. > > Then collect the output from dmesg and post it. Attached. A remount in the middle is me remounting an SATA device to save dmesg output in case the system crashes hard. dmesg2.bz2 Description: BZip2 compressed data
Re: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Sat, Jan 12, 2013 at 6:37 PM, Alan Stern wrote: > On Sat, 12 Jan 2013, Alex Riesen wrote: >> One more detail: I usually use the "noop" elevator. That time it was >> the "deadline". And I just reproduced it easily with "deadline". > > I doubt the elevator has anything to do with this. But it looks like it does: just using the deadline elevator is a sure way to reproduce the bug. The system always recovers (sometimes after a while) with "noop". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Reproducible OOM with just a few sleeps
The issue is a regression with PAE, reproduced and verified on Ubuntu, on my home PC with 3GB RAM. My PC was running kernel linux-image-3.2.0-35-generic so it showed: psz@DellE520:~$ uname -a Linux DellE520 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:45:18 UTC 2012 i686 i686 i386 GNU/Linux psz@DellE520:~$ free -l total used free sharedbuffers cached Mem: 3087972 6922562395716 0 18276 427116 Low:861464 71372 790092 High: 2226508 6208841605624 -/+ buffers/cache: 2468642841108 Swap: 2920 258364 19742556 Then it handled the "sleep test" bash -c 'n=0; while [ $n -lt 33000 ]; do sleep 600 & ((n=n+1)); ((m=n%500)); if [ $m -lt 1 ]; then echo -n "$n - "; date; free -l; sleep 1; fi; done' just fine, stopped only by "max user processes" (default setting of "ulimit -u 23964"), or raising that limit stopped when the machine ran out of PID space; there was no OOM. Installing and running the PAE kernel so it showed: psz@DellE520:~$ uname -a Linux DellE520 3.2.0-35-generic-pae #55-Ubuntu SMP Wed Dec 5 18:04:39 UTC 2012 i686 i686 i386 GNU/Linux psz@DellE520:~$ free -l total used free sharedbuffers cached Mem: 3087620 6811882406432 0 167332 352296 Low:865208 214080 651128 High: 412 4671081755304 -/+ buffers/cache: 1615602926060 Swap: 2920 0 2920 and re-trying the "sleep test", it ran into OOM after 18000 or so sleeps and crashed/froze so I had to press the POWER button to recover. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] signalfd: add ability to return siginfo in a raw format (v2)
On 01/10, Andrey Wagin wrote: > > 2012/12/28 Oleg Nesterov : > >> > >> This functionality is required for checkpointing pending signals. > > > > And this should be used along with pread(). > > > > I won't argue, but perhaps we should simply postulate that pread() > > always dumps siginfo in raw format and avoid the new flag? > > I won't argue too:), but I think the flag is more flexiable. The flag > allows to get raw siginfo from read(), it may be useful not only for > checkpoint/restore. pread with offset = 0 is equal to read(), so the > interface with the flag is more clear. OK, I agree. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.8.0-rc3: possible circular locking dependency: >legacy_mutex / >hangup_work with serial/RFCOMM connection via USB bluetooth dongle
Hi,
Running a 3.8.0-rc3 kernel (latest commit
b719f43059903820c31edb30f4663a2818836e7f) kernel (debian squeeze os), i'm
running into this lockdep warning when:
- Running a perl script that uses rfcomm to communicatie via bluetooth with a
bluetooth/TTL converter.
- It can run ok for a few hours before this lockdep occurs and the perl script
freezes.
- The info related to bluetooth from syslog:
Jan 12 10:24:08 serveerstertje kernel: [7.919775] Bluetooth: Virtual HCI
driver ver 1.3
Jan 12 10:24:08 serveerstertje kernel: [7.920314] Bluetooth: HCI UART
driver ver 2.2
Jan 12 10:24:08 serveerstertje kernel: [7.920316] Bluetooth: HCI H4
protocol initialized
Jan 12 10:24:08 serveerstertje kernel: [7.920317] Bluetooth: HCI BCSP
protocol initialized
Jan 12 10:24:08 serveerstertje kernel: [7.920318] Bluetooth: HCILL protocol
initialized
Jan 12 10:24:08 serveerstertje kernel: [7.920318] Bluetooth: HCIATH3K
protocol initialized
Jan 12 10:24:08 serveerstertje kernel: [7.920319] Bluetooth: HCI Three-wire
UART (H5) protocol initialized
Jan 12 10:24:08 serveerstertje kernel: [8.191897] Bluetooth: RFCOMM TTY
layer initialized
Jan 12 10:24:08 serveerstertje kernel: [8.191930] Bluetooth: RFCOMM socket
layer initialized
Jan 12 10:24:08 serveerstertje kernel: [8.191931] Bluetooth: RFCOMM ver 1.11
Jan 12 10:24:08 serveerstertje kernel: [8.191932] Bluetooth: BNEP (Ethernet
Emulation) ver 1.3
Jan 12 10:24:08 serveerstertje kernel: [8.191933] Bluetooth: BNEP filters:
protocol multicast
Jan 12 10:24:08 serveerstertje kernel: [8.191944] Bluetooth: BNEP socket
layer initialized
Jan 12 10:24:08 serveerstertje kernel: [8.191945] Bluetooth: HIDP (Human
Interface Emulation) ver 1.2
Jan 12 10:24:08 serveerstertje kernel: [8.191954] Bluetooth: HIDP socket
layer initialized
Jan 12 10:24:09 serveerstertje bluetoothd[3912]: Bluetooth deamon 4.66
Jan 12 10:24:09 serveerstertje bluetoothd[3912]: Starting SDP server
Jan 12 10:24:09 serveerstertje bluetoothd[3912]: Starting experimental netlink
support
Jan 12 10:24:09 serveerstertje bluetoothd[3912]: Failed to find Bluetooth
netlink family
Jan 12 10:24:09 serveerstertje bluetoothd[3912]: Failed to init netlink plugin
Jan 12 10:24:09 serveerstertje bluetoothd[3912]: bridge pan0 created
Jan 12 10:24:09 serveerstertje bluetoothd[3912]: HCI dev 0 registered
Jan 12 10:24:09 serveerstertje bluetoothd[3912]: Failed to open RFKILL control
device
Jan 12 10:24:09 serveerstertje bluetoothd[3912]: HCI dev 0 up
Jan 12 10:24:09 serveerstertje bluetoothd[3912]: Starting security manager 0
Jan 12 10:24:09 serveerstertje bluetoothd[3912]: Adapter /org/bluez/3912/hci0
has been enabled
Jan 12 10:24:09 serveerstertje bluetoothd[3912]: Failed to access HAL
- And the lockdep warning itself:
[28678.458250]
[28678.476588] ==
[28678.494887] [ INFO: possible circular locking dependency detected ]
[28678.513013] 3.8.0-rc3-20130112-netpatched-rocketscience-radeon #1 Not tainted
[28678.530909] ---
[28678.548636] kworker/2:1/19513 is trying to acquire lock:
[28678.566070] (>legacy_mutex){+.+.+.}, at: []
tty_lock_nested+0x3e/0x80
[28678.583577]
[28678.583577] but task is already holding lock:
[28678.617615] ((>hangup_work)){+.+...}, at: []
process_one_work+0x158/0x4b0
[28678.634569]
[28678.634569] which lock already depends on the new lock.
[28678.634569]
[28678.683868]
[28678.683868] the existing dependency chain (in reverse order) is:
[28678.715354]
[28678.715354] -> #2 ((>hangup_work)){+.+...}:
[28678.745890][] __lock_acquire+0x44e/0xdd0
[28678.760975][] lock_acquire+0xba/0x100
[28678.775834][] flush_work+0x3a/0x250
[28678.790408][] tty_ldisc_flush_works+0x18/0x40
[28678.804877][] tty_ldisc_release+0x2e/0x90
[28678.818952][] tty_release+0x3c7/0x590
[28678.832813][] __fput+0xa9/0x2c0
[28678.846411][] fput+0x9/0x10
[28678.859644][] task_work_run+0x95/0xb0
[28678.872661][] do_notify_resume+0x6d/0x80
[28678.885516][] int_signal+0x12/0x17
[28678.898047]
[28678.898047] -> #1 (>legacy_mutex/1){+.+...}:
[28678.922334][] __lock_acquire+0x44e/0xdd0
[28678.934268][] lock_acquire+0xba/0x100
[28678.945916][] mutex_lock_nested+0x4c/0x450
[28678.957318][] tty_lock_nested+0x3e/0x80
[28678.968500][] tty_lock_pair+0x6a/0x70
[28678.979405][] tty_release+0x16b/0x590
[28678.990012][] __fput+0xa9/0x2c0
[28679.000367][] fput+0x9/0x10
[28679.009455] FW: BLOCKED low udp input: IN=eth0 OUT=
MAC=40:61:86:f4:67:d9:00:08:ae:10:46:60:08:00 SRC=112.203.174.221
DST=88.159.69.252 LEN=131 TOS=0x00 PREC=0x00 TTL=38 ID=17898 PROTO=UDP
SPT=27001 DPT=1024 LEN=111
[28679.030869][] task_work_run+0x95/0xb0
[28679.040727][] do_notify_resume+0x6d/0x80
[28679.050419][] in
Re: ALSA: Conexant CX20585 (thinkpad t510) speaker powersave regression
On Tue, 08 Jan 2013 16:26:38 +0100 Takashi Iwai wrote: > At Sat, 22 Dec 2012 14:23:24 -0700, > Kevin Fenzi wrote: > > > > Greetings. > > > > I've got an issue with sound on my t510. It started in the late > > 3.4.x kernels. Sound works on boot and for 5-10min after, then the > > speakers stop working at all. > > > > I posted a while back on the alsa-users list, and someone else had > > the same issue: > > > > http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28769.html > > > > It seems that the speakers(?) are getting moved to state D3 and > > turning off. You can manually get it to come back for a few minutes > > by using hda-verb to move it back to D0: > > > > hda-verb /dev/snd/hwC0D0 0x1f SET_POWER_STATE 0 > > > > http://www.alsa-project.org/db/?f=fd5ca157b2e76942df5ce2f0ae1a2817f3f08afd > > is my alsa-info. > > > > I'd file a bug on the alsa bug tracker, but it still seems to be > > down (for many months now?). No response on alsa-users, so now that > > I have a bit of time, I am posting here in hopes someone can > > look. ;) > > > > Happy to provide more info or try things. > > It's a known problem that some people have already reported, but > currently no clue who actually turns down the pin to D3. > Conexant guys wrote me that the codec doesn't do it by itself, and the > driver neither, AFAIK. A possible answer is the firmware / BIOS, but > who knows. > > In anyway, could you try to trace the hd-audio events and see whether > the power down is *not* issued by the driver when you see this state? > See Documentation/sound/alsa/HD-Audio.txt, the section "Tracepoints" > for a brief instruction. ok. I am not sure I am doing the right thing, but: - echo 1 > /sys/kernel/debug/tracing/events/hda/enable - Run hda-verb to get sound working. - Play a video to confirm. - check /sys/kernel/debug/tracing/trace - Wait a while. - Play another sound that doesn't come out of speakers. - check /sys/kernel/debug/tracing/trace for anything new. The only things I see in the trace file are my hda-verb call, and the sounds playing. Nothing else. I then tried to duplicate it, but the trace file didn't seem to update properly. Is there some reset needed? Or is this not the info you were looking for? hda-verb-27187 [001] 78907.305149: hda_power_count: [0:0] power_count=1, power_on=1, power_transition=0 hda-verb-27187 [001] 78907.305152: hda_send_cmd: [0:0] val=1f70500 hda-verb-27187 [001] 78907.305214: hda_get_response: [0:0] val=0 hda-verb-27187 [001] 78907.305214: hda_power_count: [0:0] power_count=0, power_on=1, power_transition=0 alsa-sink-17958 [000] 78933.682478: hda_power_count: [0:0] power_count=1, power_on=1, power_transition=0 alsa-sink-17958 [000] 78933.683330: hda_power_count: [0:0] power_count=2, power_on=1, power_transition=0 alsa-sink-17958 [000] 78933.683335: hda_power_count: [0:0] power_count=3, power_on=1, power_transition=0 alsa-sink-17958 [000] 78933.683336: hda_send_cmd: [0:0] val=103a047 alsa-sink-17958 [000] 78933.683378: hda_get_response: [0:0] val=0 alsa-sink-17958 [000] 78933.683379: hda_power_count: [0:0] power_count=2, power_on=1, power_transition=0 alsa-sink-17958 [000] 78933.683380: hda_power_count: [0:0] power_count=3, power_on=1, power_transition=0 ... kevin signature.asc Description: PGP signature
Re: [PATCH] fb: Rework locking to fix lock ordering on takeover
On Mon, Jan 07, 2013 at 10:37:15AM +0100, Jiri Kosina wrote: > Still seeing it with current Linus' tree. > > Tested-by: Jiri Kosina > > Anyone applying this, please? Yeah, I'm still seeing it in -rc3. Linus, can you pick up Alan's patch from https://patchwork.kernel.org/patch/1757061/ please? Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PTRACE_SYSCALL && vsyscall (Was: arch_check_bp_in_kernelspace: fix the range check)
On 01/10, u3...@miso.sublimeip.com wrote: > > Hi Everyone, > > > On 01/08, Pedro Alves wrote: > >> > >> On 12/04/2012 05:59 PM, Oleg Nesterov wrote: > >> > >> > But If we want to allow to trace vsyscall's, hw bp doesn't look very > >> > nice imo. HBP_NUM = 4 and you need to setup 3 bp's to trace them all. > >> > >> Irrespective of the whole syscall tracing issue, allowing HW bkpts in > >> the vsyscall just seems like a bug fix to me. > > > > And I never argued. I sent the patch iirc ;) > > Exactly, it is a bug and I am still waiting for it to be fixed in the > Linux kernel. I would not say this is a bug but let me repeat, no need to convince me. Please feel free to re-send the patch(es) I sent to maintainers. Sorry, I can't push these changes into Linus's tree. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
On 01/12/2013 10:08 AM, Borislav Petkov wrote: On Sat, Jan 12, 2013 at 09:40:20AM -0800, H. Peter Anvin wrote: Hiding it because it happens to be in a slightly illogical place seems completely backwards. Sure, that's the lazy dude solution™ :-) I could try to restructure arch/x86/Kconfig but is it worth the trouble to fix the "slightly illogical" placing... Well, it's more than that. It is actually removing functionality because it is "illogically placed"... that cure is worse than the disease. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
On Sat, Jan 12, 2013 at 09:40:20AM -0800, H. Peter Anvin wrote: > Hiding it because it happens to be in a slightly illogical place seems > completely backwards. Sure, that's the lazy dude solution™ :-) I could try to restructure arch/x86/Kconfig but is it worth the trouble to fix the "slightly illogical" placing... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rwlock_t unfairness and tasklist_lock
On 01/11, Michel Lespinasse wrote:
>
> So I looked again at getpriority() since that's what I had used for my
> DOS test code, and it looks like everything there is already protected
> by RCU or smaller granularity locks and refcounts. Patch attached to
> remove this tasklist_lock usage.
And probably the change in getpriority() is fine, but ...
> @@ -189,7 +189,6 @@ SYSCALL_DEFINE3(setpriority, int, which, int, who, int,
> niceval)
> niceval = 19;
>
> rcu_read_lock();
> - read_lock(_lock);
> switch (which) {
> case PRIO_PROCESS:
> if (who)
> @@ -226,7 +225,6 @@ SYSCALL_DEFINE3(setpriority, int, which, int, who, int,
> niceval)
> break;
> }
> out_unlock:
> - read_unlock(_lock);
you also changed setpriority(), this should be documented at least ;)
OK. Even without this change, say, sys_setpriority(PRIO_PGRP) can obviously
race with fork(), so this change probably is not bad.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/23] uvc: Replace memcpy with struct assignment
On Wed, Jan 9, 2013 at 9:19 PM, Laurent Pinchart wrote: > Hi Ezequiel, > > On Thursday 27 December 2012 21:49:37 Mauro Carvalho Chehab wrote: >> Em Thu, 27 Dec 2012 18:12:46 -0300 Ezequiel Garcia escreveu: >> > On Tue, Oct 23, 2012 at 4:57 PM, Ezequiel Garcia wrote: >> > > This kind of memcpy() is error-prone. Its replacement with a struct >> > > assignment is prefered because it's type-safe and much easier to read. >> > > >> > > Found by coccinelle. Hand patched and reviewed. >> > > Tested by compilation only. >> > > >> > > A simplified version of the semantic match that finds this problem is as >> > > follows: (http://coccinelle.lip6.fr/) >> > > >> > > // >> > > @@ >> > > identifier struct_name; >> > > struct struct_name to; >> > > struct struct_name from; >> > > expression E; >> > > @@ >> > > -memcpy(&(to), &(from), E); >> > > +to = from; >> > > // >> > > >> > > Cc: Laurent Pinchart >> > > Signed-off-by: Peter Senna Tschudin >> > > Signed-off-by: Ezequiel Garcia >> > > --- >> > > >> > > drivers/media/usb/uvc/uvc_v4l2.c |6 +++--- >> > > 1 files changed, 3 insertions(+), 3 deletions(-) >> > > >> > > diff --git a/drivers/media/usb/uvc/uvc_v4l2.c >> > > b/drivers/media/usb/uvc/uvc_v4l2.c index f00db30..4fc8737 100644 >> > > --- a/drivers/media/usb/uvc/uvc_v4l2.c >> > > +++ b/drivers/media/usb/uvc/uvc_v4l2.c >> > > @@ -314,7 +314,7 @@ static int uvc_v4l2_set_format(struct uvc_streaming >> > > *stream, >> > > goto done; >> > > } >> > > >> > > - memcpy(>ctrl, , sizeof probe); >> > > + stream->ctrl = probe; >> > > >> > > stream->cur_format = format; >> > > stream->cur_frame = frame; >> > > @@ -386,7 +386,7 @@ static int uvc_v4l2_set_streamparm(struct >> > > uvc_streaming *stream, >> > > return -EBUSY; >> > > } >> > > >> > > - memcpy(, >ctrl, sizeof probe); >> > > + probe = stream->ctrl; >> > > probe.dwFrameInterval = >> > > uvc_try_frame_interval(stream->cur_frame, interval); >> > > >> > > @@ -397,7 +397,7 @@ static int uvc_v4l2_set_streamparm(struct >> > > uvc_streaming *stream, >> > > return ret; >> > > } >> > > >> > > - memcpy(>ctrl, , sizeof probe); >> > > + stream->ctrl = probe; >> > > mutex_unlock(>mutex); >> > > >> > > /* Return the actual frame period. */ >> > >> > It seems you've marked this one as "Changes requested" [1]. >> > However, Laurent didn't request any change, >> > but just pointed out we missed one memcpy replacement candidate. >> > >> > I believe it's safe to apply the patch (together with the other 20 >> > patches) and we can fix the missing spot in another patch. >> >> The other patches got applied already. Well just do whatever Laurent asked >> you and re-submit this one ;) > > Could you please resubmit this patch with the missed memcpy replaced by a > struct assignment ? I'll then add it to my tree. > Sure! Thanks, -- Ezequiel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
On 01/12/2013 09:06 AM, Borislav Petkov wrote: > > Ok, I don't know whether this was on purpose or not but setting ARCH=x86 > has the side effect of putting the config 64BIT prompt into the toplevel > menuconfig: > > [*] 64-bit kernel > General setup ---> > [*] Enable loadable module support ---> > [*] Enable the block layer ---> > Processor type and features ---> > > Now, IMHO, maybe the more fitting place for this should be "Processor > type and features" where all the arch-specific stuff goes but looking at > arch/x86/Kconfig, it would need some restructuring due to dependencies. > > So how about we simply hide it by still preserving the functionality: > Hiding it because it happens to be in a slightly illogical place seems completely backwards. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.8-rc1 - another regression on USB :-(
On Sat, 12 Jan 2013, Andreas Mohr wrote: > There's of course the EHCI vs. UHCI(/OHCI) duality > (EHCI host controller responsible for high speed transfers, > the other for 1.1 full speed, both serving the same port connectors). > So if the coordination between the two is a problem, > you might end up with merely full speed on a 2.0 port. > > And with drivers builtin vs. module, the init sequence/timing > might possibly be affected - right? > Perhaps this got worsened by semi-recent driver init kernel changes? > (AFAIR the kernel was changed to init more things in parallel, > for faster bootup). So maybe that affected EHCI vs. UHCI coordination timing. Another important change is that the EHCI driver is now split into two modules. That can slow down loading and affect the timing. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Sat, 12 Jan 2013, Alex Riesen wrote: > On Fri, Jan 11, 2013 at 10:04 PM, Alex Riesen wrote: > > Hi, > > > > the USB stick (an Cruzer Titanium 2GB) was not recognized at any of > > the USB ports of this system (an System76 lemu4 laptop, XHCI device) > > after it was removed. If I attempt to insert it again in any of the > > ports (one of the two USB3, or the USB2) the led on the stick lights > > up shortly and if off again. There is no media detection messages in > > the dmesg output, only that from the first time: To make testing simpler, use only the USB-2 ports. The xHCI driver is not as mature as the EHCI driver. > > usb 1-1.2: new high-speed USB device number 3 using ehci-pci > > usb 1-1.2: New USB device found, idVendor=0781, idProduct=5408 > > usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > > usb 1-1.2: Product: U3 Titanium > > usb 1-1.2: Manufacturer: SanDisk Corporation > > usb 1-1.2: SerialNumber: 187A3A60F1E9 > > scsi6 : usb-storage 1-1.2:1.0 > > io scheduler deadline registered (default) > > usb 1-1.2: USB disconnect, device number 3 > > > > The kernel is v3.8-rc3. I never had this problem in 3.7. I could almost > > reproduce the problem later in a simplified setup (init=/bin/bash) on > > USB3 ports by inserting and removing the stick quickly. Almost - because > > the USB3 ports recovered after some time, while the USB2 port never > > experienced the problem. For testing, use a kernel with CONFIG_USB_DEBUG and CONFIG_PRINTK_TIME enabled. Do the following: After a normal boot, run "dmesg -C" to clear the log buffer. Then plug in the stick. After a couple of seconds, type Alt-SysRq-W. Then unplug the stick. After a couple of seconds, type Alt-SysRq-W again. Then collect the output from dmesg and post it. > One more detail: I usually use the "noop" elevator. That time it was > the "deadline". And I just reproduced it easily with "deadline". I doubt the elevator has anything to do with this. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] irqchip init infrastructure and GIC/VIC move
Arnd, Olof, Please pull for 3.9. This is the initial infrastructure and conversion of the GIC and VIC to use it. Several people are waiting for the irqchip infrastructure to go in in order to convert other irqchip code over. I've left "static asmlinkage" in on the irq handlers. There's been no more discussion, so I think we are in agreement. If asmlinkage defines the procedure call convention for assembly calls, then it still makes sense to have it on a static function called thru a function pointer. Rob The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20: Linux 3.8-rc3 (2013-01-09 18:59:55 -0800) are available in the git repository at: git://sources.calxeda.com/kernel/linux.git tags/gic-vic-to-irqchip for you to fetch changes up to 9e47b8bf9815523a5816f2f83e73b13812d74014: irqchip: Move ARM vic.h to include/linux/irqchip/arm-vic.h (2013-01-12 10:52:16 -0600) Initial irqchip init infrastructure and GIC and VIC clean-ups This creates irqchip initialization infrastructure from Thomas Petazzoni. The VIC and GIC irqchip code is moved to drivers/irqchips and adapted to use the new infrastructure. All DT enabled platforms using GIC and VIC are converted over to use the new irqchip_init. Rob Herring (16): ARM: GIC: remove assembly ifdefs from gic.h ARM: GIC: remove direct use of gic_raise_softirq ARM: GIC: set handle_arch_irq in GIC initialization ARM: remove mach .handle_irq for GIC users irqchip: Move ARM GIC to drivers/irqchip ARM: use common irqchip_init for GIC init irqchip: Move ARM gic.h to include/linux/irqchip/arm-gic.h ARM: VIC: shrink down vic.h ARM: VIC: set handle_arch_irq in VIC initialization ARM: remove mach .handle_irq for VIC users ARM: remove unneeded vic.h includes ARM: samsung: remove unused tick.h irqchip: Move ARM VIC to drivers/irqchip ARM: spear: use common irqchip_init function ARM: picoxcell: use common irqchip_init function irqchip: Move ARM vic.h to include/linux/irqchip/arm-vic.h Srinidhi Kasagar (1): ARM: mach-ux500: use SGI0 to wake up the other core Thomas Petazzoni (3): irqchip: add to the directories part of the IRQ subsystem in MAINTAINERS irqchip: add basic infrastructure arm: add set_handle_irq() to register the parent IRQ controller handler function MAINTAINERS|1 + arch/arm/common/Kconfig| 23 - arch/arm/common/Makefile |2 - arch/arm/include/asm/mach/irq.h|1 + arch/arm/kernel/irq.c | 10 +++ arch/arm/kernel/smp.c |3 +- arch/arm/kernel/smp_twd.c |1 - arch/arm/mach-bcm/board_bcm.c | 17 +--- arch/arm/mach-cns3xxx/cns3420vb.c |2 - arch/arm/mach-cns3xxx/core.c |2 +- arch/arm/mach-ep93xx/adssphere.c |2 - arch/arm/mach-ep93xx/core.c|3 +- arch/arm/mach-ep93xx/edb93xx.c |9 -- arch/arm/mach-ep93xx/gesbc9312.c |2 - arch/arm/mach-ep93xx/micro9.c |5 -- arch/arm/mach-ep93xx/simone.c |2 - arch/arm/mach-ep93xx/snappercl15.c |2 - arch/arm/mach-ep93xx/ts72xx.c |2 - arch/arm/mach-ep93xx/vision_ep9307.c |2 - arch/arm/mach-exynos/common.c | 10 ++- arch/arm/mach-exynos/include/mach/regs-irq.h |2 +- arch/arm/mach-exynos/mach-armlex4210.c |2 - arch/arm/mach-exynos/mach-exynos4-dt.c |2 - arch/arm/mach-exynos/mach-exynos5-dt.c |2 - arch/arm/mach-exynos/mach-nuri.c |2 - arch/arm/mach-exynos/mach-origen.c |2 - arch/arm/mach-exynos/mach-smdk4x12.c |3 - arch/arm/mach-exynos/mach-smdkv310.c |3 - arch/arm/mach-exynos/mach-universal_c210.c |2 - arch/arm/mach-exynos/mct.c |1 - arch/arm/mach-exynos/platsmp.c |6 +- arch/arm/mach-highbank/highbank.c | 11 +-- arch/arm/mach-highbank/platsmp.c |6 +- arch/arm/mach-imx/common.h |1 - arch/arm/mach-imx/gpc.c|2 +- arch/arm/mach-imx/mach-imx6q.c | 10 +-- arch/arm/mach-imx/platsmp.c|4 +- arch/arm/mach-msm/board-dt-8660.c | 16 +--- arch/arm/mach-msm/board-dt-8960.c | 16 +--- arch/arm/mach-msm/platsmp.c|6 +-
Re: rwlock_t unfairness and tasklist_lock
On 01/09, Michel Lespinasse wrote: > > On Wed, Jan 9, 2013 at 9:49 AM, Oleg Nesterov wrote: > > On 01/08, Michel Lespinasse wrote: > >> Like others before me, I have discovered how easy it is to DOS a > >> system by abusing the rwlock_t unfairness and causing the > >> tasklist_lock read side to be continuously held > > > > Yes. Plus it has perfomance problems. > > > > It should die. We still need the global lock to protect, say, > > init_task.tasks list, but otherwise we need the per-process locking. > > To be clear: I'm not trying to defend tasklist_lock here. I understand, > However, > given how long this has been a known issue, I think we should consider > attacking the problem from the lock fairness perspective first and > stop waiting for an eventual tasklist_lock death. And probably you are right, > >> - Would there be any fundamental objection to implementing a fair > >> rwlock_t and dealing with the reentrancy issues in tasklist_lock ? My > >> proposal there would be along the lines of: > > > > I don't really understand your proposal in details, but until we kill > > tasklist_lock, perhaps it makes sense to implement something simple, say, > > write-biased rwlock and add "int task_struct->tasklist_read_lock_counter" > > to avoid the read-write-read deadlock. > > Right. But one complexity that has to be dealt with, is how to handle > reentrant uses of the tasklist_lock read side, > ... > > there is still the > possibility of an irq coming up in before the counter is incremented. Sure, I didn't try to say that it is trivial to implement read_lock_tasklist(), we should prevent this race. > So to deal with that, I think we have to explicitly detect the > tasklist_lock uses that are in irq/softirq context and deal with these > differently from those in process context I disagree. In the long term, I think that tasklist (or whatever we use instead) should be never used in irq/atomic context. And probably the per-process lock should be rw_semaphore (although it is not recursive). But until then, if we try to improve the things somehow, we should not complicate the code, we need something simple. But actually I am not sure, you can be right. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kconfig-frontends-3.6.0-0 released
On Saturday 2012-10-06 17:55, Yann E. MORIN wrote:
>Hello All!
>
>I'm pleased to announce the release of kconfig-frontends 3.6.0-0!
>Go download it there:
>
> http://ymorin.is-a-geek.org/download/kconfig-frontends/kconfig-frontends-3.6.0-0.tar.xz
Please stick to a single separator, i.e. "3.6.0.0". The dash is already
used by distributions to mark same-source releases.
>And the repository can be browsed or hg-cloned from:
> http://ymorin.is-a-geek.org/hg/kconfig-frontends
Ugh, hg. There goes any chance for contributions.
bootstrap.sh
>printf "Running libtoolize...\n"
>libtoolize --copy --force
>printf "Running aclocal...\n"
>aclocal -Wall --force
Not again. autoreconf has existed for so long, why are people still
hand-coding the boilerplate?
configure.ac
> By default, do not build with -Wall, unless the user asks for it
There normally is no excuse for not using -Wall by default,
save for trying to compile it with msvc.
>AC_HEADER_STDC
>AC_HEADER_STDBOOL
>AC_CHECK_HEADERS([ fcntl.h limits.h locale.h ])
>AC_CHECK_HEADERS([ stdlib.h string.h sys/time.h unistd.h ])
>AC_TYPE_SIZE_T
>AC_FUNC_MALLOC
>AC_FUNC_REALLOC
>AC_FUNC_ALLOCA
>AC_CHECK_FUNCS([ bzero memmove memset ])
>AC_CHECK_FUNCS([ strcasecmp strchr strcspn strdup strncasecmp strpbrk strrchr
>strspn strtol ])
>AC_CHECK_FUNCS([ gettimeofday mkdir regcomp setlocale uname ])
All of this seems pointless because you never use the results
(HAVE_FCNTL_H, HAVE_LIMITS_H, etc.)
ncurses has the ncurses{w,}{6,5}-config scripts that ought to be called
to determine the locations.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] arm: vt8500: Add support for Wondermedia WM8750/WM8850
On Sat, Jan 12, 2013 at 04:07:24PM +1300, Tony Prisk wrote:
> > I suggest that you split off the last three (and rebase them to be
> > independent), and apply them to a multiplatform branch for vt8500. Then the
> > last one is a soc branch that goes on top of the multiplatform branch (i.e.
> > you
> > build it on top of multiplatform). That way we can pull in the multiplatform
> > changes together with those for other platforms, and then take the
> > wm8{7,8}50
> > branch goes in with the other new-soc support from other platforms.
> >
> > Does that make sense? I'll be happy to provide more explanation if it
> > doesn't.
> >
> > -Olof
>
> I think I understand - pull requests to follow.
Looks good, thanks for fixing it up. Next time feel free to change to
fresh subjects on the pull requests. :)
I don't see your PGP key uploaded to the public key servers, and you
likely don't have it signed by anyone else. If you have a chance, please
try to get it signed by a few people. Ideal time to do that is if you're
going to any conferences, but there are also local people around the
world that can meet up sometimes.
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] IIO ADC support for AD7923
On 01/08/2013 10:14 AM, Alessandro Rubini wrote: >> +config AD7923 > > I wonder if IIO config symbols should have IIO_ in their name, so > people looking at config files knows what they actually are. > Actually, all USB drivers have USB in their config name, which is > useful even if e.g. "PL2303" cannot be but USB. > > On the other hand, AD7923 and all the others can well be driven by > something else than IIO, even if currently this is the only mainstream > option. No, IIO is and should be the only option for these devices. We really don't want to drivers for the same device in different subsystems of the kernel. The other argument is still valid though. > Here comedi made the right choice, and all their symbols are > in the CONFIG_COMEDI_ name space. - lars -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] arm: vt8500: Add support for Wondermedia WM8750/WM8850
On Sat, Jan 12, 2013 at 04:09:49PM +1300, Tony Prisk wrote: > The following changes since commit > ce3f386fdf10d79eaf6ebd63bb7adbd95f08f9f0: > > arm: vt8500: Remove remaining mach includes (2013-01-12 15:47:39 > +1300) > > are available in the git repository at: > > git://server.prisktech.co.nz/git/linuxwmt.git tags/armsoc-3.9 Thanks, I pulled this in as vt8500/wm8x50 -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] arm: vt8500: Add support for Wondermedia WM8750/WM8850
On Sat, Jan 12, 2013 at 04:09:23PM +1300, Tony Prisk wrote: > The following changes since commit > d1c3ed669a2d452cacfb48c2d171a1f364dae2ed: > > Linux 3.8-rc2 (2013-01-02 18:13:21 -0800) > > are available in the git repository at: > > git://server.prisktech.co.nz/git/linuxwmt.git > tags/vt8500-multiplatform-3.9 Thanks, pulled in as vt8500/multiplatform. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 5/6] uprobes: add bp_vaddr argument to consumer handler
On 01/10, Josh Stone wrote: > > For uprobes, systemtap wants regs->ip to be the real breakpoint address, Just to be sure this didn't escape your attention... Please note that this becomes true after [PATCH 2/2] uprobes: Change handle_swbp() to expose bp_vaddr to handler_chain() http://marc.info/?l=linux-kernel=135688247630262 so you should no longer use uprobe_get_swbp_addr or inst->vaddr to change regs->ip. > and for uretprobes we want the original return address. Yes, Anton's v2 does this. But. Don't you also need to know the address of function we are going to return from? Probably you do not, uprobe_consumer should know which function (but not vaddr) it probes, but please confirm. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86 e820: only void usable memory areas in memmap=exactmap case
On Sat, Jan 12, 2013 at 3:31 AM, Thomas Renninger wrote: > memmap=exactmap [KNL,X86] Enable setting of an exact > - E820 memory map, as specified by the user. > - Such memmap=exactmap lines can be constructed based on > - BIOS output or other requirements. See the > memmap=nn@ss > - option description. > + E820 usable memory map, as specified by the user. > + All unusable (reserved, ACPI, NVS,...) ranges from the > + original e820 table are preserved. > + But the usable memory regions from the original e820 > + table are removed. > + This parameter is explicitly for kdump usage: > + The memory the kdump kernel is allowed to use must > + be passed via below memmap=nn[KMG]@ss[KMG] param. > + All reserved regions the kernel may use for > ioremapping > + and similar are still considered. > + > + memmap=voidmap [KNL,X86] Do not use any e820 ranges from BIOS or > + bootloader. Instead you have to pass regions via > + below memmap= options. I would suggest to keep memmap=exactmap meaning not changed, and add memmap=exactusablemap instead. kexec-tools could be updated to support exactusablemap with kernelversion checking for kdump. also we need to double check to make sure: 1. exactmap should override exactusablemap, even the out of order sequence. 2. when exactusablemap is used, not just remove old usable type range, also need to remove overlapped range with new usable range. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG_64BIT
On Thu, Dec 20, 2012 at 06:07:46PM -0800, tip-bot for David Woodhouse wrote: > Commit-ID: ffee0de411fd4f74f3b788892eeb075abbf26c52 > Gitweb: http://git.kernel.org/tip/ffee0de411fd4f74f3b788892eeb075abbf26c52 > Author: David Woodhouse > AuthorDate: Thu, 20 Dec 2012 21:51:55 + > Committer: H. Peter Anvin > CommitDate: Thu, 20 Dec 2012 14:37:18 -0800 > > x86: Default to ARCH=x86 to avoid overriding CONFIG_64BIT > > It is easy to waste a bunch of time when one takes a 32-bit .config > from a test machine and try to build it on a faster 64-bit system, and > its existing setting of CONFIG_64BIT=n gets *changed* to match the > build host. Similarly, if one has an existing build tree it is easy > to trash an entire build tree that way. > > This is because the default setting for $ARCH when discovered from > 'uname' is one of the legacy pre-x86-merge values (i386 or x86_64), > which effectively force the setting of CONFIG_64BIT to match. We should > default to ARCH=x86 instead, finally completing the merge that we > started so long ago. Ok, I don't know whether this was on purpose or not but setting ARCH=x86 has the side effect of putting the config 64BIT prompt into the toplevel menuconfig: [*] 64-bit kernel General setup ---> [*] Enable loadable module support ---> [*] Enable the block layer ---> Processor type and features ---> Now, IMHO, maybe the more fitting place for this should be "Processor type and features" where all the arch-specific stuff goes but looking at arch/x86/Kconfig, it would need some restructuring due to dependencies. So how about we simply hide it by still preserving the functionality: -- diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 50b1b1bf442b..e8d7e9250853 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1,6 +1,7 @@ # Select 32 or 64 bit config 64BIT - bool "64-bit kernel" if ARCH = "x86" + bool + default y if ARCH = "x86" default ARCH != "i386" ---help--- Say yes to build a 64-bit kernel - formerly known as x86_64 Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7] kbuild: create a rule to run the pre-processor on *.dts files
On Wed, Jan 2, 2013 at 10:43 AM, Stephen Warren wrote: > From: Stephen Warren > > Create cmd_dtc_cpp to run the C pre-processor on *.dts file before > passing them to dtc for final compilation. This allows the use of #define > and #include within the .dts file. > > Signed-off-by: Stephen Warren Acked-by: Simon Glass > --- > Grant, back in mid-November, you said you'd make a decision on this in > the next couple of days, but I think this got overlooked. > > v7: Build *.dtb from *.dts not src/*.dts. > v6: No change. > v5: > * Update Documentation/kbuild for the new command and rule. > v4: > * Use -x assembler-with-cpp so pre-defined macros are set up so that > #included header files know to only use cpp syntax, not C syntax. > * Define __DTS__ for similar reasons. > * use $(CPP) not $(CC) -E, and use $(cpp_flags). > * Save the pre-processed results so they can be easily inspected when > debugging build issues. > * The use of -x assembler-with-cpp causes cpp to recognize directives in > column 1 only. Hence, there's no need to escape property names that > begin with #. Hence, there's no need for separate skeleton.dtsi and > skeleton.dtsip. Maintain a separate file extension and build rule so that > CPP-usage is opt-in. In particular, when using CPP, #include must be used > rather than /include/ so that dependencies work. > v3: Pass "-x c" not "-xc" to cpp. > v2: Place make %.dtb: %.dtsp rule into Makefile.lib. > --- > Documentation/kbuild/makefiles.txt | 23 +++ > scripts/Makefile.lib |9 + > 2 files changed, 32 insertions(+) > > diff --git a/Documentation/kbuild/makefiles.txt > b/Documentation/kbuild/makefiles.txt > index 14c3f4f..5198b74 100644 > --- a/Documentation/kbuild/makefiles.txt > +++ b/Documentation/kbuild/makefiles.txt > @@ -1186,6 +1186,29 @@ When kbuild executes, the following steps are followed > (roughly): > clean-files += *.dtb > DTC_FLAGS ?= -p 1024 > > +dtc_cpp > + This is just like dtc as describe above, except that the C pre- > + processor is invoked upon the .dtsp file before compiling the result > + with dtc. > + > + In order for build dependencies to work, all files compiled using > + dtc_cpp must use the C pre-processor's #include functionality and not > + dtc's /include/ functionality. > + > + Using the C pre-processor allows use of #define to create named > + constants. In turn, the #defines will typically appear in a header > + file, which may be shared with regular C code. Since the dtc language > + represents a data structure rather than code in C syntax, similar > + restrictions are placed on a header file included by a device tree > + file as for a header file included by an assembly language file. > + In particular, the C pre-processor is passed -x assembler-with-cpp, > + which sets macro __ASSEMBLY__. __DTS__ is also set. These allow header > + files to restrict their content to that compatible with device tree > + source. > + > + A central rule exists to create $(obj)/%.dtb from $(src)/%.dtsp; > + architecture Makefiles do no need to explicitly write out that rule. > + > --- 6.8 Custom kbuild commands > > When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index bdf42fd..2c2a302 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -269,6 +269,15 @@ cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 > $(DTC_FLAGS) -d $(depfile > $(obj)/%.dtb: $(src)/%.dts FORCE > $(call if_changed_dep,dtc) > > +dtc-tmp = $(subst $(comma),_,$(dot-target).dts) > + > +quiet_cmd_dtc_cpp = DTC+CPP $@ > +cmd_dtc_cpp = $(CPP) $(cpp_flags) -D__DTS__ -x assembler-with-cpp -o > $(dtc-tmp) $< ; \ > + $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) $(dtc-tmp) > + > +$(obj)/%.dtb: $(src)/%.dtsp FORCE > + $(call if_changed_dep,dtc_cpp) > + > # Bzip2 > # --- > > -- > 1.7.10.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.8-rc1 - another regression on USB :-(
On Saturday 12 January 2013 14:16:02 Andreas Mohr wrote: > > Greg, Linus, > > It sounds insane, but after banging on the issue I have found out that > > USB problem is caused (also in vanilla kernel) with a config change: > > USB-all built as modules - bad USB > > USB core built in, UHCI/EHCI modules - semi functional - but 1Mb/s > > transfer > > USB core and UHCI EHCI built-in - bingo - no issues. > > > > Could anybody duplicate that, or is it somehow my setup??? > > Since there was no additional reply here (needed) so far, > some of my (questionably relevant?) thoughts on this: > > There's of course the EHCI vs. UHCI(/OHCI) duality > (EHCI host controller responsible for high speed transfers, > the other for 1.1 full speed, both serving the same port connectors). > So if the coordination between the two is a problem, > you might end up with merely full speed on a 2.0 port. > > And with drivers builtin vs. module, the init sequence/timing > might possibly be affected - right? You should try EHCI first. This has always been true, but the likeliehood of seeing trouble is variable. This is testable. EHCI static, UHCI modular - should work EHCI modular, UHCI static - should fail Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmotm 2013-01-11-15-47 uploaded (x86 asm-offsets broken)
On Sat, 2013-01-12 at 11:13 +0100, Sedat Dilek wrote: > On Sat, Jan 12, 2013 at 3:29 AM, Joe Perches wrote: > > On Sat, 2013-01-12 at 13:17 +1100, Stephen Rothwell wrote: > >> On Fri, 11 Jan 2013 17:43:06 -0800 Randy Dunlap > >> wrote: > >> > > >> > b0rked. > >> > > >> > Some (randconfig?) causes this set of errors: > > > > I guess that's when CONFIG_HZ is not an even divisor of 1000. > > I suppose this needs to be worked on a bit more. [] > I remember this patch from Joe come up with a pending patch in > net-next.git#master [] > As I see Randy has in his kernel-config: > CONFIG_HZ=300 > So there is a problem for the value "300" (only)? Basically, this problem exists whenever timeconst.h is necessary. kernel/Makefile has code to create it in kernel/ and kernel/time.c is the only file that uses it. That code will need to be removed and newly written somewhere so that timeconst.h could be created as include/linux/timeconst.h before any other compilation so that jiffies.h can #include it. I believe it should be akin to how version.h or elfconfig.h is created. Someone with stronger Makefile foo could probably do it quicker than I could. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] uprobes: Add exports for module use
On 01/11, Christoph Hellwig wrote: > > On Thu, Jan 10, 2013 at 03:01:46PM -0800, Josh Stone wrote: > > The original pull message for uprobes (commit 654443e2) noted: > > > > This tree includes uprobes support in 'perf probe' - but SystemTap > > (and other tools) can take advantage of user probe points as well. > > > > In order to actually be usable in module-based tools like SystemTap, the > > interface needs to be exported. This patch first adds the obvious > > exports for uprobe_register and uprobe_unregister. Then it also adds > > one for task_user_regset_view, which is necessary to get the correct > > state of userspace registers. > > Get systemtap into the mainline kernel tree and we can talk. I can't understand your reply. Looks like, you do not like the fact that uprobes can be used by the out of tree modules. Why? And why, say, kprobe_register() is exported then? Afaics, it does not have any modular in-kernel user. As for systemtap in particular. I never used it, and probably you didn't. But it has a lot of users, and I know many people who find it very useful. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
