* initialisation freqency patch problem.
From: Ian Molton @ 2009-09-29 3:01 UTC (permalink / raw)
To: linux-mmc
Hi folks,
The commit 8dfd0374be84793360db7fff2e635d2cd3bbcb21 is causing one of
my MMC cards to fail to initialise.
Has anyone else seen initialisation failures since this patch?
I suspect the problem is in tmio-mmc but its a weird one - only one of
my two tc6393xb based hosts has this issue, and none of t7l66 or
tc6387, and only with one card.
I'll look into it tomorrow and see what actual clock frequency is
getting selected.
I'm off to bed now.
--
Ian Molton
Linux, Automotive, and other hacking:
http://www.mnementh.co.uk/
^ permalink raw reply
* Re: [Bonding-devel] [PATCH 4/4] bonding: add sysfs files to display tlb and alb hash table contents
From: Stephen Hemminger @ 2009-09-29 3:00 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Andy Gospodarek, netdev, fubar, bonding-devel
In-Reply-To: <20090929013713.GG4436@gospo.rdu.redhat.com>
On Mon, 28 Sep 2009 21:37:13 -0400
Andy Gospodarek <andy@greyhouse.net> wrote:
> On Mon, Sep 28, 2009 at 05:34:20PM -0700, Stephen Hemminger wrote:
> > On Mon, 28 Sep 2009 20:12:03 -0400
> > Andy Gospodarek <andy@greyhouse.net> wrote:
> >
> > > On Mon, Sep 28, 2009 at 04:22:37PM -0700, Stephen Hemminger wrote:
> > > > On Fri, 11 Sep 2009 17:13:17 -0400
> > > > Andy Gospodarek <andy@greyhouse.net> wrote:
> > > >
> > > > >
> > > > > bonding: add sysfs files to display tlb and alb hash table contents
> > > > >
> > > > > While debugging some problems with alb (mode 6) bonding I realized that
> > > > > being able to output the contents of both hash tables would be helpful.
> > > > > This is what the output looks like for the two files:
> > > > >
> > > > > device load
> > > > > eth1 491
> > > > > eth2 491
> > > > > hash device last device tx bytes load next previous
> > > > > 2 eth1 eth1 2254 491 0 0
> > > > > 3 eth2 eth2 2744 491 0 0
> > > > > 6 eth2 0 488 0 0
> > > > > 8 eth2 0 461698 0 0
> > > > > 1b eth2 0 249 0 0
> > > > > eb eth2 0 21 0 0
> > > > > ff eth2 0 22 0 0
> > > > >
> > > > > hash ip_src ip_dst mac_dst slave assign ntt
> > > > > 2 10.0.3.2 10.0.3.11 00:e0:81:71:ee:a9 eth1 1 0
> > > > > 3 10.0.3.2 10.0.3.10 00:e0:81:71:ee:a9 eth2 1 0
> > > > > 8 10.0.3.2 10.0.3.1 00:e0:81:71:ee:a9 eth2 1 0
> > > > >
> > > > > These were a great help debugging the fixes I have just posted and they
> > > > > might be helpful for others, so I decided to include them in my
> > > > > patchset.
> > > > >
> > > > > Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> > > >
> > > > No.
> > > >
> > > > Please don't put formatted output in sysfs, it is not meant to be
> > > > used like proc, there is supposed to be only one value per file.
> > >
> > > Then based on the over 300 files in /sys/ that are more than 1 line on
> > > my currently running kernel, it seems there is significant work to do.
> > >
> > > Seemingly arbitrary requests like this are extremely annoying when the
> > > current kernel violates them all over the place.
> > >
> >
> > The rules are documented in Documentation/sysfs-rules.txt. If you want
> > to change the rules, submit a change to the rules.
> >
>
> That specific request is actually in filesystems/sysfs.txt in the
> 'Attributes' section, but the fact that it's actually outlined somewhere
> makes the request seem less 'arbitrary.' ;-)
>
Ah, that is where the note is:
----------------------
Attributes
~~~~~~~~~~
Attributes can be exported for kobjects in the form of regular files in
the filesystem. Sysfs forwards file I/O operations to methods defined
for the attributes, providing a means to read and write kernel
attributes.
Attributes should be ASCII text files, preferably with only one value
per file. It is noted that it may not be efficient to contain only one
value per file, so it is socially acceptable to express an array of
values of the same type.
Mixing types, expressing multiple lines of data, and doing fancy
formatting of data is heavily frowned upon. Doing these things may get
you publically humiliated and your code rewritten without notice.
--
^ permalink raw reply
* Re: Paravirtualization on VMware's Platform [VMI].
From: Alok Kataria @ 2009-09-29 3:00 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Gerd Hoffmann, Ingo Molnar, Thomas Gleixner,
the arch/x86 maintainers, LKML, Jeremy Fitzhardinge, Chris Wright,
Rusty Russell, virtualization@lists.osdl.org, Greg KH,
Linus Torvalds, Andrew Morton
In-Reply-To: <4AC17018.4040600@zytor.com>
On Mon, 2009-09-28 at 19:25 -0700, H. Peter Anvin wrote:
> On 09/28/2009 05:45 PM, Alok Kataria wrote:
> > + bool "VMI Guest support [will be deprecated soon]"
> > + default n
>
> This is incorrect use of the word "deprecated"... it's *already*
> deprecated (a word which pretty much means the opposite of "recommended".)
>
> As far as "default n" is concerned... this is usually not necessary; "n"
> is the default unless anything else is specified.
How about this ? Thanks.
--
Mark VMI for removal in feature-removal-schedule.txt.
From: Alok N Kataria <akataria@vmware.com>
Add text in feature-removal.txt and also modify Kconfig to disable
vmi by default.
---
Documentation/feature-removal-schedule.txt | 30 ++++++++++++++++++++++++++++
arch/x86/Kconfig | 12 ++++++++---
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 89a47b5..d24c1af 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -451,3 +451,33 @@ Why: OSS sound_core grabs all legacy minors (0-255) of SOUND_MAJOR
will also allow making ALSA OSS emulation independent of
sound_core. The dependency will be broken then too.
Who: Tejun Heo <tj@kernel.org>
+
+----------------------------
+
+What: Support for VMware's guest paravirtuliazation technique [VMI] will be
+ dropped.
+When: 2.6.37 or earlier.
+Why: With the recent innovations in CPU hardware acceleration technologies
+ from Intel and AMD, VMware ran a few experiments to compare these
+ techniques to guest paravirtualization technique on VMware's platform.
+ These hardware assisted virtualization techniques have outperformed the
+ performance benefits provided by VMI in most of the workloads. VMware
+ expects that these hardware features will be ubiquitous in a couple of
+ years, as a result, VMware has started a phased retirement of this
+ feature from the hypervisor. We will be removing this feature from the
+ Kernel too. Right now we are targeting 2.6.37 but can retire earlier if
+ technical reasons ( read opportunity to remove major chunk of pvops)
+ arise.
+
+ Please note that VMI has always been an optimization and non-VMI kernels
+ still work fine on VMware's platform.
+ Latest versions of VMware's product which support VMI are,
+ Workstation 7.0 and VSphere 4.0 on ESX side, future maintainence
+ releases for these products will continue supporting VMI.
+
+ For more details about VMI retirement take a look at this,
+ http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html
+
+Who: Alok N Kataria <akataria@vmware.com>
+
+----------------------------
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f777aaf..44c1660 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -496,14 +496,20 @@ if PARAVIRT_GUEST
source "arch/x86/xen/Kconfig"
config VMI
- bool "VMI Guest support"
- select PARAVIRT
- depends on X86_32
+ bool "VMI Guest support [deprecated]"
+ depends on X86_32 && PARAVIRT
---help---
VMI provides a paravirtualized interface to the VMware ESX server
(it could be used by other hypervisors in theory too, but is not
at the moment), by linking the kernel to a GPL-ed ROM module
provided by the hypervisor.
+ As of September 2009, VMware has started a phased retirement of this
+ feature from VMware's products. Please see
+ feature-removal-schedule.txt for details.
+ If you are planning to enable this option, please note that you
+ cannot live migrate a VMI enabled VM to a future VMware product,
+ which doesn't support VMI. So if you expect your kernel to seamlessly
+ migrate to newer VMware products, keep this disabled.
config KVM_CLOCK
bool "KVM paravirtualized clock"
^ permalink raw reply related
* Re: [PATCH][rc1] cgroup: catch bad css refcnt at css_put
From: KAMEZAWA Hiroyuki @ 2009-09-29 2:55 UTC (permalink / raw)
To: Li Zefan
Cc: linux-kernel, akpm@linux-foundation.org, mingo,
balbir@linux.vnet.ibm.com, nishimura@mxp.nes.nec.co.jp,
menage@google.com
In-Reply-To: <4AC159D9.8020900@cn.fujitsu.com>
On Tue, 29 Sep 2009 08:50:33 +0800
Li Zefan <lizf@cn.fujitsu.com> wrote:
> KAMEZAWA Hiroyuki wrote:
> > This is a patch for checking css->refcnt's sanity at css_put().
> >
> > BTW, I noticed that...css->refcnt may overflow if used with memcg...
> > Now, refcnt is incremented per a page. Paul, do you have any idea ?
>
> atomic64_t ?
>
maybe. atomic_long_t ?
> But for 4K pagesize, it won't overflow until when the referenced
> memory is > 8T?
>
you're right. But there tends to be a few users who use unbelievable amounts
of memory in the world.
(Such user uses memcg or not is another problem ;)
> > (Ah, yes. "don't use css->refcnt per page" is maybe reasonable but
> > it will be big change..)
> >
> > ==
> > __css_put() doesn't check a bug as refcnt goes to minus.
> > I think it should be caught. This patch adds a check for it.
> >
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>
> Acked-by: Li Zefan <lizf@cn.fujitsu.com>
>
> > ---
> > kernel/cgroup.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > Index: linux-2.6.32-rc1/kernel/cgroup.c
> > ===================================================================
> > --- linux-2.6.32-rc1.orig/kernel/cgroup.c
> > +++ linux-2.6.32-rc1/kernel/cgroup.c
> > @@ -3708,8 +3708,10 @@ static void check_for_release(struct cgr
> > void __css_put(struct cgroup_subsys_state *css)
> > {
> > struct cgroup *cgrp = css->cgroup;
> > + int val;
> > rcu_read_lock();
> > - if (atomic_dec_return(&css->refcnt) == 1) {
> > + val = atomic_dec_return(&css->refcnt);
> > + if (val == 1) {
> > if (notify_on_release(cgrp)) {
> > set_bit(CGRP_RELEASABLE, &cgrp->flags);
> > check_for_release(cgrp);
> > @@ -3717,6 +3719,7 @@ void __css_put(struct cgroup_subsys_stat
> > cgroup_wakeup_rmdir_waiter(cgrp);
> > }
> > rcu_read_unlock();
> > + WARN_ON(val < 1);
>
> When we run into this, it'll probably fill up the syslog quickly,
> so I think WARN_ON_ONCE() is a bit better.
>
Hmm, ok. I'll rewrite.
Thanks,
-Kame
> > }
> >
>
^ permalink raw reply
* Re: [RFC][PATCH 8/10] memcg: clean up charge/uncharge anon
From: Daisuke Nishimura @ 2009-09-29 3:03 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: nishimura, linux-mm@kvack.org, balbir@linux.vnet.ibm.com
In-Reply-To: <20090929111828.6f9148d6.nishimura@mxp.nes.nec.co.jp>
Just to make sure.
> > Maybe there is something I don't understand..
> > IIUC, when page_remove_rmap() is called by do_wp_page(),
> > there must be pte(s) which points to the page and a pte is guarded by
> > page table lock. So, I think page_mapcount() > 0 before calling page_remove_rmap()
> > because there must be a valid pte, at least.
> >
> > Can this scenario happen ?
> I think so. I intended to mention this case :)
> I'm sorry for my vague explanation.
>
> > ==
> > Thread A. Thread B.
> >
> > do_wp_page() do_swap_page()
> > PageAnon(oldpage)
> > lock_page() lock_page()=> wait.
> > reuse = false.
> > unlock_page() get lock.
> > do copy-on-write
> > pte_same() == true
> > page_remove_rmap(oldpage) (mapcount goes to -1)
> > page_set_anon_rmap() (new anon rmap again)
> > ==
> > Then, oldpage's mapcount goes down to 0 and up to 1 immediately.
> >
I meant "process" not "thread".
I think this cannot happen in the case of threads, because these page_remove_rmap()
and page_set_anon_rmap() are called under pte lock(they share the pte).
Thanks,
Daisuke Nishimura.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: compat-wireless master-2009-09-28 breakage and suggested fixes
From: Luis R. Rodriguez @ 2009-09-29 2:55 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Luis Rodriguez, linux-wireless
In-Reply-To: <3ace41890909281935k284402f3q90b54ae20a636eeb@mail.gmail.com>
On Mon, Sep 28, 2009 at 07:35:22PM -0700, Hin-Tak Leung wrote:
> commit d0cf9c0dadcdc89a755bcb301cfc9c796eb28ccf
> Author: Stephen Hemminger <shemminger@vyatta.com>
> Date: Mon Aug 31 19:50:57 2009 +0000
>
> wireless: convert drivers to netdev_tx_t
>
> and the 2nd change due to this:
>
> commit 384912ed194e43c03ad1cdaa09b0b1e488c34d46
> Author: Marcel Holtmann <marcel@holtmann.org>
> Date: Mon Aug 31 21:08:19 2009 +0000
>
> net: Add DEVTYPE support for Ethernet based devices
>
> Both of these changes are traced back to changes in
> <linux/netdevice.h> , which compat-wireless does not ship. What's your
> policy on these kind of changes to compat-wireless?
> (the 2nd SET_NETDEV_DEVTYPE change probably can be spanned by an
> ifndef SET_NETDEV_DEVTYPE, and roll into
> "compat/patches/01-netdev.patch"? Should the first kind of change also
> go into compat/patches/01-netdev.patch?)
I don't see this yet on wireless-testing but it is on 2.6.32.
I backported this as follows. I'll push this out shortly.
From: Luis R. Rodriguez <lrodriguez@atheros.com>
Subject: [PATCH] Fix compilation against for 2.6.32 changes
2.6.32 added SET_NETDEV_DEVTYPE() and netdev_tx
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
compat/compat-2.6.32.h | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/compat/compat-2.6.32.h b/compat/compat-2.6.32.h
index f7081f2..418b521 100644
--- a/compat/compat-2.6.32.h
+++ b/compat/compat-2.6.32.h
@@ -31,6 +31,18 @@
#define dev_change_net_namespace(a, b, c) (-EOPNOTSUPP)
+#define SET_NETDEV_DEVTYPE(netdev, type)
+
+#ifdef __KERNEL__
+/* Driver transmit return codes */
+enum netdev_tx {
+ BACKPORT_NETDEV_TX_OK = NETDEV_TX_OK, /* driver took care of packet */
+ BACKPORT_NETDEV_TX_BUSY = NETDEV_TX_BUSY, /* driver tx path was busy*/
+ BACKPORT_NETDEV_TX_LOCKED = NETDEV_TX_LOCKED, /* driver tx lock was already taken */
+};
+typedef enum netdev_tx netdev_tx_t;
+#endif /* __KERNEL__ */
+
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,32)) */
#endif /* LINUX_26_32_COMPAT_H */
--
1.6.3.3
^ permalink raw reply related
* Re: [Openipmi-developer] Subject:[RFC Patch 1/2]IPMI/ACPI: Locate the IPMI system interface in ACPI namespace
From: ykzhao @ 2009-09-29 2:49 UTC (permalink / raw)
To: Corey Minyard
Cc: linux-acpi@vger.kernel.org,
openipmi-developer@lists.sourceforge.net, lenb@kernel.org
In-Reply-To: <4AC0CFC9.5050705@acm.org>
On Mon, 2009-09-28 at 23:01 +0800, Corey Minyard wrote:
> I've been looking for something like this for a while, but I didn't have
> a system that supports this, so I didn't have a way to test it. Thanks
> for doing this.
> Now to the code.
>
> In general, the code is not consistent in the way it uses blank lines
> between functions, if statements, etc. Can you make it consistent (and
> consistent with the rest of the driver)?
Agree with what you said. I will make it cleaner.
>
> Can you name all the functions starting with acpi_device or something
> like that to make their function clear?
>
> You need to run this through the kernel checkpatch script, it has some
> coding style problems.
>
> Can the old ACPI code go away? I understand that it will be redundant
> with these additions, but I'm not 100% sure.
Now we can't delete the old ACPI code.
The IPMI system interface can be located in ACPI by using the following
two ways:
1. locate it in SPMI table. This is done by using the old ACPI code.
2. locate it in ACPI device tree. This is realized by enumerating the
ACPI device tree. And this is done in my patch.
>
> Why not fill out an info structure directly in check_bmc_device and then
> call try_device_init_acpi() directly from there instead of creating a
> new structure device, allocating it, saving it in a list, etc. That
> would save some code and simplify things a little.
What you said is also OK. But it will be more clearer to divide into two
steps. One is to locate all the IPMI system intefaces in ACPI device
tree and register them.
Another concern is that it will get some mutex lock when calling the
function of acpi_walk_namespace(The check_bmc_device is the callback
function user in acpi_walk_namespace). To avoid that the mutex is locked
for too long time, IMO it is reasonable to divide two steps.
>
> + if (device_count > 1) {
> + printk(KERN_WARNING "More than one BMC device is found in "
> + "ACPI table\n");
> + printk(KERN_WARNING "Of course the BMC device will be "
> + "registered\n");
> + }
>
> It's legal (and possible) to have more than one BMC. I don't think this
> code is necessary.
Ok. I will delete this check.
>
> + if (resource->type == ACPI_RESOURCE_TYPE_MEMORY32 ||
> + resource->type == ACPI_RESOURCE_TYPE_MEMORY24 ||
> + resource->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
> + printk(KERN_DEBUG
> + "Can't handle the Memory32/24/fixed32 type\n");
> + printk(KERN_DEBUG "please send acpidump to "
> + "linux-acpi@vger.kernel.org\n");
> + return AE_OK;
> + }
>
> I don't really understand this, but debug is probably not the
> appropriate printk level for this if the user needs to see it. Also,
> what is going on here? Why isn't this supported?
In fact the above resource is parsed from the _CRS object defined in
IPMI device. The resource type for the following example is IO.
For example:
// Returns the "Current Resources"
Name(_CRS,
ResourceTemplate() {
IO(Decode16, 0xCA9, 0, 3) // Ports 0xCA9, 0xCAA & 0xCAB
}
)
For most IPMI system interfaces defined in ACPI device tree, the address
type will be IO.
But the IPMI 2.0 spec has an example definition of IPMI system
interface, in which the address type is 64-bit memory type.
In fact I don't find that the resource type is
TYPE_MEMORY32/24/FIXED_MEMORY32 for the _CRS object.
But I don't know whether it is necessary to support the above three
type. So when this message is complained, we can get the acpidump and
add the support for it.
Of course we can add the support of parsing the base address from the
MEMORY32/24/FIXED_MEMORY32 resource type.
>
> + /*
> + * If the resource type is ACPI_RESOURCE_IRQ, it is not
> + * supported.
> + */
>
> Why not? Is there something else that should be logged or done? Also, wouldn't you put this in an IRQ function?
OK. I will try to add the support of parsing the irq number when the
resource type is ACPI_RESOURCE_IRQ.
>
>
> + if (p_ipmi->interrupttype) {
> + /*
> + * If it already support the interrupt through GPE,
> + * it is unnecessary to get this interrupt again.
> + */
> + printk(KERN_DEBUG "Interrupt through GPE is already"
> + " supported.\n");
> + return AE_OK;
> + }
> + if (extended_irq->interrupt_count != 1) {
> + printk(KERN_DEBUG "Incorrect resource setting about "
> + "interrupt \n");
> + return AE_OK;
> + }
>
> I think the printks need to be a little clearer, and if the user needs
> to see them (like these are errors in the ACPI structures) they should
> be warnings or something like that.
Yes. The KERN_WARNING prefix should be used instead of KERN_DEBUG.
thanks.
>
> Thanks,
>
> -corey
>
> yakui.zhao@intel.com wrote:
> > According to the IPMI 2.0 spec the IPMI system interface can be located with
> > ACPI. One is located in SPMI table(Service Processor Management Interface
> > table). Another is located in ACPI namespace.
> > This patch is to locate the IPMI system interface in ACPI namespace and
> > register it.
> > It includes the following two steps:
> > 1. enumerate the ACPI device tree to find the IPMI system interface
> > The IPMI device type is IPI0001. When the device is found, it
> > will continue to parse the corresponding resources.
> > For example:
> > interface type (KCS, BT, SMIC) (SSIF is not supported)
> > interrupt number and type (_GPE or GSI)
> > Memory or IO base address
> > 2. register the IPMI system interface.
> >
> >
> > Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
> > ---
> > drivers/char/ipmi/ipmi_si_intf.c | 360 +++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 360 insertions(+)
> >
> > Index: linux-2.6/drivers/char/ipmi/ipmi_si_intf.c
> > ===================================================================
> > --- linux-2.6.orig/drivers/char/ipmi/ipmi_si_intf.c 2009-09-21 16:49:29.000000000 +0800
> > +++ linux-2.6/drivers/char/ipmi/ipmi_si_intf.c 2009-09-28 11:43:53.000000000 +0800
> > @@ -1813,6 +1813,35 @@
> > * are no more.
> > */
> > static int acpi_failure;
> > +static LIST_HEAD(acpi_ipmi);
> > +
> > +struct acpi_device_ipmi {
> > + struct list_head link;
> > + u8 interfacetype;
> > + /*
> > + * Bit 0 - SCI interrupt supported
> > + * Bit 1 - I/O APIC/SAPIC
> > + */
> > + u8 interrupttype;
> > + /*
> > + * If bit 0 of InterruptType is set, then this is the SCI
> > + * interrupt in the GPEx_STS register.
> > + */
> > + u8 gpe;
> > + /*
> > + * If bit 1 of InterruptType is set, then this is the I/O
> > + * APIC/SAPIC interrupt.
> > + */
> > + u32 global_interrupt;
> > +
> > + /* The actual register address. */
> > + struct acpi_generic_address addr;
> > + struct acpi_generic_address sm_addr;
> > +
> > + u8 ipmi_revision;
> > + u8 resource_count;
> > + struct device *dev;
> > +};
> >
> > /* For GPE-type interrupts. */
> > static u32 ipmi_acpi_gpe(void *context)
> > @@ -2001,7 +2030,337 @@
> >
> > return 0;
> > }
> > +static __devinit int try_init_acpi_device(struct acpi_device_ipmi *spmi)
> > +{
> > + struct smi_info *info;
> > + u8 addr_space;
> > +
> > + if (spmi->addr.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY)
> > + addr_space = IPMI_MEM_ADDR_SPACE;
> > + else
> > + addr_space = IPMI_IO_ADDR_SPACE;
> > +
> > + info = kzalloc(sizeof(*info), GFP_KERNEL);
> > + if (!info) {
> > + printk(KERN_ERR "ipmi_si: Could not allocate SI data (3)\n");
> > + return -ENOMEM;
> > + }
> > +
> > + info->addr_source = "ACPI";
> > +
> > + /* Figure out the interface type. */
> > + switch (spmi->interfacetype) {
> > + case 1: /* KCS */
> > + info->si_type = SI_KCS;
> > + break;
> > + case 2: /* SMIC */
> > + info->si_type = SI_SMIC;
> > + break;
> > + case 3: /* BT */
> > + info->si_type = SI_BT;
> > + break;
> > + default:
> > + printk(KERN_INFO "ipmi_si: Unknown ACPI/SPMI SI type %d\n",
> > + spmi->interfacetype);
> > + kfree(info);
> > + return -EIO;
> > + }
> > +
> > + if (spmi->interrupttype & 1) {
> > + /* We've got a GPE interrupt. */
> > + info->irq = spmi->gpe;
> > + info->irq_setup = acpi_gpe_irq_setup;
> > + } else if (spmi->interrupttype & 2) {
> > + /* We've got an APIC/SAPIC interrupt. */
> > + info->irq = spmi->global_interrupt;
> > + info->irq_setup = std_irq_setup;
> > + } else {
> > + /* Use the default interrupt setting. */
> > + info->irq = 0;
> > + info->irq_setup = NULL;
> > + }
> > +
> > + if (spmi->addr.bit_width) {
> > + /* A (hopefully) properly formed register bit width. */
> > + info->io.regspacing = spmi->addr.bit_width / 8;
> > + } else {
> > + info->io.regspacing = DEFAULT_REGSPACING;
> > + }
> > + info->io.regsize = info->io.regspacing;
> > + info->io.regshift = spmi->addr.bit_offset;
> > +
> > + if (spmi->addr.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
> > + info->io_setup = mem_setup;
> > + info->io.addr_type = IPMI_MEM_ADDR_SPACE;
> > + } else if (spmi->addr.space_id == ACPI_ADR_SPACE_SYSTEM_IO) {
> > + info->io_setup = port_setup;
> > + info->io.addr_type = IPMI_IO_ADDR_SPACE;
> > + } else {
> > + kfree(info);
> > + printk(KERN_WARNING
> > + "ipmi_si: Unknown ACPI I/O Address type\n");
> > + return -EIO;
> > + }
> > + info->io.addr_data = spmi->addr.address;
> > + info->dev = spmi->dev;
> > +
> > + try_smi_init(info);
> > +
> > + return 0;
> > +}
> > +static acpi_status
> > +bmc_parse_io_ports(struct acpi_resource *resource, void *context)
> > +{
> > + struct acpi_device_ipmi *p_ipmi = context;
> > +
> > + /*
> > + * If the resource type is ACPI_RESOURCE_IRQ, it is not
> > + * supported.
> > + */
> > + if (resource->type == ACPI_RESOURCE_TYPE_EXTENDED_IRQ) {
> > + struct acpi_resource_extended_irq *extended_irq;
> > + extended_irq = &resource->data.extended_irq;
> > + if (p_ipmi->interrupttype) {
> > + /*
> > + * If it already support the interrupt through GPE,
> > + * it is unnecessary to get this interrupt again.
> > + */
> > + printk(KERN_DEBUG "Interrupt through GPE is already"
> > + " supported.\n");
> > + return AE_OK;
> > + }
> > + if (extended_irq->interrupt_count != 1) {
> > + printk(KERN_DEBUG "Incorrect resource setting about "
> > + "interrupt \n");
> > + return AE_OK;
> > + }
> > + p_ipmi->global_interrupt = extended_irq->interrupts[0];
> > + if (p_ipmi->global_interrupt) {
> > + /* GSI interrupt type */
> > + p_ipmi->interrupttype |= 0x02;
> > + }
> > + return AE_OK;
> > + }
> > + if (resource->type == ACPI_RESOURCE_TYPE_IO ||
> > + resource->type == ACPI_RESOURCE_TYPE_FIXED_IO) {
> > + u16 address;
> > + struct acpi_resource_io *io;
> > + struct acpi_resource_fixed_io *fixed_io;
> > +
> > + fixed_io = &resource->data.fixed_io;
> > + if (p_ipmi->resource_count) {
> > + /*
> > + * Multiply definitions of IO/memory address are
> > + * obtained. It is incorrect. We will continue
> > + * to use the first IO/memory definition.
> > + * If not correct, please fix me.
> > + */
> > + return AE_OK;
> > + }
> > + if (resource->type == ACPI_RESOURCE_TYPE_IO) {
> > + io = &resource->data.io;
> > + if (!io->minimum) {
> > + /* when IO address is zero, return */
> > + return AE_OK;
> > + }
> > + address = io->minimum;
> > + } else {
> > + fixed_io = &resource->data.fixed_io;
> > + if (!fixed_io->address)
> > + return AE_OK;
> > + address = fixed_io->address;
> > + }
> > + p_ipmi->resource_count++;
> > + p_ipmi->addr.space_id = ACPI_ADR_SPACE_SYSTEM_IO;
> > + p_ipmi->addr.address = address;
> > + return AE_OK;
> > + }
> > +
> > + if (resource->type == ACPI_RESOURCE_TYPE_MEMORY32 ||
> > + resource->type == ACPI_RESOURCE_TYPE_MEMORY24 ||
> > + resource->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
> > + printk(KERN_DEBUG
> > + "Can't handle the Memory32/24/fixed32 type\n");
> > + printk(KERN_DEBUG "please send acpidump to "
> > + "linux-acpi@vger.kernel.org\n");
> > + return AE_OK;
> > + }
> > + if (resource->type == ACPI_RESOURCE_TYPE_ADDRESS16 ||
> > + resource->type == ACPI_RESOURCE_TYPE_ADDRESS32 ||
> > + resource->type == ACPI_RESOURCE_TYPE_ADDRESS64) {
> > + struct acpi_resource_address64 address64;
> > + acpi_resource_to_address64(resource, &address64);
> > + if (p_ipmi->resource_count) {
> > + /*
> > + * Multiply definitions of IO/memory address are
> > + * obtained. It is incorrect. We will continue
> > + * to use the first IO/memory definition.
> > + * If not correct, please fix me.
> > + */
> > + return AE_OK;
> > + }
> > + if (address64.resource_type != ACPI_MEMORY_RANGE &&
> > + address64.resource_type != ACPI_IO_RANGE) {
> > + /* ignore the incorrect resource type */
> > + return AE_OK;
> > + }
> > + p_ipmi->addr.address = address64.minimum;
> > + p_ipmi->resource_count++;
> > + if (address64.resource_type == ACPI_MEMORY_RANGE)
> > + p_ipmi->addr.space_id = ACPI_ADR_SPACE_SYSTEM_MEMORY;
> > + else
> > + p_ipmi->addr.space_id = ACPI_ADR_SPACE_SYSTEM_IO;
> > +
> > + return AE_OK;
> > + }
> >
> > + return AE_OK;
> > +}
> > +
> > +/*
> > + * parse_bmc_resource -- parse the BMC resources from ACPI
> > + * @p_ipmi: the memory to store the BCM resource
> > + * @handle: ACPI device handle
> > + */
> > +static int parse_bmc_resource(struct acpi_device_ipmi *p_ipmi,
> > + acpi_handle handle)
> > +{
> > + int parse_ok = false;
> > + unsigned long long temp_data;
> > + acpi_status status;
> > +
> > + /* According to IPMI spec there should exist the _IFT method
> > + * for the IPMI device. So when there is no _IFT, it is regarded
> > + * as the incorrect BMC device and won't parse the resource again.
> > + */
> > + status = acpi_evaluate_integer(handle, "_IFT", NULL, &temp_data);
> > + if (ACPI_FAILURE(status))
> > + return parse_ok;
> > +
> > + p_ipmi->interfacetype = temp_data;
> > + /* Figure out the interface type. If the interface type is not
> > + * KCS/SMIC/BT, it is regared as the incorrect IPMI device.
> > + * Of course the SSIF interface type is also defined, but we
> > + * can't handle it. So it is not supported */
> > + switch (temp_data) {
> > + case 1: /* KCS */
> > + case 2: /* SMIC */
> > + case 3: /* BT */
> > + break;
> > + default:
> > + printk(KERN_INFO "ipmi_si: Unknown ACPI/SPMI SI type %d\n",
> > + p_ipmi->interfacetype);
> > + return parse_ok;
> > + }
> > + /* check whether there exists the _GPE method. If it exists, it
> > + * means that interrupt through GPE is supported.
> > + */
> > + temp_data = 0;
> > + status = acpi_evaluate_integer(handle, "_GPE", NULL, &temp_data);
> > + if (ACPI_SUCCESS(status)) {
> > + p_ipmi->gpe = temp_data;
> > + /* set the GPE interrupt type */
> > + p_ipmi->interrupttype |= 0x01;
> > + }
> > + /* get the IPMI revision */
> > + temp_data = 0;
> > + status = acpi_evaluate_integer(handle, "_SRV", NULL, &temp_data);
> > + if (ACPI_SUCCESS(status))
> > + p_ipmi->ipmi_revision = temp_data;
> > +
> > + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> > + bmc_parse_io_ports, p_ipmi);
> > + if (ACPI_FAILURE(status)) {
> > + printk(KERN_WARNING "Can't parse the _CRS object \n");
> > + return parse_ok;
> > + }
> > + if (!p_ipmi->resource_count) {
> > + /* The incorrect IO/Memory address is parsed */
> > + printk(KERN_WARNING "Incorrect IO/Memory address is parsed\n");
> > + return parse_ok;
> > + }
> > + parse_ok = true;
> > +
> > + return parse_ok;
> > +}
> > +
> > +const struct acpi_device_id ipmi_ids[] = {
> > + {ACPI_VIDEO_HID, 0},
> > + {"", 0},
> > +};
> > +/*
> > + * check_bmc_device -- check whether @handle is a BMC device and then
> > + * get its corresponding resource. For example: IO/Mem
> > + * address, interface type
> > + * @handle: ACPI device handle
> > + * @level : depth in the ACPI namespace tree
> > + * @context: the number of bmc device. In theory there is not more than
> > + * one ACPI BMC device.
> > + * @rv: a return value to fill if desired (Not use)
> > + */
> > +static acpi_status
> > +check_bmc_device(acpi_handle handle, u32 level, void *context,
> > + void **return_value)
> > +{
> > + struct acpi_device *acpi_dev;
> > + struct acpi_device_ipmi *p_ipmi = NULL;
> > + int *count = (int *)context;
> > +
> > + acpi_dev = NULL;
> > + /* Get the acpi device for device handle */
> > + if (acpi_bus_get_device(handle, &acpi_dev) || !acpi_dev) {
> > + /* If there is no ACPI device for handle, return */
> > + return AE_OK;
> > + }
> > +
> > + if (acpi_match_device_ids(acpi_dev, ipmi_ids))
> > + return AE_OK;
> > +
> > + p_ipmi = kzalloc(sizeof(*p_ipmi), GFP_KERNEL);
> > + if (!p_ipmi) {
> > + printk(KERN_DEBUG "Can't allocate memory for IPMI device\n");
> > + return AE_OK;
> > + }
> > + p_ipmi->dev = &acpi_dev->dev;
> > + if (!parse_bmc_resource(p_ipmi, handle)) {
> > + kfree(p_ipmi);
> > + } else {
> > + list_add_tail(&p_ipmi->link, &acpi_ipmi);
> > + *count = *count + 1;
> > + }
> > +
> > + return AE_OK;
> > +}
> > +static __devinit void acpi_device_find_bmc(void)
> > +{
> > + acpi_status status;
> > + int device_count = 0;
> > + struct acpi_device_ipmi *p_ipmi, *p_ipmi2;
> > +
> > + if (acpi_disabled)
> > + return;
> > +
> > + status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
> > + ACPI_UINT32_MAX,
> > + check_bmc_device, &device_count, NULL);
> > + if (!device_count) {
> > + /* when no IPMI device is found in ACPI namespace, return */
> > + return;
> > + }
> > + if (device_count > 1) {
> > + printk(KERN_WARNING "More than one BMC device is found in "
> > + "ACPI table\n");
> > + printk(KERN_WARNING "Of course the BMC device will be "
> > + "registered\n");
> > + }
> > + list_for_each_entry_safe(p_ipmi, p_ipmi2, &acpi_ipmi, link) {
> > + try_init_acpi_device(p_ipmi);
> > + list_del(&p_ipmi->link);
> > + kfree(p_ipmi);
> > + }
> > +
> > + return;
> > +}
> > static __devinit void acpi_find_bmc(void)
> > {
> > acpi_status status;
> > @@ -2022,6 +2381,7 @@
> >
> > try_init_acpi(spmi);
> > }
> > + acpi_device_find_bmc();
> > }
> > #endif
> >
> >
> > ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry® Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9-12, 2009. Register now!
> > http://p.sf.net/sfu/devconf
> > _______________________________________________
> > Openipmi-developer mailing list
> > Openipmi-developer@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openipmi-developer
> >
> >
>
^ permalink raw reply
* Re: private ioctls in input driver
From: Barry Song @ 2009-09-29 2:50 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Trilok Soni, linux-input
In-Reply-To: <5d5443650909281005u37503ab0rc6b62effe73f8046@mail.gmail.com>
On Tue, Sep 29, 2009 at 1:05 AM, Trilok Soni <soni.trilok@gmail.com> wrote:
>
> Hi Dmitry,
>
> On Mon, Sep 28, 2009 at 10:32 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Fri, Sep 25, 2009 at 02:21:40PM +0530, Trilok Soni wrote:
> >> Hi Dmitry,
> >>
> >> On Fri, Sep 25, 2009 at 9:32 AM, Dmitry Torokhov
> >> <dmitry.torokhov@gmail.com> wrote:
> >> > Hi Trilok,
> >> >
> >> > On Thu, Sep 24, 2009 at 05:21:09PM +0530, Trilok Soni wrote:
> >> >> Hi Dmitry,
> >> >>
> >> >> Is there any way of creating private ioctls in the input driver? I see
> >> >> that all the input framework handled
> >> >> by the framework itself and there is no way to call private ioctls if
> >> >> it doesn't match the standard ones.
> >> >>
> >> >
> >> > You are right, event devices only allow standard ioctl. What kind of
> >> > ictl are you considering? Normally device-specific controls are done via
> >> > sysfs attached to the parent device (see atkbd, psmouse, etc).
> >>
> >> sysfs might good for purpose when you can associate one file per
> >> value, so for more data we can't simply create one file per the data.
> >> Say five fingers touch data (I know we have MT_* support but here it
> >> is just for example) , say id, x, y, z etc., per finger, then we can't
> >> create one file for each of them.
> >
> > Maybe use configfs if sysfs is not suitable? I am not sure.
> >
> > I would like to not-have driver-specific ioctls in evdev/input core but
> > rather keep them with device/driver itself. Input core should only have
> > stuff that makes sense for multiple devices.
>
> I mean on the similar line only, we won't add any driver-specific
> ioctls in evdev/input core, but just transfer their control to resp.
> device/driver itself, may be similar in the line of how v4l2 does.
Sometimes, we really have this kind of requirement. Now there are more
and more kinds of input devices. Some devices have special controls
which should not belong to generic input layer. How about add a case
item in evdev_do_ioctl() to handle these commands and call drivers'
ioctl directly?
>
> --
> ---Trilok Soni
> http://triloksoni.wordpress.com
> http://www.linkedin.com/in/triloksoni
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Bluetooth: Enable auto sleep mode for btmrvl driver
From: Bing Zhao @ 2009-09-29 2:50 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Bing Zhao, Amitkumar Karwar
From: Amitkumar Karwar <akarwar@marvell.com>
The auto sleep mode for btmrvl driver is not enabled by default.
This patch enables auto sleep mode when card is probed.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/bluetooth/btmrvl_drv.h | 1 +
drivers/bluetooth/btmrvl_main.c | 56 +++++++++++++++++++++++---------------
drivers/bluetooth/btmrvl_sdio.c | 2 +
3 files changed, 37 insertions(+), 22 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_drv.h b/drivers/bluetooth/btmrvl_drv.h
index 411c7a7..523d197 100644
--- a/drivers/bluetooth/btmrvl_drv.h
+++ b/drivers/bluetooth/btmrvl_drv.h
@@ -131,6 +131,7 @@ void btmrvl_check_evtpkt(struct btmrvl_private *priv, struct sk_buff *skb);
int btmrvl_process_event(struct btmrvl_private *priv, struct sk_buff *skb);
int btmrvl_send_module_cfg_cmd(struct btmrvl_private *priv, int subcmd);
+int btmrvl_enable_ps(struct btmrvl_private *priv);
int btmrvl_prepare_command(struct btmrvl_private *priv);
#ifdef CONFIG_DEBUG_FS
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index e605563..43b5b68 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -189,6 +189,39 @@ int btmrvl_send_module_cfg_cmd(struct btmrvl_private *priv, int subcmd)
}
EXPORT_SYMBOL_GPL(btmrvl_send_module_cfg_cmd);
+int btmrvl_enable_ps(struct btmrvl_private *priv)
+{
+ struct sk_buff *skb;
+ struct btmrvl_cmd *cmd;
+ int ret = 0;
+
+ skb = bt_skb_alloc(sizeof(*cmd), GFP_ATOMIC);
+ if (skb == NULL) {
+ BT_ERR("No free skb");
+ return -ENOMEM;
+ }
+
+ cmd = (struct btmrvl_cmd *) skb_put(skb, sizeof(*cmd));
+ cmd->ocf_ogf = cpu_to_le16(hci_opcode_pack(OGF,
+ BT_CMD_AUTO_SLEEP_MODE));
+ cmd->length = 1;
+
+ if (priv->btmrvl_dev.psmode)
+ cmd->data[0] = BT_PS_ENABLE;
+ else
+ cmd->data[0] = BT_PS_DISABLE;
+
+ bt_cb(skb)->pkt_type = MRVL_VENDOR_PKT;
+
+ skb->dev = (void *) priv->btmrvl_dev.hcidev;
+ skb_queue_head(&priv->adapter->tx_queue, skb);
+
+ BT_DBG("Queue PSMODE Command:%d", cmd->data[0]);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(btmrvl_enable_ps);
+
static int btmrvl_enable_hs(struct btmrvl_private *priv)
{
struct sk_buff *skb;
@@ -258,28 +291,7 @@ int btmrvl_prepare_command(struct btmrvl_private *priv)
if (priv->btmrvl_dev.pscmd) {
priv->btmrvl_dev.pscmd = 0;
-
- skb = bt_skb_alloc(sizeof(*cmd), GFP_ATOMIC);
- if (skb == NULL) {
- BT_ERR("No free skb");
- return -ENOMEM;
- }
-
- cmd = (struct btmrvl_cmd *) skb_put(skb, sizeof(*cmd));
- cmd->ocf_ogf = cpu_to_le16(hci_opcode_pack(OGF, BT_CMD_AUTO_SLEEP_MODE));
- cmd->length = 1;
-
- if (priv->btmrvl_dev.psmode)
- cmd->data[0] = BT_PS_ENABLE;
- else
- cmd->data[0] = BT_PS_DISABLE;
-
- bt_cb(skb)->pkt_type = MRVL_VENDOR_PKT;
-
- skb->dev = (void *) priv->btmrvl_dev.hcidev;
- skb_queue_head(&priv->adapter->tx_queue, skb);
-
- BT_DBG("Queue PSMODE Command:%d", cmd->data[0]);
+ btmrvl_enable_ps(priv);
}
if (priv->btmrvl_dev.hscmd) {
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 5b33b85..d6aaf51 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -930,6 +930,8 @@ static int btmrvl_sdio_probe(struct sdio_func *func,
priv->hw_wakeup_firmware = btmrvl_sdio_wakeup_fw;
btmrvl_send_module_cfg_cmd(priv, MODULE_BRINGUP_REQ);
+ priv->btmrvl_dev.psmode = 1;
+ btmrvl_enable_ps(priv);
return 0;
--
1.5.4.3
^ permalink raw reply related
* Re: [Fastboot] kexec - 2.6.14 - loads BIOS again
From: Prabhakar K. @ 2009-09-29 2:48 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: fastboot, Kexec Mailing List
In-Reply-To: <m1tyympope.fsf@fess.ebiederm.org>
[-- Attachment #1.1: Type: text/plain, Size: 2119 bytes --]
From: Eric W. Biederman <ebiederm@xmission.com>
Subject: Re: [Fastboot] kexec - 2.6.14 - loads BIOS again
To: "Prabhakar K." <krishkar99@yahoo.com>
Cc: "Kexec Mailing List" <kexec@lists.infradead.org>, fastboot@lists.linux-foundation.org
Date: Tuesday, September 29, 2009, 6:11 AM
"Prabhakar K." <krishkar99@yahoo.com> writes:
>> Hi - After my previous posting I was able to make some progress.
>>
>> When I do
>>
>> kexec -l vmlinux --append="init 1 root=/dev/hda2" --console-serial
>>
>> and
>> kexec -e,
>>
>> I get message:
>>
>> Starting new kernel
>> I'm in purgatory
>>
>> And after that it still boots from BIOS (to the same first kernel).
>>
>> Whats the problem here?
>
> I would recommend instrumenting up purgatory and then your target kernel.
>
> It is quite possible the problem is in your backport.
>
>>>>>
> I have instrumented the purgatory code. when I run kexec -e, It hangs for a
> while at
> sha256_starts(&ctx); in the function verify_sha256_digest(), and then reboots
> to the first kernel (from BIOS). I have put debug prints in sha256_starts, but
> none of those are executed.
>
> Interestingly, the same function sha256_starts is executed during kexec -l,
> which is called as part of update_purgatory( )( when my_load( ) is called from
> kexec.c).
> so its surprise why the same function is giving problems when kexec -e is run.
Do you by any chance have a watchdog you are not petting?
>> Yes, we do have software watchdog and hardware watchdog. I disabled software watchdog and I think the reason for resetting to the first kernel can be explained due to hardware watchdog kicking in.
To try out a different version of the kexec, I took kexec version 20080227 from http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/and instrumented that code as well. With this, I was able to see the sha 256 verification done during kexec -e and also the post verification of purgatory code. And it hangs there (does not reboot to the first kernel).
So, any conclusions based on these ? Please CC me in reply. Thanks !!
Eric
[-- Attachment #1.2: Type: text/html, Size: 3034 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* [PATCH] Bluetooth: Removal of unused variable in btmrvl driver
From: Bing Zhao @ 2009-09-29 2:43 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Bing Zhao, Rahul Tank
From: Rahul Tank <rahult@marvell.com>
This patch removes unused variable "drvdbg" from btmrvl_debugfs_data
structure.
Signed-off-by: Rahul Tank <rahult@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/bluetooth/btmrvl_debugfs.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_debugfs.c b/drivers/bluetooth/btmrvl_debugfs.c
index 4617bd1..d43b5cb 100644
--- a/drivers/bluetooth/btmrvl_debugfs.c
+++ b/drivers/bluetooth/btmrvl_debugfs.c
@@ -29,7 +29,6 @@ struct btmrvl_debugfs_data {
struct dentry *root_dir, *config_dir, *status_dir;
/* config */
- struct dentry *drvdbg;
struct dentry *psmode;
struct dentry *pscmd;
struct dentry *hsmode;
--
1.5.4.3
^ permalink raw reply related
* compat-wireless master-2009-09-28 breakage and suggested fixes
From: Hin-Tak Leung @ 2009-09-29 2:35 UTC (permalink / raw)
To: Luis R. Rodriguez, linux-wireless
Hi Luis,
A couple of breakages against current wireless testing head:
compat-release - master-2009-09-23-1-gd1e5747
git-describe v2.6.32-rc1-39226-g63dbea4
master-tag master-2009-09-28
-----------
make[1]: Entering directory `/usr/src/kernels/2.6.30.8-67.fc11.x86_64'
CC [M] /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/main.o
In file included from
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/main.c:29:
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/ieee80211_i.h:1053:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
‘ieee80211_monitor_start_xmit’
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/ieee80211_i.h:1055:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
‘ieee80211_subif_start_xmit’
make[3]: *** [/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/main.o]
Error 1
make[2]: *** [/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211] Error 2
make[1]: *** [_module_/home/Hin-Tak/tmp-git/compat-wireless-2.6] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.30.8-67.fc11.x86_64'
make: *** [modules] Error 2
----------
----------
CC [M] /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/iface.o
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/iface.c: In
function ‘ieee80211_if_add’:
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/iface.c:815:
error: implicit declaration of function ‘SET_NETDEV_DEVTYPE’
make[3]: *** [/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/iface.o]
Error 1
make[2]: *** [/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211] Error 2
make[1]: *** [_module_/home/Hin-Tak/tmp-git/compat-wireless-2.6] Error 2
----------
The first error can be fixed by inserting the netdev_tx_t enum:
----------------
$ diff -u ../wireless-testing/net/mac80211/ieee80211_i.h
net/mac80211/ieee80211_i.h
--- ../wireless-testing/net/mac80211/ieee80211_i.h 2009-09-29
01:21:11.000000000 +0100
+++ net/mac80211/ieee80211_i.h 2009-09-29 02:43:26.000000000 +0100
@@ -28,6 +28,24 @@
#include "key.h"
#include "sta_info.h"
+#ifdef NETDEV_TX_OK
+#undef NETDEV_TX_OK
+#endif
+#ifdef NETDEV_TX_BUSY
+#undef NETDEV_TX_BUSY
+#endif
+#ifdef NETDEV_TX_LOCKED
+#undef NETDEV_TX_LOCKED
+#endif
+
+/* Driver transmit return codes */
+enum netdev_tx {
+ NETDEV_TX_OK = 0, /* driver took care of packet */
+ NETDEV_TX_BUSY, /* driver tx path was busy*/
+ NETDEV_TX_LOCKED = -1, /* driver tx lock was already taken */
+};
+typedef enum netdev_tx netdev_tx_t;
+
struct ieee80211_local;
/* Maximum number of broadcast/multicast frames to buffer when some of the
------------------
The 2nd by adding SET_NETDEV_DEVTYPE():
----------
--- ../wireless-testing/net/mac80211/iface.c 2009-09-29 01:21:11.000000000 +0100
+++ net/mac80211/iface.c 2009-09-29 02:50:54.000000000 +0100
@@ -22,6 +22,8 @@
#include "led.h"
#include "driver-ops.h"
+#define SET_NETDEV_DEVTYPE(net, devtype) ((net)->dev.type = (devtype))
+
/**
* DOC: Interface list locking
*
-------------
The first change is due to this:
commit d0cf9c0dadcdc89a755bcb301cfc9c796eb28ccf
Author: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon Aug 31 19:50:57 2009 +0000
wireless: convert drivers to netdev_tx_t
and the 2nd change due to this:
commit 384912ed194e43c03ad1cdaa09b0b1e488c34d46
Author: Marcel Holtmann <marcel@holtmann.org>
Date: Mon Aug 31 21:08:19 2009 +0000
net: Add DEVTYPE support for Ethernet based devices
Both of these changes are traced back to changes in
<linux/netdevice.h> , which compat-wireless does not ship. What's your
policy on these kind of changes to compat-wireless?
(the 2nd SET_NETDEV_DEVTYPE change probably can be spanned by an
ifndef SET_NETDEV_DEVTYPE, and roll into
"compat/patches/01-netdev.patch"? Should the first kind of change also
go into compat/patches/01-netdev.patch?)
^ permalink raw reply
* Re: [PATCH] ahci: display all AHCI 1.3 HBA capability flags (v2)
From: Robert Hancock @ 2009-09-29 2:34 UTC (permalink / raw)
To: Jeff Garzik; +Cc: ide, Tejun Heo
In-Reply-To: <4AB6B487.3010907@gmail.com>
On Sun, Sep 20, 2009 at 5:02 PM, Robert Hancock <hancockrwd@gmail.com> wrote:
> Update the AHCI driver to display all of the HBA capabilities defined in the
> AHCI 1.3 specification. Some of these are in a new CAP2 (HBA Capabilities
> Extended) register which is only defined on AHCI 1.2 or later. The spec says
> that undefined registers should always return 0 on read, but to be safe we
> assume a value of 0 unless the controller reports AHCI version 1.2 or later.
> The value can also be retrieved through sysfs as with the existing capability
> field.
>
> For example, on an Intel Ibex Peak (PCH) controller:
>
> ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pmp pio slum part ems
> sxs apst
>
> We don't do anything special with the new flags yet.
>
> Also, change the code that displays the flags to use the same bit enumerations
> that are used to control actual operation.
>
> Signed-off-by: Robert Hancock <hancockrwd@gmail.com>
>
Ping?
^ permalink raw reply
* Re: regression in page writeback
From: Wu Fengguang @ 2009-09-29 2:32 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Dave Chinner, Chris Mason, Andrew Morton, Peter Zijlstra,
Li, Shaohua, linux-kernel@vger.kernel.org,
richard@rsk.demon.co.uk, jens.axboe@oracle.com
In-Reply-To: <20090928130804.GA25880@infradead.org>
On Mon, Sep 28, 2009 at 09:08:04PM +0800, Christoph Hellwig wrote:
> On Mon, Sep 28, 2009 at 03:15:07PM +0800, Wu Fengguang wrote:
> > + if (!PageActive(page))
> > + SetPageReclaim(page);
> > + err = mapping->a_ops->writepage(page, wbc);
> > + if (err < 0)
> > + handle_write_error(mapping, page, res);
> > + if (err == AOP_WRITEPAGE_ACTIVATE) {
> > + ClearPageReclaim(page);
> > + res = PAGE_ACTIVATE;
> > + break;
> > + }
>
> This should help a bit for XFS as it historically does multi-page
> writeouts from ->writepages (and apprently btrfs that added some
->writepage ?
> write-around recently?) but not those brave filesystems only
> implementing the multi-page writeout from writepages as designed.
Thanks. Just tried write_cache_pages(), looks simple. Need to further
convert all aops->writepages to support lumpy pageout :)
> But really, the best would be to leave the writeout to the flusher
> threads and just reclaim the clean pages from the VM.
Yup, that's much larger behavior change, and could be pursued as a
long term goal.
Thanks,
Fengguang
^ permalink raw reply
* Re: Paravirtualization on VMware's Platform [VMI].
From: H. Peter Anvin @ 2009-09-29 2:25 UTC (permalink / raw)
To: akataria
Cc: Gerd Hoffmann, Ingo Molnar, Thomas Gleixner,
the arch/x86 maintainers, LKML, Jeremy Fitzhardinge, Chris Wright,
Rusty Russell, virtualization@lists.osdl.org, Greg KH,
Linus Torvalds, Andrew Morton
In-Reply-To: <1254185107.13456.32.camel@ank32.eng.vmware.com>
On 09/28/2009 05:45 PM, Alok Kataria wrote:
> + bool "VMI Guest support [will be deprecated soon]"
> + default n
This is incorrect use of the word "deprecated"... it's *already*
deprecated (a word which pretty much means the opposite of "recommended".)
As far as "default n" is concerned... this is usually not necessary; "n"
is the default unless anything else is specified.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [PATCH] ACPI: Add EC event managerment functions into header file
From: Ike Panhc @ 2009-09-29 2:28 UTC (permalink / raw)
To: Alexey Starikovskiy; +Cc: linux-acpi, linux-kernel
In-Reply-To: <4AC135AC.2010407@gmail.com>
I had sent a new driver for Lenovo SL series laptops [1], and it uses those
functions to detect hotkeys. Since it has been exported for other modules,
I think it is reasonable to write in header file to make sure everyone has
the same definition.
[1] http://patchwork.kernel.org/patch/49912/
Alexey Starikovskiy wrote:
> These functions are never used anywhere, but sbshc.c.
> What is the reason to make them known to the whole kernel?
>
> Ike Panhc пишет:
>> There are two functions for add/remove EC query handler functions, which
>> exported without any definition in header files
>>
>> Patch against current checkout of linux-acpi 2.6.31 is below.
>>
>> In this patch, the following definitions has been added into
>> include/linux/acpi.h
>> - typedef: acpi_ec_query_func
>> - struct: acpi_ec
>> - fucntions: acpi_ec_add_query_handler, acpi_ec_remove_query_handler
>>
>> And the following definitions has been removed from driver/acpi/ec.c
>> - typedef: acpi_ec_query_func
>> - struct: acpi_ec
>>
>> So that, the following externs and typedef could be remove from
>> drivers/acpi/sbshc.c
>> - typedef: acpi_ec_query_func
>> - externs: acpi_ec_add_query_handler, acpi_ec_remove_query_handler
>>
>> Signed-off-by: Ike Panhc <ike.pan@canonical.com>
>> ---
>> drivers/acpi/ec.c | 22 +++++-----------------
>> drivers/acpi/sbshc.c | 8 --------
>> include/linux/acpi.h | 21 +++++++++++++++++++++
>> 3 files changed, 26 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
>> index f707960..8950c4f 100644
>> --- a/drivers/acpi/ec.c
>> +++ b/drivers/acpi/ec.c
>> @@ -43,6 +43,7 @@
>> #include <acpi/acpi_bus.h>
>> #include <acpi/acpi_drivers.h>
>> #include <linux/dmi.h>
>> +#include <linux/acpi.h>
>>
>> #define ACPI_EC_CLASS "embedded_controller"
>> #define ACPI_EC_DEVICE_NAME "Embedded Controller"
>> @@ -80,10 +81,6 @@ enum {
>> * OpReg are installed */
>> };
>>
>> -/* If we find an EC via the ECDT, we need to keep a ptr to its
>> context */
>> -/* External interfaces use first EC only, so remember */
>> -typedef int (*acpi_ec_query_func) (void *data);
>> -
>> struct acpi_ec_query_handler {
>> struct list_head node;
>> acpi_ec_query_func func;
>> @@ -104,19 +101,10 @@ struct transaction {
>> bool done;
>> };
>>
>> -static struct acpi_ec {
>> - acpi_handle handle;
>> - unsigned long gpe;
>> - unsigned long command_addr;
>> - unsigned long data_addr;
>> - unsigned long global_lock;
>> - unsigned long flags;
>> - struct mutex lock;
>> - wait_queue_head_t wait;
>> - struct list_head list;
>> - struct transaction *curr;
>> - spinlock_t curr_lock;
>> -} *boot_ec, *first_ec;
>> +/* If we find an EC via the ECDT, we need to keep a ptr to its
>> context */
>> +/* External interfaces use first EC only, so remember */
>> +static struct acpi_ec *boot_ec;
>> +static struct acpi_ec *first_ec;
>>
>> static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */
>>
>> diff --git a/drivers/acpi/sbshc.c b/drivers/acpi/sbshc.c
>> index d933980..d5550a5 100644
>> --- a/drivers/acpi/sbshc.c
>> +++ b/drivers/acpi/sbshc.c
>> @@ -250,12 +250,6 @@ static int smbus_alarm(void *context)
>> return 0;
>> }
>>
>> -typedef int (*acpi_ec_query_func) (void *data);
>> -
>> -extern int acpi_ec_add_query_handler(struct acpi_ec *ec, u8 query_bit,
>> - acpi_handle handle, acpi_ec_query_func func,
>> - void *data);
>> -
>> static int acpi_smbus_hc_add(struct acpi_device *device)
>> {
>> int status;
>> @@ -292,8 +286,6 @@ static int acpi_smbus_hc_add(struct acpi_device
>> *device)
>> return 0;
>> }
>>
>> -extern void acpi_ec_remove_query_handler(struct acpi_ec *ec, u8
>> query_bit);
>> -
>> static int acpi_smbus_hc_remove(struct acpi_device *device, int type)
>> {
>> struct acpi_smb_hc *hc;
>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>> index dfcd920..259eacb 100644
>> --- a/include/linux/acpi.h
>> +++ b/include/linux/acpi.h
>> @@ -145,12 +145,33 @@ struct acpi_pci_driver {
>> int acpi_pci_register_driver(struct acpi_pci_driver *driver);
>> void acpi_pci_unregister_driver(struct acpi_pci_driver *driver);
>>
>> +typedef int (*acpi_ec_query_func) (void *data);
>> +
>> +struct acpi_ec {
>> + acpi_handle handle;
>> + unsigned long gpe;
>> + unsigned long command_addr;
>> + unsigned long data_addr;
>> + unsigned long global_lock;
>> + unsigned long flags;
>> + struct mutex lock;
>> + wait_queue_head_t wait;
>> + struct list_head list;
>> + struct transaction *curr;
>> + spinlock_t curr_lock;
>> +};
>> +
>> extern int ec_read(u8 addr, u8 *val);
>> extern int ec_write(u8 addr, u8 val);
>> extern int ec_transaction(u8 command,
>> const u8 *wdata, unsigned wdata_len,
>> u8 *rdata, unsigned rdata_len,
>> int force_poll);
>> +extern int acpi_ec_add_query_handler(struct acpi_ec *ec, u8 query_bit,
>> + acpi_handle handle,
>> + acpi_ec_query_func func, void *data);
>> +extern void acpi_ec_remove_query_handler(struct acpi_ec *ec, u8
>> query_bit);
>> +
>>
>> #if defined(CONFIG_ACPI_WMI) || defined(CONFIG_ACPI_WMI_MODULE)
>>
>>
>
>
--
Ike Panhc <ike.pan@canonical.com>
Hardware Enable Team - Kernel Team - Platform Team - Canonical
Ubuntu - Linux for human beings | www.ubuntu.com | www.canonical.com
^ permalink raw reply
* Re: [PATCH] ACPI: Add EC event managerment functions into header file
From: Ike Panhc @ 2009-09-29 2:28 UTC (permalink / raw)
To: Alexey Starikovskiy; +Cc: linux-acpi, linux-kernel
In-Reply-To: <4AC135AC.2010407@gmail.com>
I had sent a new driver for Lenovo SL series laptops [1], and it uses those
functions to detect hotkeys. Since it has been exported for other modules,
I think it is reasonable to write in header file to make sure everyone has
the same definition.
[1] http://patchwork.kernel.org/patch/49912/
Alexey Starikovskiy wrote:
> These functions are never used anywhere, but sbshc.c.
> What is the reason to make them known to the whole kernel?
>
> Ike Panhc пишет:
>> There are two functions for add/remove EC query handler functions, which
>> exported without any definition in header files
>>
>> Patch against current checkout of linux-acpi 2.6.31 is below.
>>
>> In this patch, the following definitions has been added into
>> include/linux/acpi.h
>> - typedef: acpi_ec_query_func
>> - struct: acpi_ec
>> - fucntions: acpi_ec_add_query_handler, acpi_ec_remove_query_handler
>>
>> And the following definitions has been removed from driver/acpi/ec.c
>> - typedef: acpi_ec_query_func
>> - struct: acpi_ec
>>
>> So that, the following externs and typedef could be remove from
>> drivers/acpi/sbshc.c
>> - typedef: acpi_ec_query_func
>> - externs: acpi_ec_add_query_handler, acpi_ec_remove_query_handler
>>
>> Signed-off-by: Ike Panhc <ike.pan@canonical.com>
>> ---
>> drivers/acpi/ec.c | 22 +++++-----------------
>> drivers/acpi/sbshc.c | 8 --------
>> include/linux/acpi.h | 21 +++++++++++++++++++++
>> 3 files changed, 26 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
>> index f707960..8950c4f 100644
>> --- a/drivers/acpi/ec.c
>> +++ b/drivers/acpi/ec.c
>> @@ -43,6 +43,7 @@
>> #include <acpi/acpi_bus.h>
>> #include <acpi/acpi_drivers.h>
>> #include <linux/dmi.h>
>> +#include <linux/acpi.h>
>>
>> #define ACPI_EC_CLASS "embedded_controller"
>> #define ACPI_EC_DEVICE_NAME "Embedded Controller"
>> @@ -80,10 +81,6 @@ enum {
>> * OpReg are installed */
>> };
>>
>> -/* If we find an EC via the ECDT, we need to keep a ptr to its
>> context */
>> -/* External interfaces use first EC only, so remember */
>> -typedef int (*acpi_ec_query_func) (void *data);
>> -
>> struct acpi_ec_query_handler {
>> struct list_head node;
>> acpi_ec_query_func func;
>> @@ -104,19 +101,10 @@ struct transaction {
>> bool done;
>> };
>>
>> -static struct acpi_ec {
>> - acpi_handle handle;
>> - unsigned long gpe;
>> - unsigned long command_addr;
>> - unsigned long data_addr;
>> - unsigned long global_lock;
>> - unsigned long flags;
>> - struct mutex lock;
>> - wait_queue_head_t wait;
>> - struct list_head list;
>> - struct transaction *curr;
>> - spinlock_t curr_lock;
>> -} *boot_ec, *first_ec;
>> +/* If we find an EC via the ECDT, we need to keep a ptr to its
>> context */
>> +/* External interfaces use first EC only, so remember */
>> +static struct acpi_ec *boot_ec;
>> +static struct acpi_ec *first_ec;
>>
>> static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */
>>
>> diff --git a/drivers/acpi/sbshc.c b/drivers/acpi/sbshc.c
>> index d933980..d5550a5 100644
>> --- a/drivers/acpi/sbshc.c
>> +++ b/drivers/acpi/sbshc.c
>> @@ -250,12 +250,6 @@ static int smbus_alarm(void *context)
>> return 0;
>> }
>>
>> -typedef int (*acpi_ec_query_func) (void *data);
>> -
>> -extern int acpi_ec_add_query_handler(struct acpi_ec *ec, u8 query_bit,
>> - acpi_handle handle, acpi_ec_query_func func,
>> - void *data);
>> -
>> static int acpi_smbus_hc_add(struct acpi_device *device)
>> {
>> int status;
>> @@ -292,8 +286,6 @@ static int acpi_smbus_hc_add(struct acpi_device
>> *device)
>> return 0;
>> }
>>
>> -extern void acpi_ec_remove_query_handler(struct acpi_ec *ec, u8
>> query_bit);
>> -
>> static int acpi_smbus_hc_remove(struct acpi_device *device, int type)
>> {
>> struct acpi_smb_hc *hc;
>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>> index dfcd920..259eacb 100644
>> --- a/include/linux/acpi.h
>> +++ b/include/linux/acpi.h
>> @@ -145,12 +145,33 @@ struct acpi_pci_driver {
>> int acpi_pci_register_driver(struct acpi_pci_driver *driver);
>> void acpi_pci_unregister_driver(struct acpi_pci_driver *driver);
>>
>> +typedef int (*acpi_ec_query_func) (void *data);
>> +
>> +struct acpi_ec {
>> + acpi_handle handle;
>> + unsigned long gpe;
>> + unsigned long command_addr;
>> + unsigned long data_addr;
>> + unsigned long global_lock;
>> + unsigned long flags;
>> + struct mutex lock;
>> + wait_queue_head_t wait;
>> + struct list_head list;
>> + struct transaction *curr;
>> + spinlock_t curr_lock;
>> +};
>> +
>> extern int ec_read(u8 addr, u8 *val);
>> extern int ec_write(u8 addr, u8 val);
>> extern int ec_transaction(u8 command,
>> const u8 *wdata, unsigned wdata_len,
>> u8 *rdata, unsigned rdata_len,
>> int force_poll);
>> +extern int acpi_ec_add_query_handler(struct acpi_ec *ec, u8 query_bit,
>> + acpi_handle handle,
>> + acpi_ec_query_func func, void *data);
>> +extern void acpi_ec_remove_query_handler(struct acpi_ec *ec, u8
>> query_bit);
>> +
>>
>> #if defined(CONFIG_ACPI_WMI) || defined(CONFIG_ACPI_WMI_MODULE)
>>
>>
>
>
--
Ike Panhc <ike.pan@canonical.com>
Hardware Enable Team - Kernel Team - Platform Team - Canonical
Ubuntu - Linux for human beings | www.ubuntu.com | www.canonical.com
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] intel_txt: fix the buggy timeout warning logic in tboot
From: Shane Wang @ 2009-09-29 2:27 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: Ingo Molnar, H. Peter Anvin, Cihula, Joseph,
arjan@linux.intel.com, andi@firstfloor.org, chrisw@sous-sol.org,
jmorris@namei.org, jbeulich@novell.com, peterm@redhat.com
In-Reply-To: <4ABF2B50.6070106@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]
This patch based on an original version by H. Peter Anvin fixed the buggy
timeout warning logic in tboot.
---
arch/x86/kernel/tboot.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
Signed-off-by: Shane Wang <shane.wang@intel.com>
diff -r 0edd117ada44 arch/x86/kernel/tboot.c
--- a/arch/x86/kernel/tboot.c Wed Sep 23 10:06:56 2009 -0700
+++ b/arch/x86/kernel/tboot.c Mon Sep 28 07:42:18 2009 -0700
@@ -301,16 +301,17 @@ static int tboot_wait_for_aps(int num_ap
unsigned long timeout;
timeout = AP_WAIT_TIMEOUT*HZ;
- while (atomic_read((atomic_t *)&tboot->num_in_wfs) != num_aps &&
- timeout) {
+ while (timeout) {
+ if (atomic_read((atomic_t *)&tboot->num_in_wfs) == num_aps)
+ break;
mdelay(1);
timeout--;
}
- if (timeout)
+ if (!timeout)
pr_warning("tboot wait for APs timeout\n");
- return !(atomic_read((atomic_t *)&tboot->num_in_wfs) == num_aps);
+ return !timeout;
}
static int __cpuinit tboot_cpu_callback(struct notifier_block *nfb,
[-- Attachment #2: timeout_fix.patch --]
[-- Type: text/plain, Size: 902 bytes --]
This patch based on an original version by H. Peter Anvin fixed the buggy timeout warning logic in tboot.
Signed-off-by: Shane Wang <shane.wang@intel.com>
diff -r 0edd117ada44 arch/x86/kernel/tboot.c
--- a/arch/x86/kernel/tboot.c Wed Sep 23 10:06:56 2009 -0700
+++ b/arch/x86/kernel/tboot.c Mon Sep 28 07:42:18 2009 -0700
@@ -301,16 +301,17 @@ static int tboot_wait_for_aps(int num_ap
unsigned long timeout;
timeout = AP_WAIT_TIMEOUT*HZ;
- while (atomic_read((atomic_t *)&tboot->num_in_wfs) != num_aps &&
- timeout) {
+ while (timeout) {
+ if (atomic_read((atomic_t *)&tboot->num_in_wfs) == num_aps)
+ break;
mdelay(1);
timeout--;
}
- if (timeout)
+ if (!timeout)
pr_warning("tboot wait for APs timeout\n");
- return !(atomic_read((atomic_t *)&tboot->num_in_wfs) == num_aps);
+ return !timeout;
}
static int __cpuinit tboot_cpu_callback(struct notifier_block *nfb,
^ permalink raw reply
* Re: Paravirtualization on VMware's Platform [VMI].
From: H. Peter Anvin @ 2009-09-29 2:25 UTC (permalink / raw)
To: akataria
Cc: Andrew Morton, Greg KH, the arch/x86 maintainers, LKML,
Chris Wright, virtualization@lists.osdl.org, Ingo Molnar,
Linus Torvalds, Thomas Gleixner
In-Reply-To: <1254185107.13456.32.camel@ank32.eng.vmware.com>
On 09/28/2009 05:45 PM, Alok Kataria wrote:
> + bool "VMI Guest support [will be deprecated soon]"
> + default n
This is incorrect use of the word "deprecated"... it's *already*
deprecated (a word which pretty much means the opposite of "recommended".)
As far as "default n" is concerned... this is usually not necessary; "n"
is the default unless anything else is specified.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: [lm-sensors] [PATCH] asus_atk0110: add support for Asus P7P55D
From: Robert Hancock @ 2009-09-29 2:20 UTC (permalink / raw)
To: Luca Tettamanti; +Cc: lm-sensors, linux-kernel, Jean Delvare
In-Reply-To: <20090928131700.GA19243@nb-core2.darkstar.lan>
On Mon, Sep 28, 2009 at 7:17 AM, Luca Tettamanti <kronos.it@gmail.com> wrote:
> On Wed, Sep 23, 2009 at 09:18:45PM -0600, Robert Hancock wrote:
>> On Wed, Sep 23, 2009 at 1:12 PM, Luca Tettamanti <kronos.it@gmail.com> wrote:
>> > With P7P55D (and newer) boards Asus extended the output buffer (ASBF)
>> > making the driver unable to read the data from the sensors.
>> > Change the driver to use dynamic buffers (allocated by ACPI core); the
>> > return value is cached, so the number of memory allocations is very low.
>> >
>> > Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
>> > Tested-by: Robert Hancock <hancockrwd@gmail.com>
>>
>> I just noticed a problem (either with this patch or some other issue
>> with the driver on this board): The readings don't seem to be
>> updating, I get the same values all the time. (Just now I started
>> compiling a kernel and coretemp reports temperatures in the 60 degree
>> plus range but atk0110-acpi still reports 35 degrees as it did
>> before..)
>
> Hi Robert,
> I have a new patch for you :)
> It contains the previous changes to handle the bigger ASBF buffer plus a new
> method to enable the EC as suggested by Asus. Be sure to compile with
> HWMON_DEBUG_CHIP enabled.
Excellent.. seems to work now and give actually updating sensor readings :-)
By the way, if you have any firmware-type contacts at Asus that know
about these boards, you might want to point them at this problem, the
BIOS DMAR tables point to invalid locations when Intel VT-d is
enabled. So far haven't gotten any useful response from tech support..
http://www.gossamer-threads.com/lists/linux/kernel/1131574
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: [PATCH] asus_atk0110: add support for Asus P7P55D
From: Robert Hancock @ 2009-09-29 2:20 UTC (permalink / raw)
To: Luca Tettamanti; +Cc: lm-sensors, linux-kernel, Jean Delvare
In-Reply-To: <20090928131700.GA19243@nb-core2.darkstar.lan>
On Mon, Sep 28, 2009 at 7:17 AM, Luca Tettamanti <kronos.it@gmail.com> wrote:
> On Wed, Sep 23, 2009 at 09:18:45PM -0600, Robert Hancock wrote:
>> On Wed, Sep 23, 2009 at 1:12 PM, Luca Tettamanti <kronos.it@gmail.com> wrote:
>> > With P7P55D (and newer) boards Asus extended the output buffer (ASBF)
>> > making the driver unable to read the data from the sensors.
>> > Change the driver to use dynamic buffers (allocated by ACPI core); the
>> > return value is cached, so the number of memory allocations is very low.
>> >
>> > Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
>> > Tested-by: Robert Hancock <hancockrwd@gmail.com>
>>
>> I just noticed a problem (either with this patch or some other issue
>> with the driver on this board): The readings don't seem to be
>> updating, I get the same values all the time. (Just now I started
>> compiling a kernel and coretemp reports temperatures in the 60 degree
>> plus range but atk0110-acpi still reports 35 degrees as it did
>> before..)
>
> Hi Robert,
> I have a new patch for you :)
> It contains the previous changes to handle the bigger ASBF buffer plus a new
> method to enable the EC as suggested by Asus. Be sure to compile with
> HWMON_DEBUG_CHIP enabled.
Excellent.. seems to work now and give actually updating sensor readings :-)
By the way, if you have any firmware-type contacts at Asus that know
about these boards, you might want to point them at this problem, the
BIOS DMAR tables point to invalid locations when Intel VT-d is
enabled. So far haven't gotten any useful response from tech support..
http://www.gossamer-threads.com/lists/linux/kernel/1131574
^ permalink raw reply
* [U-Boot] [PATCH] arm:kirkwood: Add hardware watchdog support for Marvell Kirkwood boards
From: Prafulla Wadaskar @ 2009-09-29 2:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1254121586-26903-1-git-send-email-simon.kagstrom@netinsight.net>
> -----Original Message-----
> From: u-boot-bounces at lists.denx.de
> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Simon Kagstrom
> Sent: Monday, September 28, 2009 12:36 PM
> To: u-boot at lists.denx.de
> Subject: [U-Boot] [PATCH] arm:kirkwood: Add hardware watchdog
> support for Marvell Kirkwood boards
>
> Initialize by calling kw_watchdog_init() with the number of
> seconds for
> the watchdog to timeout.
Hi Simon
It is good to have more support available for Kirkwood and thanks for your efforts.
But do you really need Watchdog support for u-boot?
Because if you want to use the watchdog, you will need to keep it running in
Entire code.
May you pls explain your objective for enabling it?
Secondly Pls have a look at drivers/watchdog/at91sam9_wdt.c and its implementation,
This will be a good way of implementation.
Regards..
Prafulla . .
Regards..
Prafulla . .
^ permalink raw reply
* Re: [RFC][PATCH 8/10] memcg: clean up charge/uncharge anon
From: Daisuke Nishimura @ 2009-09-29 2:18 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: nishimura, linux-mm@kvack.org, balbir@linux.vnet.ibm.com
In-Reply-To: <20090929102653.612cc2a4.kamezawa.hiroyu@jp.fujitsu.com>
On Tue, 29 Sep 2009 10:26:53 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> Thank you for testing.
>
> On Tue, 29 Sep 2009 09:24:13 +0900
> Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> wrote:
>
> > On Fri, 25 Sep 2009 17:28:50 +0900, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > > This may need careful review.
> > >
> > > ==
> > > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > >
> > > In old codes, this function was used for other purposes rather
> > > than charginc new anon pages. But now, this function is (ranamed) and
> > > used only for new pages.
> > >
> > > For the same kind of reason, ucharge_page() should use VM_BUG_ON().
> > >
> > > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > > ---
> > > mm/memcontrol.c | 27 +++++++++++++--------------
> > > 1 file changed, 13 insertions(+), 14 deletions(-)
> > >
> > > Index: temp-mmotm/mm/memcontrol.c
> > > ===================================================================
> > > --- temp-mmotm.orig/mm/memcontrol.c
> > > +++ temp-mmotm/mm/memcontrol.c
> > > @@ -1638,15 +1638,8 @@ int mem_cgroup_newpage_charge(struct pag
> > > return 0;
> > > if (PageCompound(page))
> > > return 0;
> > > - /*
> > > - * If already mapped, we don't have to account.
> > > - * If page cache, page->mapping has address_space.
> > > - * But page->mapping may have out-of-use anon_vma pointer,
> > > - * detecit it by PageAnon() check. newly-mapped-anon's page->mapping
> > > - * is NULL.
> > > - */
> > > - if (page_mapped(page) || (page->mapping && !PageAnon(page)))
> > > - return 0;
> > > + /* This function is "newpage_charge" and called right after alloc */
> > > + VM_BUG_ON(page_mapped(page) || (page->mapping && !PageAnon(page)));
> > > if (unlikely(!mm))
> > > mm = &init_mm;
> > > return mem_cgroup_charge_common(page, mm, gfp_mask,
> > I think this VM_BUG_ON() is vaild.
> >
> > > @@ -1901,11 +1894,11 @@ unlock_out:
> > >
> > > void mem_cgroup_uncharge_page(struct page *page)
> > > {
> > > - /* early check. */
> > > - if (page_mapped(page))
> > > - return;
> > > - if (page->mapping && !PageAnon(page))
> > > - return;
> > > + /*
> > > + * Called when anonymous page's page->mapcount goes down to zero,
> > > + * or cancel a charge gotten by newpage_charge().
> > > + */
> > > + VM_BUG_ON(page_mapped(page) || (page->mapping && !PageAnon(page)));
> > > __mem_cgroup_uncharge_common(page, MEM_CGROUP_CHARGE_TYPE_MAPPED);
> > > }
> > >
> > >
> > I hit this VM_BUG_ON() when I'm testing mmotm-2009-09-25-14-35 + these patches
> > + my latest recharge-at-task-move patches(not posted yet).
> >
>
> Ouch.
>
>
> > [ 2966.031815] kernel BUG at mm/memcontrol.c:2014!
> > [ 2966.031815] invalid opcode: 0000 [#1] SMP
> > [ 2966.031815] last sysfs file: /sys/devices/pci0000:00/0000:00:07.0/0000:09:00.2/0000:0b:
> > 04.1/irq
> > [ 2966.031815] CPU 2
> > [ 2966.031815] Modules linked in: autofs4 lockd sunrpc iscsi_tcp libiscsi_tcp libiscsi scs
> > i_transport_iscsi dm_mirror dm_multipath video output lp sg ide_cd_mod cdrom serio_raw but
> > ton parport_pc parport e1000 i2c_i801 i2c_core pata_acpi ata_generic pcspkr dm_region_hash
> > dm_log dm_mod ata_piix libata shpchp megaraid_mbox megaraid_mm sd_mod scsi_mod ext3 jbd u
> > hci_hcd ohci_hcd ehci_hcd [last unloaded: microcode]
> > [ 2966.031815] Pid: 19677, comm: mmapstress10 Not tainted 2.6.31-mmotm-2009-09-25-14-35-35
> > ace741 #1 Express5800/140Rd-4 [N8100-1065]
> > [ 2966.031815] RIP: 0010:[<ffffffff800efbe2>] [<ffffffff800efbe2>] mem_cgroup_uncharge_pa
> > ge+0x18/0x28
> > [ 2966.031815] RSP: 0000:ffff880381713da8 EFLAGS: 00010246
> > [ 2966.031815] RAX: 0000000000000000 RBX: ffffea001668fef0 RCX: ffffea001763afe0
> > [ 2966.031815] RDX: 0000000000000080 RSI: 0000000000000008 RDI: ffffea001668fef0
> > [ 2966.031815] RBP: ffff880381713da8 R08: ffffea001763afe0 R09: ffff88039dfafa28
> > [ 2966.031815] R10: ffff880381617b80 R11: 0000000000000000 R12: ffffea001668fef0
> > [ 2966.031815] R13: ffffea001668fef0 R14: 0000000000000008 R15: ffff880381617b80
> > [ 2966.031815] FS: 00007f9a617fa6e0(0000) GS:ffff88002a000000(0000) knlGS:000000000000000
> > 0
> > [ 2966.031815] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > [ 2966.031815] CR2: 000000385021c4b8 CR3: 0000000372107000 CR4: 00000000000006e0
> > [ 2966.031815] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [ 2966.031815] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > [ 2966.031815] Process mmapstress10 (pid: 19677, threadinfo ffff880381712000, task ffff880
> > 3817c2920)
> > [ 2966.031815] Stack:
> > [ 2966.031815] ffff880381713dc8 ffffffff800d6bff 00000003992ec067 00000003992ec067
> > [ 2966.031815] <0> ffff880381713e58 ffffffff800ce2f3 ffff880381713e18 ffff88038a90c408
> > [ 2966.031815] <0> 000000385021c4b8 ffff88039dfaf6c0 ffffea000168fef0 ffffea0016c91508
> > [ 2966.031815] Call Trace:
> > [ 2966.031815] [<ffffffff800d6bff>] page_remove_rmap+0x28/0x44
> > [ 2966.031815] [<ffffffff800ce2f3>] do_wp_page+0x626/0x73c
> > [ 2966.031815] [<ffffffff8005e9e3>] ? __wake_up_bit+0x2c/0x2e
> > [ 2966.031815] [<ffffffff800cfbfc>] handle_mm_fault+0x712/0x824
> > [ 2966.031815] [<ffffffff8034e6d7>] do_page_fault+0x255/0x2e5
> > [ 2966.031815] [<ffffffff8034c59f>] page_fault+0x1f/0x30
> > [ 2966.031815] Code: 83 7f 18 00 74 04 0f 0b eb fe 31 f6 e8 75 fe ff ff c9 c3 8b 47 0c 55
> > 48 89 e5 85 c0 79 0d 48 8b 47 18 48 85 c0 74 08 a8 01 75 04 <0f> 0b eb fe be 01 00 00 00 e
> > 8 4d fe ff ff c9 c3 55 65 48 8b 04
> > [ 2966.031815] RIP [<ffffffff800efbe2>] mem_cgroup_uncharge_page+0x18/0x28
> > [ 2966.031815] RSP <ffff880381713da8>
> >
> > I don't think my patch is the guilt because this also happens even if I don't
> > set "recharge_at_immigrate".
> >
> > It might be better that I test w/o my patches, but IIUC, this can happen
> > in following scenario like:
> >
> > Assume process A and B has the same swap pte.
> >
> > process A process B
> > do_swap_page() do_swap_page()
> > read_swap_cache_async()
> > lock_page() lookup_swap_cache()
> > page_add_anon_rmap()
> > unlock_page()
> > lock_page()
> > do_wp_page()
> I think do_wp_page() do lock_page() here.
> Because the page is ANON.
>
hmm, but it calls unlock_page() soon.
So, I think this can happen if lock_page() of B gets the lock after do_wp_page()
of A release the lock.
> > page_remove_rmap()
> > atomic_add_negative()
> > -> page->_mapcount = -1 page_add_anon_rmap()
> > atomic_inc_and_test()
> > -> page->_mapcount = 0
> > mem_cgroup_uncharge_page()
> > -> hit the VM_BUG_ON()
> >
> >
> > So, I think this should be like:
> >
> > void mem_cgroup_uncharge_page(struct page *page)
> > {
> > /*
> > * Called when anonymous page's page->mapcount goes down to zero,
> > * or cancel a charge gotten by newpage_charge().
> > * But there is a small race between page_remove_rmap() and
> > * page_add_anon_rmap(), so we can reach here with page_mapped().
> > */
> > VM_BUG_ON(page->mapping && !PageAnon(page))
> > if (unlikely(page_mapped(page))
> > return;
> > __mem_cgroup_uncharge_common(page, MEM_CGROUP_CHARGE_TYPE_MAPPED);
> > }
> >
>
> From backtrace, mem_cgroup_uncharge_page() is called via page_remove_rmap().
> Then, page_mapped() should be false.
>
> Hmm.
> VM_BUG_ON(page_mapped(page) || (page->mapping && !PageAnon(page)));
>
> mem_cgroup_uncharge_page() is called by page_remove_rmap() only when
> !page_mapped() and PageAnon(page) == true.
> Could you show me disassemble of (head lines of) mem_cgroup_uncharge_page() ?
>
here.
===
(gdb) disas mem_cgroup_uncharge_page
Dump of assembler code for function mem_cgroup_uncharge_page:
0xffffffff800efbca <mem_cgroup_uncharge_page+0>: mov 0xc(%rdi),%eax
0xffffffff800efbcd <mem_cgroup_uncharge_page+3>: push %rbp
0xffffffff800efbce <mem_cgroup_uncharge_page+4>: mov %rsp,%rbp
0xffffffff800efbd1 <mem_cgroup_uncharge_page+7>: test %eax,%eax
0xffffffff800efbd3 <mem_cgroup_uncharge_page+9>: jns 0xffffffff800efbe2 <mem_cgroup_uncharge_page+24>
0xffffffff800efbd5 <mem_cgroup_uncharge_page+11>: mov 0x18(%rdi),%rax
0xffffffff800efbd9 <mem_cgroup_uncharge_page+15>: test %rax,%rax
0xffffffff800efbdc <mem_cgroup_uncharge_page+18>: je 0xffffffff800efbe6 <mem_cgroup_uncharge_page+28>
0xffffffff800efbde <mem_cgroup_uncharge_page+20>: test $0x1,%al
0xffffffff800efbe0 <mem_cgroup_uncharge_page+22>: jne 0xffffffff800efbe6 <mem_cgroup_uncharge_page+28>
0xffffffff800efbe2 <mem_cgroup_uncharge_page+24>: ud2a
0xffffffff800efbe4 <mem_cgroup_uncharge_page+26>: jmp 0xffffffff800efbe4 <mem_cgroup_uncharge_page+26>
0xffffffff800efbe6 <mem_cgroup_uncharge_page+28>: mov $0x1,%esi
0xffffffff800efbeb <mem_cgroup_uncharge_page+33>: callq 0xffffffff800efa3d <__mem_cgroup_uncharge_common>
0xffffffff800efbf0 <mem_cgroup_uncharge_page+38>: leaveq
0xffffffff800efbf1 <mem_cgroup_uncharge_page+39>: retq
End of assembler dump.
===
> Maybe there is something I don't understand..
> IIUC, when page_remove_rmap() is called by do_wp_page(),
> there must be pte(s) which points to the page and a pte is guarded by
> page table lock. So, I think page_mapcount() > 0 before calling page_remove_rmap()
> because there must be a valid pte, at least.
>
> Can this scenario happen ?
I think so. I intended to mention this case :)
I'm sorry for my vague explanation.
> ==
> Thread A. Thread B.
>
> do_wp_page() do_swap_page()
> PageAnon(oldpage)
> lock_page() lock_page()=> wait.
> reuse = false.
> unlock_page() get lock.
> do copy-on-write
> pte_same() == true
> page_remove_rmap(oldpage) (mapcount goes to -1)
> page_set_anon_rmap() (new anon rmap again)
> ==
> Then, oldpage's mapcount goes down to 0 and up to 1 immediately.
>
> About charge itself, Thread B. executes swap's charge sequence and maybe
> no problem. Hmm.
>
I think so too.
Thanks,
Daisuke Nishimura.
> I'll apply your change. Thank you for report.
>
> Regards,
> -Kame
>
>
>
> >
> >
> > Thanks,
> > Daisuke Nishimura.
> >
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo@kvack.org. For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> >
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] rmap : fix the comment
From: Huang Shijie @ 2009-09-29 2:25 UTC (permalink / raw)
To: akpm; +Cc: hugh.dickins, linux-mm, Huang Shijie
The page_address_in_vma() is not only used in unuse_vma().
Signed-off-by: Huang Shijie <shijie8@gmail.com>
---
mm/rmap.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index 28aafe2..dd43373 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -242,8 +242,8 @@ vma_address(struct page *page, struct vm_area_struct *vma)
}
/*
- * At what user virtual address is page expected in vma? checking that the
- * page matches the vma: currently only used on anon pages, by unuse_vma;
+ * At what user virtual address is page expected in vma?
+ * checking that the page matches the vma.
*/
unsigned long page_address_in_vma(struct page *page, struct vm_area_struct *vma)
{
--
1.6.0.6
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: visibility of linux source
From: Américo Wang @ 2009-09-29 2:07 UTC (permalink / raw)
To: Taro Okumichi; +Cc: linux-kernel
In-Reply-To: <25a94d2a0909281502u2bb383aemdb44f4af8ffdc9e7@mail.gmail.com>
On Tue, Sep 29, 2009 at 6:02 AM, Taro Okumichi <tarookumichi@gmail.com> wrote:
> I have written a gcc-tracer and html-formatter that shows
> Linux's init/main.c formatted as dynamic-html including:
> o expand macros by clicking on them
> o expand include directives
> o traverse c-structs
> Address:
> http://cfw.sourceforge.net/htmltag/init/main.c.pinfo.html
> I have only processed init/main.c (50mb mysql content)
> As far as I understand (maybe I am wrong) this kind of
> visibility is not achieved till now.
> Note:
> I tested firefox (3.5) and konqueror. The first page takes ~
> 10 Seconds to load, therefore be patient until the right
> side init/main.c content is shown (ajax fetch from a mysql db).
{snip}
> Using a ajax request to retrieve the html, the Mysql db
> content is ~ 50 mb for the whole of main.c. No optimization
> is done, so this includes lots of redundant entries.
>
> The left index frame should not be used, the javascript code
> is kind of buggy, so only use the right frame where the code
> is shown.
>
> Also: There is a bug in when closing a "include" directive section:
> (At least in firefox) A new windows will pop up (I didnt find out
> why this is the case). Click the window to the back and continue
> (not closing it otherwise the next #include directive opens it again...
Awesome!
Taro, you are doing a nice work! Thanks!
I just wonder how can I go back if I follow a function definition from one
file to another? Ajax makes going back to previous page impossible.
:-/
Thanks!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.