* Re: git-blame.el: what is format-spec?
From: David Kågedal @ 2009-12-07 9:05 UTC (permalink / raw)
To: Sergei Organov; +Cc: git, Andreas Schwab
In-Reply-To: <87k4wzdvuk.fsf@osv.gnss.ru>
Sergei Organov <osv@javad.com> writes:
> David Kågedal <davidk@lysator.liu.se> writes:
>
>> Sergei Organov <osv@javad.com> writes:
>>
>>> Then there should be (require 'format-spec) in git-blame.el, right? Due
>>> to:
>>
>> Of course. I must have missed that since I already had it loaded.
>>
>>> Now, I've evaluated (require 'format-spec) in my Emacs 22 (yes, 22, not
>>> 23), and now git-blame almost works there. The problem I see is that it
>>> doesn't output anything in the echo area. It color-codes the buffer, it
>>> does show correct pop-up when mouse is over a region, but it doesn't
>>> print anything in the echo area when I move cursor through the regions.
>>> Any idea how to debug/fix this?
>>
>> Well, it appears I removed the output to the echo area. I didn't think
>> it worked very well, and the new output format mostly replaces it by
>> showing the hash.
>>
>> There are also technical reasons for removing it (it couldn't be
>> implemented very cleanly).
>
> I didn't know you deliberately removed it, -- I thought it's some
> Emacs22 - related problem. I have no problem then, except that I don't
> know how to get the hash into my kill-ring or X selection.
>
> While we are at it, why is git-blame-identify interactive and how is it
> useful?
I think I need to go over this file with a fine-tooth coam to remove or
fix bitrot. This command seems to try to show the hash in the echo area,
but probably doesn't work. New and better commands should be deviced.
I'll try to find some time to work on this soon.
Thanks a lot for the feedback.
--
David Kågedal
^ permalink raw reply
* [Buildroot] Strange MTD problem (ARM)
From: Joachim Pihl @ 2009-12-07 9:17 UTC (permalink / raw)
To: buildroot
In-Reply-To: <87pr6rp3fn.fsf@macbook.be.48ers.dk>
On Mon, 07 Dec 2009 09:57:00 +0100, Peter Korsgaard <jacmet@uclibc.org>
wrote:
>>>>>> "Joachim" == Joachim Pihl <jpihl@nevion.com> writes:
> Joachim> We have used "cp mtdblock2 /dev/mtdblock2" for 7 years in the
> Joachim> product, this is the first time I have seen it fail.
>
> OK. FYI, busybox nowadays also has the flashcp applet from mtd-utils
> which does the right thing.
Thanks, that solved the problem. Will simply replace "cp mtdblock2
/dev/mtdblock2" with "flashcp mtdblock2 /dev/mtd2" and all is well.
--
Joachim Pihl
Senior R&D Engineer
Nevion
Tel: +47 33 48 94 66
Fax: +47 33 48 99 98
Mobile: +47 91 33 98 91
jpihl at nevion.com
www.nevion.com
-----------------------------------
The Global Video Transport Leader
-----------------------------------
^ permalink raw reply
* [PATCH net-next]atl1c:use common_task instead of reset_task and link_chg_task
From: jie.yang @ 2009-12-07 9:16 UTC (permalink / raw)
To: davem; +Cc: cmatei, netdev, linux-kernel, Jie Yang
From: Jie Yang <jie.yang@atheros.com>
use common_task instead of reset_task and link_chg_task, so it fix "call cancel_work_sync
from the work itself".
Signed-off-by: Jie Yang <jie.yang@atheros.com>
---
drivers/net/atl1c/atl1c.h | 6 ++-
drivers/net/atl1c/atl1c_main.c | 72 ++++++++++++++++++---------------------
2 files changed, 37 insertions(+), 41 deletions(-)
diff --git a/drivers/net/atl1c/atl1c.h b/drivers/net/atl1c/atl1c.h
index a348a22..b020723 100644
--- a/drivers/net/atl1c/atl1c.h
+++ b/drivers/net/atl1c/atl1c.h
@@ -550,6 +550,9 @@ struct atl1c_adapter {
#define __AT_TESTING 0x0001
#define __AT_RESETTING 0x0002
#define __AT_DOWN 0x0003
+ u8 work_event;
+#define ATL1C_WORK_EVENT_RESET 0x01
+#define ATL1C_WORK_EVENT_LINK_CHANGE 0x02
u32 msg_enable;
bool have_msi;
@@ -561,8 +564,7 @@ struct atl1c_adapter {
spinlock_t tx_lock;
atomic_t irq_sem;
- struct work_struct reset_task;
- struct work_struct link_chg_task;
+ struct work_struct common_task;
struct timer_list watchdog_timer;
struct timer_list phy_config_timer;
diff --git a/drivers/net/atl1c/atl1c_main.c b/drivers/net/atl1c/atl1c_main.c
index 1e2f57d..c6c8fe8 100644
--- a/drivers/net/atl1c/atl1c_main.c
+++ b/drivers/net/atl1c/atl1c_main.c
@@ -198,27 +198,12 @@ static void atl1c_phy_config(unsigned long data)
void atl1c_reinit_locked(struct atl1c_adapter *adapter)
{
-
WARN_ON(in_interrupt());
atl1c_down(adapter);
atl1c_up(adapter);
clear_bit(__AT_RESETTING, &adapter->flags);
}
-static void atl1c_reset_task(struct work_struct *work)
-{
- struct atl1c_adapter *adapter;
- struct net_device *netdev;
-
- adapter = container_of(work, struct atl1c_adapter, reset_task);
- netdev = adapter->netdev;
-
- netif_device_detach(netdev);
- atl1c_down(adapter);
- atl1c_up(adapter);
- netif_device_attach(netdev);
-}
-
static void atl1c_check_link_status(struct atl1c_adapter *adapter)
{
struct atl1c_hw *hw = &adapter->hw;
@@ -275,18 +260,6 @@ static void atl1c_check_link_status(struct atl1c_adapter *adapter)
}
}
-/*
- * atl1c_link_chg_task - deal with link change event Out of interrupt context
- * @netdev: network interface device structure
- */
-static void atl1c_link_chg_task(struct work_struct *work)
-{
- struct atl1c_adapter *adapter;
-
- adapter = container_of(work, struct atl1c_adapter, link_chg_task);
- atl1c_check_link_status(adapter);
-}
-
static void atl1c_link_chg_event(struct atl1c_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
@@ -311,20 +284,40 @@ static void atl1c_link_chg_event(struct atl1c_adapter *adapter)
adapter->link_speed = SPEED_0;
}
}
- schedule_work(&adapter->link_chg_task);
+
+ adapter->work_event |= ATL1C_WORK_EVENT_LINK_CHANGE;
+ schedule_work(&adapter->common_task);
}
-static void atl1c_del_timer(struct atl1c_adapter *adapter)
+static void atl1c_common_task(struct work_struct *work)
{
- del_timer_sync(&adapter->phy_config_timer);
+ struct atl1c_adapter *adapter;
+ struct net_device *netdev;
+
+ adapter = container_of(work, struct atl1c_adapter, common_task);
+ netdev = adapter->netdev;
+
+ if (adapter->work_event & ATL1C_WORK_EVENT_RESET) {
+ netif_device_detach(netdev);
+ atl1c_down(adapter);
+ atl1c_up(adapter);
+ netif_device_attach(netdev);
+ return;
+ }
+
+ if (adapter->work_event & ATL1C_WORK_EVENT_LINK_CHANGE)
+ atl1c_check_link_status(adapter);
+
+ return;
}
-static void atl1c_cancel_work(struct atl1c_adapter *adapter)
+
+static void atl1c_del_timer(struct atl1c_adapter *adapter)
{
- cancel_work_sync(&adapter->reset_task);
- cancel_work_sync(&adapter->link_chg_task);
+ del_timer_sync(&adapter->phy_config_timer);
}
+
/*
* atl1c_tx_timeout - Respond to a Tx Hang
* @netdev: network interface device structure
@@ -334,7 +327,8 @@ static void atl1c_tx_timeout(struct net_device *netdev)
struct atl1c_adapter *adapter = netdev_priv(netdev);
/* Do the reset outside of interrupt context */
- schedule_work(&adapter->reset_task);
+ adapter->work_event |= ATL1C_WORK_EVENT_RESET;
+ schedule_work(&adapter->common_task);
}
/*
@@ -1533,7 +1527,8 @@ static irqreturn_t atl1c_intr(int irq, void *data)
/* reset MAC */
hw->intr_mask &= ~ISR_ERROR;
AT_WRITE_REG(hw, REG_IMR, hw->intr_mask);
- schedule_work(&adapter->reset_task);
+ adapter->work_event |= ATL1C_WORK_EVENT_RESET;
+ schedule_work(&adapter->common_task);
break;
}
@@ -2198,8 +2193,7 @@ void atl1c_down(struct atl1c_adapter *adapter)
struct net_device *netdev = adapter->netdev;
atl1c_del_timer(adapter);
- atl1c_cancel_work(adapter);
-
+ adapter->work_event = 0; /* clear all event */
/* signal that we're down so the interrupt handler does not
* reschedule our watchdog timer */
set_bit(__AT_DOWN, &adapter->flags);
@@ -2599,8 +2593,8 @@ static int __devinit atl1c_probe(struct pci_dev *pdev,
adapter->hw.mac_addr[4], adapter->hw.mac_addr[5]);
atl1c_hw_set_mac_addr(&adapter->hw);
- INIT_WORK(&adapter->reset_task, atl1c_reset_task);
- INIT_WORK(&adapter->link_chg_task, atl1c_link_chg_task);
+ INIT_WORK(&adapter->common_task, atl1c_common_task);
+ adapter->work_event = 0;
err = register_netdev(netdev);
if (err) {
dev_err(&pdev->dev, "register netdevice failed\n");
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH V8 09/18] pc: remove a global variable, RTCState *rtc_state.
From: Gerd Hoffmann @ 2009-12-07 9:15 UTC (permalink / raw)
To: Isaku Yamahata; +Cc: Paolo Bonzini, qemu-devel
In-Reply-To: <1259905865-25295-10-git-send-email-yamahata@valinux.co.jp>
On 12/04/09 06:50, Isaku Yamahata wrote:
> remove a global variable, RTCState *rtc_state.
> Only the cmos_set_s3_resume_init() needs it global.
> So introduce a registering function and make it local.
> As for other function which references the variable, pass it
> as a function argument.
>
> Signed-off-by: Isaku Yamahata<yamahata@valinux.co.jp>
> Cc: Paolo Bonzini<bonzini@gnu.org>
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -64,8 +64,6 @@
[ ... ]
> -static RTCState *rtc_state;
[ ... ]
> +static RTCState *rtc_state;
[ ... ]
Hmm? Patch description says something else ...
With my qdev hat on: If you cleanup that anyway I'd suggest to make the
rtc_* functions accept and return DeviceState instead of RTCState, so
the pc.c code just has a "this is the rtc device" kind of reference.
cheers,
Gerd
^ permalink raw reply
* Re: [Xenomai-core] Realtime gettimeofday()
From: Jan Kiszka @ 2009-12-07 9:14 UTC (permalink / raw)
To: Philippe Gerum; +Cc: Wolfgang Mauerer, xenomai@xenomai.org
In-Reply-To: <1260029489.2174.87.camel@domain.hid>
Philippe Gerum wrote:
> On Thu, 2009-12-03 at 22:42 +0100, Gilles Chanteperdrix wrote:
>> Wolfgang Mauerer wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Wolfgang Mauerer wrote:
>>>>> Hi,
>>>>>
>>>>> On 03.12.2009, at 14:14, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org
>>>>> > wrote:
>>>>>
>>>>>> Wolfgang Mauerer wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Gilles Chanteperdrix wrote:
>>>>>>>> Wolfgang Mauerer wrote:
>>>>>>>>> So that means, in essence, that you would accept probabilistic
>>>>>>>>> algorithms in realtime context?
>>>>>>>> Ah, today's troll!
>>>>>>> though it seems that I have to replace Jan this time ;-)
>>>>>>>> As I think I explained, the use of a seqlock in real-time context
>>>>>>>> when
>>>>>>>> the seqlock writer only happens in linux context is not
>>>>>>>> probabilistic.
>>>>>>>> It will work every time the first pass.
>>>>>>> I still don't see why it should succeed every time: What about
>>>>>>> the case that the Linux kernel on CPU0 updates the data, while
>>>>>>> Xenomai accesses them on another CPU? This can lead to
>>>>>>> inconsistent data, and they must be reread on the Xenomai side.
>>>>>> Yeah, right. I was not thinking about SMP. But admit that in this
>>>>>> case,
>>>>>> there will be only one retry, there is nothing pathological.
>>> that's right. Which makes it bounded again, so it's maybe
>>> the best way to go.
>>>>>>> I'm asking because if this case can not happen, then there's
>>>>>>> nothing left to to as I have the code already at hand.
>>>>>> You have reworked the nucleus timers handling to adapt to this new
>>>>>> real-time clock ?
>>>>> Nope. Sorry, I was a bit unclear: I'm just referring to the gtod
>>>>> syscall that does the timer handling, Not any other adaptions.
>>>> Ok, but what good is the gtod syscall if you can not use it as a time
>>>> reference for other timing related services?
>>> it suffices for our project's current purposes ;-)
>>>
>>> But it's certainly not the full solution. Before, we
>>> should have a decision wrt. the design issues, but I
>>> won't be able to continue working on this before
>>> mid of next week to look at the changed required for timer
>>> handling and come up with code.
>> Ok. To summarize what we have said, here is how I see we could implement
>> the NTP synchronized clock fully, and portably:
>> 1- allocate at nucleus init time, an area in the global sem heap for
>> this clock house-keeping
>> 2- add an event to the I-pipe patch when vsyscall_update is called
>> 3- implement the nucleus callback for the I-pipe event which copies
>> relevant data with our own version of seqlock called with hardware irqs
>> off, to the area allocated in 1 if the current clock source is the tsc
>> 4- rework the nucleus clocks and timers handling to use these data
>> 5- pass the offset of the data allocated in 1 to user-space through the
>> xnsysinfo, or xnfeatinfo structures
>> 6- rework clock_gettime to use these data, using the user-space
>> counterpart of the seqlock used in 3
>>
>> The real hard work is 4, and note that something which I did not mention
>> yesterday, is that we not only have to change the real-time clock
>> implementation, we also have to change the monotonic clock
>> implementation, otherwise the two clocks will drift apart.
>>
>> I think making such a change now is unreasonable.
>>
>> So, solution 1, we can implement 5, passing a null offset to mean that
>> the support is unimplemented by the kernel and not even use it in
>> user-space. Keeping the work for later in the 2.5 life cycle.
>>
>> Solution 2, we keep this change for 3.0.
>>
>> Solution 3, we implement a way to read that clock without synchronizing
>> the nucleus with it (that is, everything but 4). One way to do this,
>> which I do not like, is to add a dummy clock id to the posix skin, for
>> instance CLOCK_LINUX_NTP_REALTIME, and implement the clock reading for
>> that clock id in clock_gettime. This clock id, when passed to any other
>> service, causes EINVAL to be returned, making it clear that this clock
>> can not be used for anything else. Note that if we do that, even if we
>> implement the full support later, we will have to keep that dummy clock
>> id forever.
>>
>> My preference goes to solution 1. Philippe, what do you think?
>
> Way too late for this kind of change; 2.5.0 will be out this month.
> Timer related issues are prone to introduce nasty subtle regressions.
> Let's plan this for 3.0. The earlier 2.5.0 will be out, the earlier 3.0
> will start.
No, this was not about turning the nucleus timer handling upside down
for 2.5.0, this was first of all about establishing the required kernel
to user space ABI for 2.5. Can we agree on the latter?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply
* Re: [PATCH] Fix include problem. Signed-off-by: Marek Belisko <marek.belisko@gmail.com>
From: Tomi Valkeinen @ 2009-12-07 9:11 UTC (permalink / raw)
To: ext Tony Lindgren
Cc: Cory Maccarrone, Belisko Marek, linux-omap@vger.kernel.org
In-Reply-To: <20091204230012.GN24013@atomide.com>
On Sat, 2009-12-05 at 00:00 +0100, ext Tony Lindgren wrote:
> * Cory Maccarrone <darkstar6262@gmail.com> [091203 07:28]:
> > On Thu, Dec 3, 2009 at 5:28 AM, Belisko Marek <marek.belisko@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > when make htcherald_defconfig on current linux-omap tree
> > > (82f1d8f22f2c65e70206e40a6f17688bf64a892c) compilation fails
> > > in drivers/video/omap/lcd_htcherald.c.
> > >
> > > Following patch fixed this problem.
> >
> > Marek and I talked on IRC about this, and it turns out this is true on
> > the linux-omap master branch, but for-next compiles without issue,
> > possibly due to the header changes not having been done on the master
> > branch yet.
>
> Looks like Tomi's DSS2 moved this around. The DSS2 code is merged
> into linux-omap master branch, but is not in omap for-next branch.
>
> I've applied this to linux-omap master branch for now.
>
> Tomi, can you please add this to your fixes queue?
>
> The patch in question is at:
>
> http://patchwork.kernel.org/patch/64520/
Yes, I'll take it. And I actually anyway need to re-check before sending
pull request that all includes are correct, as there may have been new
LCDs/board files.
Tomi
^ permalink raw reply
* Re: sparse 0.4.2: cgcc issue
From: Christopher Li @ 2009-12-07 9:10 UTC (permalink / raw)
To: rubisher, Blue Swirl; +Cc: linux-sparse
In-Reply-To: <4B1B9D2A.6080804@scarlet.be>
On Sun, Dec 6, 2009 at 4:01 AM, rubisher <rubisher@scarlet.be> wrote:
> mmm, I figure out that's because the number of args to call this routine
> integer_types() should be the same as the number of @types's elements (i.e.
> 6) which is not allways the case:
> e.g.
> 252 } elsif ($spec eq 'i86') {
> 253 return (' -Di386=1 -D__i386=1 -D__i386__=1' .
> 254 &integer_types (8, 16, 32, $m64 ? 64 : 32, 64) .
> 255 &float_types (1, 1, 21, [24,8], [53,11], [64,15]) .
> 256 &define_size_t ($m64 ? "long unsigned int" : "unsigned
> int"));
> 257 } elsif ($spec eq 'sparc') {
> 258 return (' -Dsparc=1 -D__sparc=1 -D__sparc__=1' .
> 259 &integer_types (8, 16, 32, $m64 ? 64 : 32, 64) .
> 260 &float_types (1, 1, 33, [24,8], [53,11], [113,15]) .
> 261 &define_size_t ($m64 ? "long unsigned int" : "unsigned
> int"));
> 262 } elsif ($spec eq 'sparc64') {
> 263 return (' -Dsparc=1 -D__sparc=1 -D__sparc__=1 -D__sparcv9__=1
> -D__sparc64__=1 -D__arch64__=1 -D__LP64__=1' .
> 264 &integer_types (8, 16, 32, 64, 64, 128) .
> 265 &float_types (1, 1, 33, [24,8], [53,11], [113,15]) .
Seems relate to Blue Swirl's 128 bit changes. Add to the CC list.
Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" 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
* [Qemu-devel] Re: [PATCH V8 00/18] split out piix specific part from pc emulator
From: Michael S. Tsirkin @ 2009-12-07 9:07 UTC (permalink / raw)
To: Anthony Liguori; +Cc: Isaku Yamahata, Gerd Hoffmann, qemu-devel
In-Reply-To: <4B19181F.1070502@codemonkey.ws>
On Fri, Dec 04, 2009 at 08:09:35AM -0600, Anthony Liguori wrote:
> Isaku Yamahata wrote:
>> This is the preparation patch for q35 chipset and PCIE support.
>> Anthony, any chance to merge? Can you please give me comments?
>>
>
> I'd like to see Michael review the PCI changes and Gerd review the pc
> changes.
I might, but I don't see any pci changes in this patchset ...
which patches have them?
> I'm uncertain if some of the pc refactoring is the right intermediate
> solution verses just doing the right thing from a qdev perspective.
> Regards,
>
> Anthony Liguori
>
^ permalink raw reply
* [Qemu-devel] Re: [PATCH V8 02/18] acpi: split out apm register emulation from acpi.c
From: Michael S. Tsirkin @ 2009-12-07 9:07 UTC (permalink / raw)
To: Isaku Yamahata; +Cc: qemu-devel
In-Reply-To: <1259905865-25295-3-git-send-email-yamahata@valinux.co.jp>
On Fri, Dec 04, 2009 at 02:50:49PM +0900, Isaku Yamahata wrote:
> Split out apm register emulation for acpi.c into pc_apm.c.
> The apm emulation will be used later.
>
> Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
I don't know much about acpi.
One general comment below.
> ---
> Makefile.target | 4 +-
> hw/acpi.c | 57 ++++++++++-------------------------
> hw/pc_apm.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> hw/pc_apm.h | 43 ++++++++++++++++++++++++++
> 4 files changed, 150 insertions(+), 43 deletions(-)
> create mode 100644 hw/pc_apm.c
> create mode 100644 hw/pc_apm.h
>
> diff --git a/Makefile.target b/Makefile.target
> index acf8865..bbeef20 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -195,7 +195,7 @@ obj-i386-y += cirrus_vga.o apic.o ioapic.o parallel.o acpi.o piix_pci.o
> obj-i386-y += usb-uhci.o vmmouse.o vmport.o vmware_vga.o hpet.o
> obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
> obj-i386-y += ne2000-isa.o
> -obj-i386-y += pc_smbus.o
> +obj-i386-y += pc_smbus.o pc_apm.o
>
> # shared objects
> obj-ppc-y = ppc.o ide/core.o ide/qdev.o ide/isa.o ide/pci.o ide/macio.o
> @@ -226,7 +226,7 @@ obj-mips-y += ide/core.o ide/qdev.o ide/isa.o ide/pci.o ide/piix.o
> obj-mips-y += gt64xxx.o pckbd.o fdc.o mc146818rtc.o usb-uhci.o acpi.o ds1225y.o
> obj-mips-y += piix4.o parallel.o cirrus_vga.o pcspk.o $(sound-obj-y)
> obj-mips-y += mipsnet.o ne2000-isa.o
> -obj-mips-y += pc_smbus.o
> +obj-mips-y += pc_smbus.o pc_apm.o
> obj-mips-y += pflash_cfi01.o
> obj-mips-y += vmware_vga.o
>
> diff --git a/hw/acpi.c b/hw/acpi.c
> index 6b030bb..b503b16 100644
> --- a/hw/acpi.c
> +++ b/hw/acpi.c
> @@ -17,6 +17,7 @@
> */
> #include "hw.h"
> #include "pc.h"
> +#include "pc_apm.h"
> #include "pc_smbus.h"
> #include "pci.h"
> #include "qemu-timer.h"
> @@ -37,8 +38,9 @@ typedef struct PIIX4PMState {
> uint16_t pmsts;
> uint16_t pmen;
> uint16_t pmcntrl;
> - uint8_t apmc;
> - uint8_t apms;
> +
> + APMState apm;
> +
> QEMUTimer *tmr_timer;
> int64_t tmr_overflow_time;
>
> @@ -217,46 +219,20 @@ static uint32_t pm_ioport_readl(void *opaque, uint32_t addr)
> return val;
> }
>
> -static void pm_smi_writeb(void *opaque, uint32_t addr, uint32_t val)
> +static void apm_ctrl_changed(uint32_t val, void *arg)
> {
> - PIIX4PMState *s = opaque;
> - addr &= 1;
> -#ifdef DEBUG
> - printf("pm_smi_writeb addr=0x%x val=0x%02x\n", addr, val);
> -#endif
> - if (addr == 0) {
> - s->apmc = val;
> -
> - /* ACPI specs 3.0, 4.7.2.5 */
> - if (val == ACPI_ENABLE) {
> - s->pmcntrl |= SCI_EN;
> - } else if (val == ACPI_DISABLE) {
> - s->pmcntrl &= ~SCI_EN;
> - }
> + PIIX4PMState *s = arg;
>
> - if (s->dev.config[0x5b] & (1 << 1)) {
> - cpu_interrupt(first_cpu, CPU_INTERRUPT_SMI);
> - }
> - } else {
> - s->apms = val;
> + /* ACPI specs 3.0, 4.7.2.5 */
> + if (val == ACPI_ENABLE) {
> + s->pmcntrl |= SCI_EN;
> + } else if (val == ACPI_DISABLE) {
> + s->pmcntrl &= ~SCI_EN;
> }
> -}
>
> -static uint32_t pm_smi_readb(void *opaque, uint32_t addr)
> -{
> - PIIX4PMState *s = opaque;
> - uint32_t val;
> -
> - addr &= 1;
> - if (addr == 0) {
> - val = s->apmc;
> - } else {
> - val = s->apms;
> + if (s->dev.config[0x5b] & (1 << 1)) {
> + cpu_interrupt(first_cpu, CPU_INTERRUPT_SMI);
> }
> -#ifdef DEBUG
> - printf("pm_smi_readb addr=0x%x val=0x%02x\n", addr, val);
> -#endif
> - return val;
> }
>
> static void acpi_dbg_writel(void *opaque, uint32_t addr, uint32_t val)
> @@ -312,8 +288,7 @@ static const VMStateDescription vmstate_acpi = {
> VMSTATE_UINT16(pmsts, PIIX4PMState),
> VMSTATE_UINT16(pmen, PIIX4PMState),
> VMSTATE_UINT16(pmcntrl, PIIX4PMState),
> - VMSTATE_UINT8(apmc, PIIX4PMState),
> - VMSTATE_UINT8(apms, PIIX4PMState),
> + VMSTATE_STRUCT(apm, PIIX4PMState, 0, vmstate_pc_apm, APMState),
> VMSTATE_TIMER(tmr_timer, PIIX4PMState),
> VMSTATE_INT64(tmr_overflow_time, PIIX4PMState),
> VMSTATE_END_OF_LIST()
> @@ -373,8 +348,8 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
>
> pci_conf[0x40] = 0x01; /* PM io base read only bit */
>
> - register_ioport_write(0xb2, 2, 1, pm_smi_writeb, s);
> - register_ioport_read(0xb2, 2, 1, pm_smi_readb, s);
> + /* APM */
> + apm_init(&s->apm, apm_ctrl_changed, s);
>
> register_ioport_write(ACPI_DBG_IO_ADDR, 4, 4, acpi_dbg_writel, s);
>
> diff --git a/hw/pc_apm.c b/hw/pc_apm.c
> new file mode 100644
> index 0000000..730a576
> --- /dev/null
> +++ b/hw/pc_apm.c
> @@ -0,0 +1,89 @@
> +/*
> + * QEMU PC APM controller Emulation
> + *
> + * Copyright (c) 2009 Isaku Yamahata <yamahata at valinux co jp>
> + * VA Linux Systems Japan K.K.
> + *
> + * This is split out from acpi.c
If all you did was rearrange routines, it seems
wrong to remove Fabrice's copyright and replace
with your own.
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston MA 02110-1301 USA
> + */
> +
> +#include "pc_apm.h"
> +#include "hw.h"
> +#include "isa.h"
> +
> +//#define DEBUG
> +
> +/* fixed I/O location */
> +#define APM_CNT_IOPORT 0xb2
> +#define APM_STS_IOPORT 0xb3
> +
> +static void apm_ioport_writeb(void *opaque, uint32_t addr, uint32_t val)
> +{
> + APMState *apm = opaque;
> + addr &= 1;
> +#ifdef DEBUG
> + printf("apm_ioport_writeb addr=0x%x val=0x%02x\n", addr, val);
> +#endif
> + if (addr == 0) {
> + apm->apmc = val;
> +
> + if (apm->callback) {
> + (apm->callback)(val, apm->arg);
> + }
> + } else {
> + apm->apms = val;
> + }
> +}
> +
> +static uint32_t apm_ioport_readb(void *opaque, uint32_t addr)
> +{
> + APMState *apm = opaque;
> + uint32_t val;
> +
> + addr &= 1;
> + if (addr == 0) {
> + val = apm->apmc;
> + } else {
> + val = apm->apms;
> + }
> +#ifdef DEBUG
> + printf("apm_ioport_readb addr=0x%x val=0x%02x\n", addr, val);
> +#endif
> + return val;
> +}
> +
> +const VMStateDescription vmstate_pc_apm = {
> + .name = "PC APM State",
> + .version_id = 1,
> + .minimum_version_id = 1,
> + .minimum_version_id_old = 1,
> + .fields = (VMStateField[]) {
> + VMSTATE_UINT8(apmc, APMState),
> + VMSTATE_UINT8(apms, APMState),
> + VMSTATE_END_OF_LIST()
> + }
> +};
> +
> +void apm_init(APMState *apm, apm_ctrl_changed_t callback, void *arg)
> +{
> + apm->callback = callback;
> + apm->arg = arg;
> +
> + /* ioport 0xb2, 0xb3 */
> + register_ioport_write(APM_CNT_IOPORT, 2, 1, apm_ioport_writeb, apm);
> + register_ioport_read(APM_CNT_IOPORT, 2, 1, apm_ioport_readb, apm);
> +}
> diff --git a/hw/pc_apm.h b/hw/pc_apm.h
> new file mode 100644
> index 0000000..f7fab33
> --- /dev/null
> +++ b/hw/pc_apm.h
> @@ -0,0 +1,43 @@
> +/*
> + * QEMU PC APM controller Emulation
> + *
> + * Copyright (c) 2009 Isaku Yamahata <yamahata at valinux co jp>
> + * VA Linux Systems Japan K.K.
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston MA 02110-1301 USA
> + */
> +
Let's not put copyright notices into headers, please.
This 20 line header is IMO ridiculous for 4 declarations,
and the real code is in .c anyway.
> +#ifndef PC_APM_H
> +#define PC_APM_H
> +
> +#include <stdint.h>
> +#include "qemu-common.h"
> +#include "hw.h"
> +
> +typedef void (*apm_ctrl_changed_t)(uint32_t val, void *arg);
> +
> +typedef struct APMState {
> + uint8_t apmc;
> + uint8_t apms;
> +
> + apm_ctrl_changed_t callback;
> + void *arg;
> +} APMState;
> +
> +void apm_init(APMState *s, apm_ctrl_changed_t callback, void *arg);
> +
> +extern const VMStateDescription vmstate_pc_apm;
> +
> +#endif /* PC_APM_H */
> --
> 1.6.5.4
>
>
^ permalink raw reply
* [Cluster-devel] GFS2 git tree
From: Steven Whitehouse @ 2009-12-07 9:08 UTC (permalink / raw)
To: cluster-devel.redhat.com
Hi,
Linus has pulled the -nmw tree. I'll leave it a few days before I start
adding patches into the tree to avoid any confusion with those still
trying to merge from linux-next, but don't let that delay you in posting
any patches. If they are fixes, then they can go into the -fixes tree
right away (currently empty)
Steve.
^ permalink raw reply
* Re: [PATCH 0/5] Add TTM functionality and drm exports for vmwgfx
From: Dave Airlie @ 2009-12-07 9:08 UTC (permalink / raw)
To: Thomas Hellstrom; +Cc: dri-devel, linux-kernel, airlied
In-Reply-To: <1260132388-28414-1-git-send-email-thellstrom@vmware.com>
On Mon, Dec 7, 2009 at 6:46 AM, Thomas Hellstrom <thellstrom@vmware.com> wrote:
> This patch series adds TTM functionality and a couple of drm exports needed by the
> vmwgfx drm driver. The patch adding the vmwgfx driver itself will be posted
> later. The current driver source is available at
>
> git://git.freedesktop.org/git/mesa/vmwgfx
Applied all of these to drm-core-next,
Thanks,
Dave.
^ permalink raw reply
* Q: I2C multiplexer support
From: Michael Lawnick @ 2009-12-07 9:07 UTC (permalink / raw)
To: linux-i2c-u79uwXL29TY76Z2rM5mHXA; +Cc: Delvare, Jean , giometti-k2GhghHVRtY
Hi,
on my current project I'm now at the point to have to implement
multiplexer support. The last patch set from Rodolfo was for 2.6.29,
most parts seem to have been integrated already in 2.6.31
If I got it correctly the patch based on creating a mux folder with
i2c-mux.c as a core file and then additional mux layer files.
So my questions:
Rodolfo, do you have a more resent patch set?
Jean, what are your plans about multiplexer support, where do you see
open issues? Do you agree with current centralized layout or would you
prefer independent single files integrating all necessary parts and
residing in bus folder?
--
Kind Regards,
Michael
^ permalink raw reply
* Re: [PATCH] [3/3] Fix unwind annotations for 64bit kernel
From: Andi Kleen @ 2009-12-07 9:06 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andi Kleen, akpm, x86, linux-kernel
In-Reply-To: <4B1CC28F0200007800024075@vpn.id2.novell.com>
> So do we, but the initial submission was rejected due to doing too many
> things at once. I didn't since find time (admittedly also because not
> giving it priority) to split the patch. Thanks for giving it another try!
I'm not sure what should be split, it's all related and straight forward.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: kernel panic when adding QUEUE to OUTGOING
From: Slava Garaschenko @ 2009-12-07 9:06 UTC (permalink / raw)
To: netfilter
I have the same problem. Kernel 2.6.31 FC12, x86_64
Problem appear ONLY then first packet go into imq, which connected to
outgoing. If I add IMQ to OUTGOOING to interface which don`t have any
routing to it, and not connected (no packets sent to this interface) -
all OK, but then first packet send to this interface - I have "kernel
trap". If it wiil be help, I can try to make screenshot of screen then
"kernel trap".
--
Garashchenko Vyacheslav
^ permalink raw reply
* linux-next: input tree build failure
From: Stephen Rothwell @ 2009-12-07 9:03 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]
Hi Dmitry,
Today's linux-next build (powerpc allyesconfig) failed like this:
drivers/input/sparse-keymap.c:101: error: __ksymtab_sparse_keymap_setkeycode causes a section type conflict
Caused by commit a2dd9f7ceeb28f495587834aa5778c721611d61b ("Input: add
generic support for sparse keymaps").
static functions should not given to EXPORT_SYMBOL().
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* linux-next: net/kbuild trees build failure
From: Stephen Rothwell @ 2009-12-07 9:03 UTC (permalink / raw)
To: David Miller, netdev, Michal Marek
Cc: linux-next, linux-kernel, Reinette Chatre, John W. Linville,
Sam Ravnborg
Hi Dave,
Today's linux-next build (powerpc allyesconfig) failed like this:
In file included from drivers/net/wireless/iwlwifi/iwl3945-base.c:57:
drivers/net/wireless/iwlwifi/iwl-core.h:66:30: error: linux/utsrelease.h: No such file or directory
Caused by commit 250cce26d5d03337aec4ff8405121f026adb4a89 ("iwlwifi:
driver version track kernel version") from the net tree interacting with
commit 8e5c76aace9705b6983cfbf5eb2f2e869dab6738 ("kbuild: move
utsrelease.h to include/generated") from the kbuild tree.
I applied this patch for today (and will carry it as necessary):
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 7 Dec 2009 19:56:42 +1100
Subject: [PATCH] net: fix for utsrelease.h moving to generated
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/net/wireless/iwlwifi/iwl-core.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.h b/drivers/net/wireless/iwlwifi/iwl-core.h
index 675b7df..27ca859 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -63,7 +63,7 @@
#ifndef __iwl_core_h__
#define __iwl_core_h__
-#include <linux/utsrelease.h>
+#include <generated/utsrelease.h>
/************************
* forward declarations *
--
1.6.5.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* linux-next: net/kbuild trees build failure
From: Stephen Rothwell @ 2009-12-07 9:03 UTC (permalink / raw)
To: David Miller, netdev, Michal Marek
Cc: linux-next, linux-kernel, Reinette Chatre, John W. Linville,
Sam Ravnborg
Hi Dave,
Today's linux-next build (powerpc allyesconfig) failed like this:
In file included from drivers/net/wireless/iwlwifi/iwl3945-base.c:57:
drivers/net/wireless/iwlwifi/iwl-core.h:66:30: error: linux/utsrelease.h: No such file or directory
Caused by commit 250cce26d5d03337aec4ff8405121f026adb4a89 ("iwlwifi:
driver version track kernel version") from the net tree interacting with
commit 8e5c76aace9705b6983cfbf5eb2f2e869dab6738 ("kbuild: move
utsrelease.h to include/generated") from the kbuild tree.
I applied this patch for today (and will carry it as necessary):
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 7 Dec 2009 19:56:42 +1100
Subject: [PATCH] net: fix for utsrelease.h moving to generated
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/net/wireless/iwlwifi/iwl-core.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.h b/drivers/net/wireless/iwlwifi/iwl-core.h
index 675b7df..27ca859 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -63,7 +63,7 @@
#ifndef __iwl_core_h__
#define __iwl_core_h__
-#include <linux/utsrelease.h>
+#include <generated/utsrelease.h>
/************************
* forward declarations *
--
1.6.5.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: debugging oops after disconnecting Nexio USB touchscreen
From: Ondrej Zary @ 2009-12-07 9:02 UTC (permalink / raw)
To: Alan Stern; +Cc: linux-usb, linux-kernel
In-Reply-To: <Pine.LNX.4.44L0.0912041614170.3070-100000@iolanthe.rowland.org>
On Friday 04 December 2009, Alan Stern wrote:
> On Fri, 4 Dec 2009, Ondrej Zary wrote:
> > [ 3.712039] usb 2-1: new full speed USB device using uhci_hcd and
> > address 2 [ 3.726791] kjournald starting. Commit interval 5 seconds
> > [ 3.726817] EXT3-fs (sda2): mounted filesystem with ordered data mode
> > [ 3.851384] usb 2-1: not running at top speed; connect to a high speed
> > hub [ 3.859379] usb 2-1: New USB device found, idVendor=2001,
> > idProduct=f103 [ 3.859387] usb 2-1: New USB device strings: Mfr=0,
> > Product=0, SerialNumber=0 [ 3.862635] hub 2-1:1.0: USB hub found
> > [ 3.864385] hub 2-1:1.0: 7 ports detected
>
> That's the problem. Notice the "not running at top speed" message?
> Something went wrong when the hub was detected. It could be a problem
> in your EHCI controller or a problem in the hub.
>
> You can get more information about this by unplugging the hub, running
> usbmon (on the 0u file), and then plugging the hub back in.
>
> > diff between ehci and uhci logs:
> > There seems to be some problem with timing.
> > Also order of ehci_usb vs uhci_usb loading changes.
>
> That order doesn't matter much. But this...
Looks like it does matter. I compiled ehci_hcd in kernel and left uhci_hcd as
module - and the hub was always attached to ehci. Compiled uhci_hcd in kernel
and ehci_hcd as module - and it was always attached to uhci. So the HW is
probably OK.
> > --- dmesg-ehci.txt- 2009-12-04 20:01:39.000000000 +0100
> > +++ dmesg-uhci.txt- 2009-12-04 20:01:31.000000000 +0100
> > @@ -144,10 +144,9 @@
> > Console: colour VGA+ 80x25
> > console [tty0] enabled
> > hpet clockevent registered
> > - Fast TSC calibration failed
> > - TSC: PIT calibration matches HPET. 1 loops
> > - Detected 1608.000 MHz processor.
> > - Calibrating delay loop (skipped), value calculated using timer
> > frequency.. 3216.00 BogoMIPS (lpj=6432000) + Fast TSC calibration using
> > PIT
> > + Detected 1608.123 MHz processor.
> > + Calibrating delay loop (skipped), value calculated using timer
> > frequency.. 3216.24 BogoMIPS (lpj=6432492) Security Framework initialized
> > SELinux: Disabled at boot.
> > Mount-cache hash table entries: 512
> > @@ -180,7 +179,7 @@
> > CPU1: Thermal monitoring enabled (TM2)
> > CPU1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz stepping 02
> > Brought up 2 CPUs
> > - Total of 2 processors activated (9326.27 BogoMIPS).
> > + Total of 2 processors activated (6432.20 BogoMIPS).
>
> Those two differences seem strange to me. You might want to report it
> in a new email thread on LKML. You might also want to see if the same
> thing happens with a 2.6.32 kernel.
>
> > > This may be a bug in ehci-hcd, a bug in your EHCI hardware, or a bug in
> > > the hub. Can you try using a different high-speed hub to see if it
> > > makes any difference?
> >
> > Yes, I'll try it next week (I have only remote access now).
> > I have different 7-port hub available to test (should be with Philips
> > chipset).
>
> It's worth a try. Still, the original problem you saw (the oops in
> ehci-hcd) is in software, not in hardware, so the hub can't be entirely
> responsible.
>
> Alan Stern
--
Ondrej Zary
^ permalink raw reply
* [Qemu-devel] Re: guest OS crash during shutdown/reboot
From: Purna Chandar @ 2009-12-07 9:02 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <c56848720910292056t8cd6e76t32617a230e215eb6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
The culprit seems to be a soft lockup during shutdown because of the smp
code. Adding nosmp command line option to the guest kernel does not cause
this problem.
2009/10/30 Purna Chandar <purnachandar.midi@oneconvergence.com>
> Can somebody out there please help me with this issue.
>
> Thanks,
> PurnaChandar M
>
> 2009/10/26 Purna Chandar <purnachandar.midi@oneconvergence.com>
>
> Hi,
>> I have compiled qemu 0.11.0 for x86 64 bit. I run Fedora Core 10 64 bit as
>> my guest OS.
>> Sometimes, when I shutdown the guest OS gracefully (using halt command), I
>> see a kernel crash with a stack trace on guest OS window at *
>> native_machine_shutdown()*. The RIP points to *native_smp_send_stop()*.
>> This doesn't happen on every shutdown/reboot though.
>>
>> I did see this issue in older versions of qemu too(0.10.0 and 0.10.6).
>> This could be a minor issue for most of you but I need to fix this because I
>> run some automated scripts on the guest OS which reboots it.
>>
>> Does anybody has a fix or any other idea to get around this issue?
>>
>> Any bit of help on this would be really helpful.
>>
>> Thanks,
>> PurnaChandar M
>>
>
>
[-- Attachment #2: Type: text/html, Size: 1784 bytes --]
^ permalink raw reply
* Re: Mantis – anyone?
From: Matthias Wächter @ 2009-12-07 8:59 UTC (permalink / raw)
To: Manu Abraham; +Cc: linux-media
In-Reply-To: <4B1BA901.3080703@waechter.wiz.at>
Manu,
Am 06.12.2009 13:52, schrieb Matthias Wächter:
> • Sometimes very slow lock at transponder change, slow enough to trace
> it in femon. femon first shows high BER rates and the picture is blocky,
> reducing within 3 or 4 Seconds to BER=0 and perfect picture. I should be
> able to repeat that and give you some logs if you need it.
>
> • Sometimes lock to a transponder only in certain order of previous
> transponder. Hard to formalize, though. Verbose module output shows 1 to
> 2 unsuccessful locking attempts per second by the driver.
> • Currently no lock on 19.2/12693h either, but this may be a signal
> quality issue on my side.
After playing some more, I think those are all related: Lock to a
transponder takes from <1 second to minutes, and sometimes I was not
patient enough to wait for the lock to finally happen.
The no-lock on 19.2°/11303h does not seem to be related to that.
– Matthias
^ permalink raw reply
* [PATCH] KVM: Fix possible circular locking in kvm_vm_ioctl_assign_device()
From: Sheng Yang @ 2009-12-07 8:58 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti; +Cc: kvm, Sheng Yang
One possible order is:
KVM_CREATE_IRQCHIP ioctl(took kvm->lock) -> kvm_iobus_register_dev() ->
down_write(kvm->slots_lock).
The other one is in kvm_vm_ioctl_assign_device(), which take kvm->slots_lock
first, then kvm->lock.
Observe it due to kernel locking debug warnings.
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
---
virt/kvm/assigned-dev.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/assigned-dev.c b/virt/kvm/assigned-dev.c
index fd9c097..f73de63 100644
--- a/virt/kvm/assigned-dev.c
+++ b/virt/kvm/assigned-dev.c
@@ -508,8 +508,8 @@ static int kvm_vm_ioctl_assign_device(struct kvm *kvm,
struct kvm_assigned_dev_kernel *match;
struct pci_dev *dev;
- down_read(&kvm->slots_lock);
mutex_lock(&kvm->lock);
+ down_read(&kvm->slots_lock);
match = kvm_find_assigned_dev(&kvm->arch.assigned_dev_head,
assigned_dev->assigned_dev_id);
@@ -573,8 +573,8 @@ static int kvm_vm_ioctl_assign_device(struct kvm *kvm,
}
out:
- mutex_unlock(&kvm->lock);
up_read(&kvm->slots_lock);
+ mutex_unlock(&kvm->lock);
return r;
out_list_del:
list_del(&match->list);
@@ -585,8 +585,8 @@ out_put:
pci_dev_put(dev);
out_free:
kfree(match);
- mutex_unlock(&kvm->lock);
up_read(&kvm->slots_lock);
+ mutex_unlock(&kvm->lock);
return r;
}
--
1.5.4.5
^ permalink raw reply related
* Re: [PATCH 7/7] sched: implement try_to_wake_up_local()
From: Peter Zijlstra @ 2009-12-07 8:56 UTC (permalink / raw)
To: Tejun Heo; +Cc: tglx, mingo, avi, efault, rusty, linux-kernel
In-Reply-To: <1260175804.8223.1217.camel@laptop>
On Mon, 2009-12-07 at 09:50 +0100, Peter Zijlstra wrote:
> On Mon, 2009-12-07 at 12:26 +0900, Tejun Heo wrote:
> > Hmmm... it was intentional as, before this patch, there's no
> > try_to_wake_up_local() so it was strange to mention it in the comment.
> > I can move the comments but I don't think it's particularly better
> > that way.
>
> /me reads the comments and goes ah!
>
> OK, maybe you've got a point there ;-)
OK, so you fork and wakeup a new thread when an existing one goes to
sleep, but do you also limit the concurrency on wakeup?
Otherwise we can end up with say 100 workqueue tasks running, simply
because they all ran into a contended lock and then woke up again.
Where does that fork happen? Having to do memory allocations and all
that while holding the rq->lock doesn't seem like a very good idea.
What happens when you run out of memory and the workqueue progress is
needed to get free memory?
^ permalink raw reply
* [PATCH net-next]atl1c:add pci map direction in atl1c_buffer flags
From: jie.yang @ 2009-12-07 8:56 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, Jie Yang
From: Jie Yang <jie.yang@atheros.com>
add pci map direction in atl1c_buffer flags, it is used when call pci_unmap
apis.
Signed-off-by: Jie Yang <jie.yang@atheros.com>
---
drivers/net/atl1c/atl1c.h | 11 ++++++++---
drivers/net/atl1c/atl1c_main.c | 22 ++++++++++++++++------
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/net/atl1c/atl1c.h b/drivers/net/atl1c/atl1c.h
index a348a22..7e09084 100644
--- a/drivers/net/atl1c/atl1c.h
+++ b/drivers/net/atl1c/atl1c.h
@@ -479,6 +479,9 @@ struct atl1c_buffer {
#define ATL1C_PCIMAP_PAGE 0x0008
#define ATL1C_PCIMAP_TYPE_MASK 0x000C
+#define ATL1C_PCIMAP_TODEVICE 0x0010
+#define ATL1C_PCIMAP_FROMDEVICE 0x0020
+#define ATL1C_PCIMAP_DIRECTION_MASK 0x0030
dma_addr_t dma;
};
@@ -487,9 +490,11 @@ struct atl1c_buffer {
((buff)->flags) |= (state); \
} while (0)
-#define ATL1C_SET_PCIMAP_TYPE(buff, type) do { \
- ((buff)->flags) &= ~ATL1C_PCIMAP_TYPE_MASK; \
- ((buff)->flags) |= (type); \
+#define ATL1C_SET_PCIMAP_TYPE(buff, type, direction) do { \
+ ((buff)->flags) &= ~ATL1C_PCIMAP_TYPE_MASK; \
+ ((buff)->flags) |= (type); \
+ ((buff)->flags) &= ~ATL1C_PCIMAP_DIRECTION_MASK; \
+ ((buff)->flags) |= (direction); \
} while (0)
/* transimit packet descriptor (tpd) ring */
diff --git a/drivers/net/atl1c/atl1c_main.c b/drivers/net/atl1c/atl1c_main.c
index 1e2f57d..1098dad 100644
--- a/drivers/net/atl1c/atl1c_main.c
+++ b/drivers/net/atl1c/atl1c_main.c
@@ -713,15 +713,21 @@ static int __devinit atl1c_sw_init(struct atl1c_adapter *adapter)
static inline void atl1c_clean_buffer(struct pci_dev *pdev,
struct atl1c_buffer *buffer_info, int in_irq)
{
+ u16 pci_driection;
if (buffer_info->flags & ATL1C_BUFFER_FREE)
return;
if (buffer_info->dma) {
+ if (buffer_info->flags & ATL1C_PCIMAP_FROMDEVICE)
+ pci_driection = PCI_DMA_FROMDEVICE;
+ else
+ pci_driection = PCI_DMA_TODEVICE;
+
if (buffer_info->flags & ATL1C_PCIMAP_SINGLE)
pci_unmap_single(pdev, buffer_info->dma,
- buffer_info->length, PCI_DMA_TODEVICE);
+ buffer_info->length, pci_driection);
else if (buffer_info->flags & ATL1C_PCIMAP_PAGE)
pci_unmap_page(pdev, buffer_info->dma,
- buffer_info->length, PCI_DMA_TODEVICE);
+ buffer_info->length, pci_driection);
}
if (buffer_info->skb) {
if (in_irq)
@@ -1606,7 +1612,8 @@ static int atl1c_alloc_rx_buffer(struct atl1c_adapter *adapter, const int ringid
buffer_info->dma = pci_map_single(pdev, vir_addr,
buffer_info->length,
PCI_DMA_FROMDEVICE);
- ATL1C_SET_PCIMAP_TYPE(buffer_info, ATL1C_PCIMAP_SINGLE);
+ ATL1C_SET_PCIMAP_TYPE(buffer_info, ATL1C_PCIMAP_SINGLE,
+ ATL1C_PCIMAP_FROMDEVICE);
rfd_desc->buffer_addr = cpu_to_le64(buffer_info->dma);
rfd_next_to_use = next_next;
if (++next_next == rfd_ring->count)
@@ -1967,7 +1974,8 @@ static void atl1c_tx_map(struct atl1c_adapter *adapter,
buffer_info->dma = pci_map_single(adapter->pdev,
skb->data, hdr_len, PCI_DMA_TODEVICE);
ATL1C_SET_BUFFER_STATE(buffer_info, ATL1C_BUFFER_BUSY);
- ATL1C_SET_PCIMAP_TYPE(buffer_info, ATL1C_PCIMAP_SINGLE);
+ ATL1C_SET_PCIMAP_TYPE(buffer_info, ATL1C_PCIMAP_SINGLE,
+ ATL1C_PCIMAP_TODEVICE);
mapped_len += map_len;
use_tpd->buffer_addr = cpu_to_le64(buffer_info->dma);
use_tpd->buffer_len = cpu_to_le16(buffer_info->length);
@@ -1988,7 +1996,8 @@ static void atl1c_tx_map(struct atl1c_adapter *adapter,
pci_map_single(adapter->pdev, skb->data + mapped_len,
buffer_info->length, PCI_DMA_TODEVICE);
ATL1C_SET_BUFFER_STATE(buffer_info, ATL1C_BUFFER_BUSY);
- ATL1C_SET_PCIMAP_TYPE(buffer_info, ATL1C_PCIMAP_SINGLE);
+ ATL1C_SET_PCIMAP_TYPE(buffer_info, ATL1C_PCIMAP_SINGLE,
+ ATL1C_PCIMAP_TODEVICE);
use_tpd->buffer_addr = cpu_to_le64(buffer_info->dma);
use_tpd->buffer_len = cpu_to_le16(buffer_info->length);
}
@@ -2009,7 +2018,8 @@ static void atl1c_tx_map(struct atl1c_adapter *adapter,
buffer_info->length,
PCI_DMA_TODEVICE);
ATL1C_SET_BUFFER_STATE(buffer_info, ATL1C_BUFFER_BUSY);
- ATL1C_SET_PCIMAP_TYPE(buffer_info, ATL1C_PCIMAP_PAGE);
+ ATL1C_SET_PCIMAP_TYPE(buffer_info, ATL1C_PCIMAP_PAGE,
+ ATL1C_PCIMAP_TODEVICE);
use_tpd->buffer_addr = cpu_to_le64(buffer_info->dma);
use_tpd->buffer_len = cpu_to_le16(buffer_info->length);
}
^ permalink raw reply related
* [Buildroot] Strange MTD problem (ARM)
From: Peter Korsgaard @ 2009-12-07 8:57 UTC (permalink / raw)
To: buildroot
In-Reply-To: <op.u4j8accoyqa4qb@jap-lappis.nevion.com>
>>>>> "Joachim" == Joachim Pihl <jpihl@nevion.com> writes:
Hi,
>> I take it that this is with busybox cp and not coreutils? You might have
>> better luck asking on the busybox list.
Joachim> This is with busybox, yes. Will repost to the busybox list and see
Joachim> what comes up.
Ok.
>> Why not simply use cat instead?
Joachim> Actually, I have never thought of that, but will that start from the
Joachim> beginning of the MTD block?
Yes it will.
Joachim> We have used "cp mtdblock2 /dev/mtdblock2" for 7 years in the
Joachim> product, this is the first time I have seen it fail.
OK. FYI, busybox nowadays also has the flashcp applet from mtd-utils
which does the right thing.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [Buildroot] [Bug 779] New: uClibc (re)building fail
From: bugzilla at busybox.net @ 2009-12-07 8:54 UTC (permalink / raw)
To: buildroot
https://bugs.busybox.net/show_bug.cgi?id=779
Target: ARM 920 (AT91RM9200)
Build: 2009.11
Summary: uClibc (re)building fail
Product: buildroot
Version: 2009.11
Platform: PC
OS/Version: Linux
Status: NEW
Severity: blocker
Priority: P5
Component: Other
AssignedTo: unassigned at buildroot.uclibc.org
ReportedBy: peter.stosz at freemail.hu
CC: buildroot at uclibc.org
Estimated Hours: 0.0
1) Download BR2009.11
2) Customize with menuconfig, target ABI is OABI
# BR2_iwmmxt is not set
BR2_ARM_TYPE="ARM920T"
# BR2_ARM_EABI is not set
BR2_ARM_OABI=y
BR2_ARCH="arm"
BR2_ENDIAN="LITTLE"
BR2_GCC_TARGET_TUNE="arm920t"
BR2_GCC_TARGET_ARCH="armv4t"
BR2_GCC_TARGET_ABI="apcs-gnu"
3) Customize Linux(2.6.27), target is ABI is OABI
CONFIG_HZ=128
# CONFIG_AEABI is not set
CONFIG_ARCH_FLATMEM_HAS_HOLES=y
4) Customize BusyBox(1.15), build system, everything is OK, target system boot
and running
5) If I touch (nothing modify) the uClibc config and try to (re)make a system,
I get something: (.ARM.exidx+0x0): undefined reference to
`__aeabi_unwind_cpp_pr0'
uClibc's config:
#
# Target Architecture Features and Options
#
TARGET_ARCH="arm"
FORCE_OPTIONS_FOR_ARCH=y
CONFIG_ARM_OABI=y
# CONFIG_ARM_EABI is not set
# USE_BX is not set
# CONFIG_GENERIC_ARM is not set
# CONFIG_ARM610 is not set
# CONFIG_ARM710 is not set
# CONFIG_ARM7TDMI is not set
# CONFIG_ARM720T is not set
CONFIG_ARM920T=y
6) Clean, working config (without step 5), I add some options (target toolchain
building) in buildroot config (without touching uClibc config), and start make
process, I get this:
CC libc/unistd/usershell.os
CC libc/unistd/usleep.os
CC libpthread/linuxthreads.old/forward.oS
CC libpthread/linuxthreads.old/libc_pthread_init.oS
CC libc/misc/elf/dl-iterate-phdr.oS
CC libc/misc/internals/__uClibc_main.oS
CC libpthread/linuxthreads.old/libc_pthread_init.os
CC libc/misc/elf/dl-support.os
CC libc/misc/elf/dl-core.os
CC libc/misc/elf/dl-iterate-phdr.os
CC libc/misc/internals/__uClibc_main.os
CC libc/stdlib/atexit.os
AR cr lib/libc.a
STRIP -x -R .note -R .comment lib/libc.a
AR cr lib/uclibc_nonshared.a
STRIP -x -R .note -R .comment lib/uclibc_nonshared.a
AR cr libc/libc_so.a
STRIP -x -R .note -R .comment libc/libc_so.a
LD libuClibc-0.9.30.1.so
/srv/buildroot-2009.11/output/staging/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.2/libgcc.a(_divdi3.o):(.ARM.exidx+0x0):
undefined reference to `__aeabi_unwind_cpp_pr0'
collect2: ld returned 1 exit status
make[1]: *** [lib/libc.so] Error 1
make[1]: Leaving directory
`/srv/buildroot-2009.11/output/toolchain/uClibc-0.9.30.1'
make: *** [/srv/buildroot-2009.11/output/target/usr/lib/libc.a] Error 2
Build environment:
Ubuntu 9.10 with bash, not dash.
Linux xxxxx 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:53:52 UTC 2009
x86_64 GNU/Linux
Target environment:
AT91RM9200 based custom board
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ 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.