* [PATCH 1/2 v1] davinci: support disabling modem status interrupts on SOC UARTS
From: Kevin Hilman @ 2011-02-01 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D44803E.8000703@criticallink.com>
Michael Williamson <michael.williamson@criticallink.com> writes:
> Hi Kevin...
>
> On 01/05/2011 07:26 AM, Michael Williamson wrote:
>> On the da850/omap-l138/am18x family of SoCs, up to three on chip UARTS may be
>> configured. These peripherals support the standard Tx/Rx signals as well as
>> CTS/RTS hardware flow control signals. The pins on these SOC's associated with
>> these signals are multiplexed; e.g., the pin providing UART0_TXD capability
>> also provides SPI0 chip select line 5 output capability. The configuration of
>> the pin multiplexing occurs during platform initialization (or by earlier
>> bootloader operations).
>>
>> There is a problem with the multiplexing implementation on these SOCs. Only
>> the output and output enable portions of the I/O section of the pin are
>> multiplexed. All peripheral input functions remain connected to a given pin
>> regardless of configuration.
>>
>> In many configurations of these parts, providing a UART with Tx/Rx capability
>> is needed, but the HW flow control capability is not. Furthermore, the pins
>> associated with the CTS inputs on these UARTS are often configured to support
>> a different peripheral, and they may be active/toggling during runtime. This
>> can result in false modem status (CTS) interrupts being asserted to the 8250
>> driver controlling the associated Tx/Rx pins, and will impact system
>> performance.
>>
>> The 8250 serial driver platform data does not provide a direct mechanism to
>> tell the driver to disable modem status (i.e., CTS) interrupts for a given
>> port. As a work-around, intercept register writes to the IER and disable
>> modem status interrupts.
>>
>> This patch was tested using a MityDSP-L138 SOM having UART1 enabled with the
>> associated CTS pin connected to a clock (configured for the AHCLKX function).
>>
>> Background / problem reports related to this issue are captured in the links
>> below:
>> http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/36701.aspx
>> http://www.mail-archive.com/davinci-linux-open-source at linux.davincidsp.com/msg19524.html
>>
>> Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
>> Tested-by: Michael Williamson <michael.williamson@criticallink.com>
>> ---
>> This is against the linux-davinci tree.
>>
>> Changes from original proposed patch:
>> - instead of overriding set_termios, now override serial_out driver hook
>> and intercept writes to the MSR.
>>
>> An alternate patch was proposed that modified the serial core driver and added a UPF_NO_MSR
>> flag. There was resistance to this patch. The reasoning is that the core 8250 driver code
>> should not continue to get muddied by platform hacks.
>>
>
> I'd like to withdraw this patch. It works, but it's inefficient and ugly, and
> I also get the feeling it isn't going to make it in it's current form anyway.
>
> I have another patch that is limited to just the mityomapl138 platform that
> I would like to submit in place of this. No other board appears to have this
> problem, so it makes sense to constrain the fix to platform file that does.
>
OK
Kevin
^ permalink raw reply
* RE: Kernel 2.6.32-5-amd64 fails to boot.
From: Leslie Rhorer @ 2011-02-01 20:52 UTC (permalink / raw)
To: 'Rudy Zijlstra'; +Cc: 'Linux RAID'
In-Reply-To: <4D487066.2010703@grumpydevil.homelinux.org>
> On 02/01/2011 09:23 PM, Leslie Rhorer wrote:
> > I have been attempting to upgrade a Debian "Squeeze" Linux box from
> > 2.6.32-3-amd64 to 2.6.32-5-amd64, but the upgrade is a non-starter.
> GRUB2
> > comes up just fine, but when I select the new kernel version, a number
> of
> > announcements flash by too fast to seen. I am not 100% certain, but I
> > believe the initrd starts to load OK. Some text flies by far too quickly
> to
> > be seen, but then an error pops up concerning an address space collision
> of
> > some PCI device. Then it shows three errors for RAID devices md1. md2,
> and
> > md3, saying they are already in use. Immediately thereafter the system
> shows
> > errors concerning the RAID targets being already in use, after which
> point
> > the system complains it can't mount / (md2), /dev, /sys, or /proc (in
> that
> > order) because the sources do not exist (if /dev/md2 does not exist, how
> can
> > it be busy?). Thereafter, of course, it fails to find init, since / is
> not
> > mounted. It then tries to run BusyBox, but Busybox complains:
> >
> > /bin/sh: can't access tty; job control turned off
> >
> > After that, it attempts to put up an initramfs prompt, but of course
> with no
> > tty access, it just hangs completely. Not surprisingly, recovery mode
> > doesn't boot, either. It gives a bit more detail in the output, but
> nothing
> > illuminating. The old kernel (2.6.32-3-amd64) boots just fine.
> >
>
> Can you enable serial console and catch the console output that way?
Well, not easily. I don't have a serial terminal. I suppose I
could set something up. You're suggesting I poke around to see what md is
reporting? Also, I'm not sure why - if the keyboard console is failing -
the serial console would work better.
> Cheers
>
> Rudy
> > Obviously there is a problem in the initramfs, probably with mdadm, but
> > what? What should I try to manipulate in the initrd so I can find out
> what
> > is failing?
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-raid" 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
* [Buildroot] [PATCH] Makefile.package.in: fix upper case $(PKG)_SITE_METHOD
From: Daniel Nyström @ 2011-02-01 20:51 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20110201213433.1d527342@surf>
011/2/1 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> On Tue, ?1 Feb 2011 12:18:49 +0100
> Bj?rn Forsman <bjorn.forsman@gmail.com> wrote:
>
>> ? ? ? ? ? ? ? case "$($(PKG)_SITE_METHOD)" in \
>> - ? ? ? ? ? ? ? ? ? ? git) $($(DL_MODE)_GIT) && exit ;; \
>> - ? ? ? ? ? ? ? ? ? ? svn) $($(DL_MODE)_SVN) && exit ;; \
>> - ? ? ? ? ? ? ? ? ? ? bzr) $($(DL_MODE)_BZR) && exit ;; \
>> + ? ? ? ? ? ? ? ? ? ? GIT) $($(DL_MODE)_GIT) && exit ;; \
>> + ? ? ? ? ? ? ? ? ? ? SVN) $($(DL_MODE)_SVN) && exit ;; \
>> + ? ? ? ? ? ? ? ? ? ? BZR) $($(DL_MODE)_BZR) && exit ;; \
>> ? ? ? ? ? ? ? ? ? ? ? *) $(call $(DL_MODE)_WGET,$(1),$(2)) && exit ;; \
>> ? ? ? ? ? ? ? esac ; \
>> ? ? ? fi ; \
>
> No. This is going to break:
>
> ? ? ? ?# Try automatic detection using the scheme part of the URI
> ? ? ? ?$(2)_SITE_METHOD = $(firstword $(subst ://, ,$(call qstrip,$($(2)_SITE))))
>
> is used to detect the site method from the URI, like :
>
> ? ? ? ?git://....
>
> or
>
> ? ? ? ?svn://....
>
> so if only upper case site methods are accepted, it's not going to work.
>
> And more generally, I'd prefer to keep the existing lower-case writing
> of the site method, since it is coherent with how it's written in the
> URI.
Maybe, after all, this is a special case where both upper and lower
case should work?
^ permalink raw reply
* Re: nbd / hot plug
From: Roberto Spadim @ 2011-02-01 20:49 UTC (permalink / raw)
To: paul.clements; +Cc: Linux-RAID
In-Reply-To: <AANLkTi=uPpV0BGoMQytTofa3986a08GMGHT_8areu6Jk@mail.gmail.com>
nice =D raid over ethernet! =D
just a heart beath and a primary decision algorithm to make a HA :D
thanks for the notice paul
i didn´t like drbd it´s have a algorithm that i can´t execute since my
app must return the primary decision algorithm :/
2011/2/1 Paul Clements <paul.clements@steeleye.com>:
> On Sun, Jan 30, 2011 at 3:27 PM, Roberto Spadim <roberto@spadim.com.br> wrote:
>> hi guys, i was thinking about nbd problems with server disconnection /
>> client disconnection
>> it's not like a SATA disk hot plug?
>> for example unplug the disk (SATA) = unplug the network card
>> could md raid work with it?
>> i tried but i should run
>> mdadm fail / remove / add
>> to get nbd back in array, it's right?
>
> Yes, nbd with md/raid works fine. If the nbd connection gets broken,
> the nbd component of the array will fail, you can then remove it and
> re-add it.
>
> --
> Paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" 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
* Re: [PATCH] isimodem: fix crash in sms driver
From: Aki Niemi @ 2011-02-01 20:47 UTC (permalink / raw)
To: ofono
In-Reply-To: <1296592629-31227-1-git-send-email-Pekka.Pessi@nokia.com>
[-- Attachment #1: Type: text/plain, Size: 303 bytes --]
Hi Pekka,
On Tue, 2011-02-01 at 22:37 +0200, ext Pekka.Pessi(a)nokia.com wrote:
> From: Pekka Pessi <Pekka.Pessi@nokia.com>
>
> ---
> drivers/isimodem/sms.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Pushed this patch, thanks for spotting the problem.
Cheers,
Aki
^ permalink raw reply
* Re: [patch 07/28] posix-timers: Convert clock_nanosleep_restart to clockid_to_kclock()
From: Thomas Gleixner @ 2011-02-01 20:46 UTC (permalink / raw)
To: John Stultz; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <1296592977.3336.25.camel@work-vm>
On Tue, 1 Feb 2011, John Stultz wrote:
> On Tue, 2011-02-01 at 13:51 +0000, Thomas Gleixner wrote:
> > plain text document attachment
> > (posix-timers-convert-nanosleep-restart.patch)
> > Use the new kclock decoding function in clock_nanosleep_restart. No
> > need to check kclock here as the restart block always contains a valid
> > clockid. If not, we are in serious trouble anyway.
> >
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > Cc: John Stultz <john.stultz@linaro.org>
> > Cc: Richard Cochran <richard.cochran@omicron.at>
>
> One nit.
>
> > -long
> > -clock_nanosleep_restart(struct restart_block *restart_block)
> > +long clock_nanosleep_restart(struct restart_block *restart_block)
> > {
> > clockid_t which_clock = restart_block->arg0;
> > + struct k_clock *kc = clockid_to_kclock(which_clock);
> >
> > - return CLOCK_DISPATCH(which_clock, nsleep_restart,
> > - (restart_block));
> > + return kc->nsleep_restart(restart_block);
> > }
>
>
> Should you be checking if kc is null before dereferencing? Or am I being
> overly paranoid?
See changelog. If we get a corrupted restart_block then checking kc is
probably the least of our worries.
Thanks,
tglx
^ permalink raw reply
* Re: [BUG 2.6.32] md/raid1: barrier disabling does not work correctly in all cases
From: Paul Clements @ 2011-02-01 20:45 UTC (permalink / raw)
To: NeilBrown; +Cc: linux-raid
In-Reply-To: <AANLkTi=NqHV9p0rc4VBBNAzxwjvfA0DpKgkxQpsX9gsT@mail.gmail.com>
On Wed, Jan 26, 2011 at 8:55 AM, Paul Clements
<paul.clements@us.sios.com> wrote:
> Attached is a modified patch, which does the extra necessary work
> (bitmap_endwrite, md_write_end) on the bio before failing it.
>
> Does this look correct? It seems to work.
Well, not quite...it's more complicated. From my reading of the code,
it looks like behind writes and barrier retries just do not work
correctly together. The issue is this:
- With behind writes, we signal the master_bio complete as soon as all
non-write-behind writes are complete.
- With barrier retries, you don't know if you'll need to retry until
you've completed all legs of the write (the last leg to complete might
throw EOPNOTSUPP).
So in the case where the master_bio has been completed, we still try
to do a retry for the leg that failed the barrier (but it's really too
late to retry). In any case, raid1d is touching master_bio (looking at
bi_size and bio_cloning it) during the retry, which causes a panic if
master_bio is already being reused by someone else.
I can't think of a good way to do behind writes and barrier retries
together. Seems we've got to disable behind writes for barriers, or
we've got to disable barrier retries when doing behind writes...
Any thoughts?
--
Paul
^ permalink raw reply
* pull request: wireless-2.6 2011-02-01
From: John W. Linville @ 2011-02-01 20:40 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is another batch of fixes intended for 2.6.38.
Included is a firmware upload fix for rtlwifi, a use after free
fix for wl12xx, a memory fix related to PAPRD for ath9k, a couple
of PM-related fixes for ath9k, fixes for race conditions that lead
to crashes in ath9k and ath9k_htc, and a couple of ath5k fixes, one
related to dma error handling and the other an endian fix. A email
address change in the MAINTAINERS entry for wl12xx tops it all off. :-)
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit fca540ab5f4718c6133f71f7be1793066008bf89:
enc28j60: Fix reading of transmit status vector (2011-01-31 20:56:54 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Bob Copeland (2):
ath5k: fix error handling in ath5k_hw_dma_stop
ath5k: correct endianness of frame duration
Chaoming Li (1):
rtlwifi: Fix firmware upload errors
Luciano Coelho (1):
MAINTAINERS: update information for the wl12xx driver
Mathias Krause (1):
wl12xx: fix use after free
Mohammed Shafi Shajakhan (1):
ath9k: Fix memory leak due to failed PAPRD frames
Rajkumar Manoharan (2):
ath9k_hw: Fix system hang when resuming from S3/S4
ath9k: Fix power save usage count imbalance on deinit
Stanislaw Gruszka (2):
ath9k: fix race conditions when stop device
ath9k_htc: fix race conditions when stop device
MAINTAINERS | 6 ++--
drivers/net/wireless/ath/ath5k/dma.c | 4 +-
drivers/net/wireless/ath/ath5k/pcu.c | 4 +--
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 3 +-
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 3 --
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 21 +++++++++----
drivers/net/wireless/ath/ath9k/init.c | 7 +---
drivers/net/wireless/ath/ath9k/main.c | 19 ++++++++++--
drivers/net/wireless/rtlwifi/efuse.c | 40 ++++++++++++------------
drivers/net/wireless/wl12xx/spi.c | 3 +-
10 files changed, 61 insertions(+), 49 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c9ec9d8..a5deb42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6612,12 +6612,12 @@ S: Maintained
F: drivers/net/wireless/wl1251/*
WL1271 WIRELESS DRIVER
-M: Luciano Coelho <luciano.coelho@nokia.com>
+M: Luciano Coelho <coelho@ti.com>
L: linux-wireless@vger.kernel.org
-W: http://wireless.kernel.org
+W: http://wireless.kernel.org/en/users/Drivers/wl12xx
T: git git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git
S: Maintained
-F: drivers/net/wireless/wl12xx/wl1271*
+F: drivers/net/wireless/wl12xx/
F: include/linux/wl12xx.h
WL3501 WIRELESS PCMCIA CARD DRIVER
diff --git a/drivers/net/wireless/ath/ath5k/dma.c b/drivers/net/wireless/ath/ath5k/dma.c
index 0064be7..21091c2 100644
--- a/drivers/net/wireless/ath/ath5k/dma.c
+++ b/drivers/net/wireless/ath/ath5k/dma.c
@@ -838,9 +838,9 @@ int ath5k_hw_dma_stop(struct ath5k_hw *ah)
for (i = 0; i < qmax; i++) {
err = ath5k_hw_stop_tx_dma(ah, i);
/* -EINVAL -> queue inactive */
- if (err != -EINVAL)
+ if (err && err != -EINVAL)
return err;
}
- return err;
+ return 0;
}
diff --git a/drivers/net/wireless/ath/ath5k/pcu.c b/drivers/net/wireless/ath/ath5k/pcu.c
index e5f2b96..a702817 100644
--- a/drivers/net/wireless/ath/ath5k/pcu.c
+++ b/drivers/net/wireless/ath/ath5k/pcu.c
@@ -86,7 +86,7 @@ int ath5k_hw_get_frame_duration(struct ath5k_hw *ah,
if (!ah->ah_bwmode) {
dur = ieee80211_generic_frame_duration(sc->hw,
NULL, len, rate);
- return dur;
+ return le16_to_cpu(dur);
}
bitrate = rate->bitrate;
@@ -265,8 +265,6 @@ static inline void ath5k_hw_write_rate_duration(struct ath5k_hw *ah)
* what rate we should choose to TX ACKs. */
tx_time = ath5k_hw_get_frame_duration(ah, 10, rate);
- tx_time = le16_to_cpu(tx_time);
-
ath5k_hw_reg_write(ah, tx_time, reg);
if (!(rate->flags & IEEE80211_RATE_SHORT_PREAMBLE))
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_hw.c b/drivers/net/wireless/ath/ath9k/ar9002_hw.c
index f8a7771..f44c84a 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_hw.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_hw.c
@@ -426,9 +426,8 @@ static void ar9002_hw_configpcipowersave(struct ath_hw *ah,
}
/* WAR for ASPM system hang */
- if (AR_SREV_9280(ah) || AR_SREV_9285(ah) || AR_SREV_9287(ah)) {
+ if (AR_SREV_9285(ah) || AR_SREV_9287(ah))
val |= (AR_WA_BIT6 | AR_WA_BIT7);
- }
if (AR_SREV_9285E_20(ah))
val |= AR_WA_BIT23;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 38433f9..0352f09 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -142,9 +142,6 @@ static void ath9k_deinit_priv(struct ath9k_htc_priv *priv)
{
ath9k_htc_exit_debug(priv->ah);
ath9k_hw_deinit(priv->ah);
- tasklet_kill(&priv->swba_tasklet);
- tasklet_kill(&priv->rx_tasklet);
- tasklet_kill(&priv->tx_tasklet);
kfree(priv->ah);
priv->ah = NULL;
}
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index f4d576b..6bb5995 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1025,12 +1025,6 @@ static void ath9k_htc_stop(struct ieee80211_hw *hw)
int ret = 0;
u8 cmd_rsp;
- /* Cancel all the running timers/work .. */
- cancel_work_sync(&priv->fatal_work);
- cancel_work_sync(&priv->ps_work);
- cancel_delayed_work_sync(&priv->ath9k_led_blink_work);
- ath9k_led_stop_brightness(priv);
-
mutex_lock(&priv->mutex);
if (priv->op_flags & OP_INVALID) {
@@ -1044,8 +1038,23 @@ static void ath9k_htc_stop(struct ieee80211_hw *hw)
WMI_CMD(WMI_DISABLE_INTR_CMDID);
WMI_CMD(WMI_DRAIN_TXQ_ALL_CMDID);
WMI_CMD(WMI_STOP_RECV_CMDID);
+
+ tasklet_kill(&priv->swba_tasklet);
+ tasklet_kill(&priv->rx_tasklet);
+ tasklet_kill(&priv->tx_tasklet);
+
skb_queue_purge(&priv->tx_queue);
+ mutex_unlock(&priv->mutex);
+
+ /* Cancel all the running timers/work .. */
+ cancel_work_sync(&priv->fatal_work);
+ cancel_work_sync(&priv->ps_work);
+ cancel_delayed_work_sync(&priv->ath9k_led_blink_work);
+ ath9k_led_stop_brightness(priv);
+
+ mutex_lock(&priv->mutex);
+
/* Remove monitor interface here */
if (ah->opmode == NL80211_IFTYPE_MONITOR) {
if (ath9k_htc_remove_monitor_interface(priv))
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 767d8b8..087a6a9 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -598,8 +598,6 @@ err_btcoex:
err_queues:
ath9k_hw_deinit(ah);
err_hw:
- tasklet_kill(&sc->intr_tq);
- tasklet_kill(&sc->bcon_tasklet);
kfree(ah);
sc->sc_ah = NULL;
@@ -807,9 +805,6 @@ static void ath9k_deinit_softc(struct ath_softc *sc)
ath9k_hw_deinit(sc->sc_ah);
- tasklet_kill(&sc->intr_tq);
- tasklet_kill(&sc->bcon_tasklet);
-
kfree(sc->sc_ah);
sc->sc_ah = NULL;
}
@@ -824,6 +819,8 @@ void ath9k_deinit_device(struct ath_softc *sc)
wiphy_rfkill_stop_polling(sc->hw->wiphy);
ath_deinit_leds(sc);
+ ath9k_ps_restore(sc);
+
for (i = 0; i < sc->num_sec_wiphy; i++) {
struct ath_wiphy *aphy = sc->sec_wiphy[i];
if (aphy == NULL)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index c79c97b..9040c2f 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -325,6 +325,8 @@ static bool ath_paprd_send_frame(struct ath_softc *sc, struct sk_buff *skb, int
{
struct ieee80211_hw *hw = sc->hw;
struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
+ struct ath_hw *ah = sc->sc_ah;
+ struct ath_common *common = ath9k_hw_common(ah);
struct ath_tx_control txctl;
int time_left;
@@ -342,8 +344,12 @@ static bool ath_paprd_send_frame(struct ath_softc *sc, struct sk_buff *skb, int
init_completion(&sc->paprd_complete);
sc->paprd_pending = true;
txctl.paprd = BIT(chain);
- if (ath_tx_start(hw, skb, &txctl) != 0)
+
+ if (ath_tx_start(hw, skb, &txctl) != 0) {
+ ath_dbg(common, ATH_DBG_XMIT, "PAPRD TX failed\n");
+ dev_kfree_skb_any(skb);
return false;
+ }
time_left = wait_for_completion_timeout(&sc->paprd_complete,
msecs_to_jiffies(ATH_PAPRD_TIMEOUT));
@@ -953,8 +959,6 @@ void ath_radio_disable(struct ath_softc *sc, struct ieee80211_hw *hw)
spin_unlock_bh(&sc->sc_pcu_lock);
ath9k_ps_restore(sc);
-
- ath9k_setpower(sc, ATH9K_PM_FULL_SLEEP);
}
int ath_reset(struct ath_softc *sc, bool retry_tx)
@@ -1309,6 +1313,9 @@ static void ath9k_stop(struct ieee80211_hw *hw)
spin_lock_bh(&sc->sc_pcu_lock);
+ /* prevent tasklets to enable interrupts once we disable them */
+ ah->imask &= ~ATH9K_INT_GLOBAL;
+
/* make sure h/w will not generate any interrupt
* before setting the invalid flag. */
ath9k_hw_disable_interrupts(ah);
@@ -1326,6 +1333,12 @@ static void ath9k_stop(struct ieee80211_hw *hw)
spin_unlock_bh(&sc->sc_pcu_lock);
+ /* we can now sync irq and kill any running tasklets, since we already
+ * disabled interrupts and not holding a spin lock */
+ synchronize_irq(sc->irq);
+ tasklet_kill(&sc->intr_tq);
+ tasklet_kill(&sc->bcon_tasklet);
+
ath9k_ps_restore(sc);
sc->ps_idle = true;
diff --git a/drivers/net/wireless/rtlwifi/efuse.c b/drivers/net/wireless/rtlwifi/efuse.c
index b8433f3..62876cd 100644
--- a/drivers/net/wireless/rtlwifi/efuse.c
+++ b/drivers/net/wireless/rtlwifi/efuse.c
@@ -726,9 +726,9 @@ static int efuse_pg_packet_read(struct ieee80211_hw *hw, u8 offset, u8 *data)
}
static void efuse_write_data_case1(struct ieee80211_hw *hw, u16 *efuse_addr,
- u8 efuse_data, u8 offset, int *bcontinual,
- u8 *write_state, struct pgpkt_struct target_pkt,
- int *repeat_times, int *bresult, u8 word_en)
+ u8 efuse_data, u8 offset, int *bcontinual,
+ u8 *write_state, struct pgpkt_struct *target_pkt,
+ int *repeat_times, int *bresult, u8 word_en)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct pgpkt_struct tmp_pkt;
@@ -744,8 +744,8 @@ static void efuse_write_data_case1(struct ieee80211_hw *hw, u16 *efuse_addr,
tmp_pkt.word_en = tmp_header & 0x0F;
tmp_word_cnts = efuse_calculate_word_cnts(tmp_pkt.word_en);
- if (tmp_pkt.offset != target_pkt.offset) {
- efuse_addr = efuse_addr + (tmp_word_cnts * 2) + 1;
+ if (tmp_pkt.offset != target_pkt->offset) {
+ *efuse_addr = *efuse_addr + (tmp_word_cnts * 2) + 1;
*write_state = PG_STATE_HEADER;
} else {
for (tmpindex = 0; tmpindex < (tmp_word_cnts * 2); tmpindex++) {
@@ -756,23 +756,23 @@ static void efuse_write_data_case1(struct ieee80211_hw *hw, u16 *efuse_addr,
}
if (bdataempty == false) {
- efuse_addr = efuse_addr + (tmp_word_cnts * 2) + 1;
+ *efuse_addr = *efuse_addr + (tmp_word_cnts * 2) + 1;
*write_state = PG_STATE_HEADER;
} else {
match_word_en = 0x0F;
- if (!((target_pkt.word_en & BIT(0)) |
+ if (!((target_pkt->word_en & BIT(0)) |
(tmp_pkt.word_en & BIT(0))))
match_word_en &= (~BIT(0));
- if (!((target_pkt.word_en & BIT(1)) |
+ if (!((target_pkt->word_en & BIT(1)) |
(tmp_pkt.word_en & BIT(1))))
match_word_en &= (~BIT(1));
- if (!((target_pkt.word_en & BIT(2)) |
+ if (!((target_pkt->word_en & BIT(2)) |
(tmp_pkt.word_en & BIT(2))))
match_word_en &= (~BIT(2));
- if (!((target_pkt.word_en & BIT(3)) |
+ if (!((target_pkt->word_en & BIT(3)) |
(tmp_pkt.word_en & BIT(3))))
match_word_en &= (~BIT(3));
@@ -780,7 +780,7 @@ static void efuse_write_data_case1(struct ieee80211_hw *hw, u16 *efuse_addr,
badworden = efuse_word_enable_data_write(
hw, *efuse_addr + 1,
tmp_pkt.word_en,
- target_pkt.data);
+ target_pkt->data);
if (0x0F != (badworden & 0x0F)) {
u8 reorg_offset = offset;
@@ -791,26 +791,26 @@ static void efuse_write_data_case1(struct ieee80211_hw *hw, u16 *efuse_addr,
}
tmp_word_en = 0x0F;
- if ((target_pkt.word_en & BIT(0)) ^
+ if ((target_pkt->word_en & BIT(0)) ^
(match_word_en & BIT(0)))
tmp_word_en &= (~BIT(0));
- if ((target_pkt.word_en & BIT(1)) ^
+ if ((target_pkt->word_en & BIT(1)) ^
(match_word_en & BIT(1)))
tmp_word_en &= (~BIT(1));
- if ((target_pkt.word_en & BIT(2)) ^
+ if ((target_pkt->word_en & BIT(2)) ^
(match_word_en & BIT(2)))
tmp_word_en &= (~BIT(2));
- if ((target_pkt.word_en & BIT(3)) ^
+ if ((target_pkt->word_en & BIT(3)) ^
(match_word_en & BIT(3)))
tmp_word_en &= (~BIT(3));
if ((tmp_word_en & 0x0F) != 0x0F) {
*efuse_addr = efuse_get_current_size(hw);
- target_pkt.offset = offset;
- target_pkt.word_en = tmp_word_en;
+ target_pkt->offset = offset;
+ target_pkt->word_en = tmp_word_en;
} else
*bcontinual = false;
*write_state = PG_STATE_HEADER;
@@ -821,8 +821,8 @@ static void efuse_write_data_case1(struct ieee80211_hw *hw, u16 *efuse_addr,
}
} else {
*efuse_addr += (2 * tmp_word_cnts) + 1;
- target_pkt.offset = offset;
- target_pkt.word_en = word_en;
+ target_pkt->offset = offset;
+ target_pkt->word_en = word_en;
*write_state = PG_STATE_HEADER;
}
}
@@ -938,7 +938,7 @@ static int efuse_pg_packet_write(struct ieee80211_hw *hw,
efuse_write_data_case1(hw, &efuse_addr,
efuse_data, offset,
&bcontinual,
- &write_state, target_pkt,
+ &write_state, &target_pkt,
&repeat_times, &bresult,
word_en);
else
diff --git a/drivers/net/wireless/wl12xx/spi.c b/drivers/net/wireless/wl12xx/spi.c
index 4671491..7145ea5 100644
--- a/drivers/net/wireless/wl12xx/spi.c
+++ b/drivers/net/wireless/wl12xx/spi.c
@@ -110,9 +110,8 @@ static void wl1271_spi_reset(struct wl1271 *wl)
spi_message_add_tail(&t, &m);
spi_sync(wl_to_spi(wl), &m);
- kfree(cmd);
-
wl1271_dump(DEBUG_SPI, "spi reset -> ", cmd, WSPI_INIT_CMD_LEN);
+ kfree(cmd);
}
static void wl1271_spi_init(struct wl1271 *wl)
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Соберeм для Вас пo ceти интеpнeт бaзу дaнных пoтeнциальныx клиeнтов для Baшегo Бизнeca (нaзваниe, телефoн, фakс, email, caйт, имена и дp инфoрмацию) Многo! Быcтpo! Точно! Узнайтe болeе пoдpoбнyю инфоpмaцию пo: Teлeфoн +79133913837 ICQ: 6288862 Skype: prodawez3837 Email: prodawez@mixmail.com
From: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f @ 2011-02-01 20:44 UTC (permalink / raw)
To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Cоберeм для Bас по сeти интеpнeт бaзу дaнных
потeнциальныx клиeнтoв для Baшегo Бизнeсa
(нaзваниe, телефoн, фakc, email, caйт, имена и дp инфoрмацию)
Mногo! Быcтpo! Toчно!
Узнайтe бoлeе подpобнyю инфоpмaцию пo:
Teлeфон +79133913837
ICQ: 6288862
Skype: prodawez3837
Email: prodawez@mixmail.com
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
^ permalink raw reply
* [PATCH v3] virtio_blk: allow re-reading config space at runtime
From: Christoph Hellwig @ 2011-02-01 20:43 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Christoph Hellwig, Rusty Russell, linux-kernel
In-Reply-To: <20110201195136.GA26688@redhat.com>
Wire up the virtio_driver config_changed method to get notified about
config changes raised by the host. For now we just re-read the device
size to support online resizing of devices, but once we add more
attributes that might be changeable they could be added as well.
Note that the config_changed method is called from irq context, so
we'll have to use the workqueue infrastructure to provide us a proper
user context for our changes.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6/drivers/block/virtio_blk.c
===================================================================
--- linux-2.6.orig/drivers/block/virtio_blk.c 2010-12-01 09:30:59.647253809 -0700
+++ linux-2.6/drivers/block/virtio_blk.c 2011-02-01 13:37:29.355728726 -0700
@@ -6,10 +6,12 @@
#include <linux/virtio.h>
#include <linux/virtio_blk.h>
#include <linux/scatterlist.h>
+#include <linux/string_helpers.h>
#define PART_BITS 4
static int major, index;
+struct workqueue_struct *virtblk_wq;
struct virtio_blk
{
@@ -26,6 +28,9 @@ struct virtio_blk
mempool_t *pool;
+ /* Process context for config space updates */
+ struct work_struct config_work;
+
/* What host tells us, plus 2 for header & tailer. */
unsigned int sg_elems;
@@ -291,6 +296,46 @@ static ssize_t virtblk_serial_show(struc
}
DEVICE_ATTR(serial, S_IRUGO, virtblk_serial_show, NULL);
+static void virtblk_config_changed_work(struct work_struct *work)
+{
+ struct virtio_blk *vblk =
+ container_of(work, struct virtio_blk, config_work);
+ struct virtio_device *vdev = vblk->vdev;
+ struct request_queue *q = vblk->disk->queue;
+ char cap_str_2[10], cap_str_10[10];
+ u64 capacity, size;
+
+ /* Host must always specify the capacity. */
+ vdev->config->get(vdev, offsetof(struct virtio_blk_config, capacity),
+ &capacity, sizeof(capacity));
+
+ /* If capacity is too big, truncate with warning. */
+ if ((sector_t)capacity != capacity) {
+ dev_warn(&vdev->dev, "Capacity %llu too large: truncating\n",
+ (unsigned long long)capacity);
+ capacity = (sector_t)-1;
+ }
+
+ size = capacity * queue_logical_block_size(q);
+ string_get_size(size, STRING_UNITS_2, cap_str_2, sizeof(cap_str_2));
+ string_get_size(size, STRING_UNITS_10, cap_str_10, sizeof(cap_str_10));
+
+ dev_notice(&vdev->dev,
+ "new size: %llu %d-byte logical blocks (%s/%s)\n",
+ (unsigned long long)capacity,
+ queue_logical_block_size(q),
+ cap_str_10, cap_str_2);
+
+ set_capacity(vblk->disk, capacity);
+}
+
+static void virtblk_config_changed(struct virtio_device *vdev)
+{
+ struct virtio_blk *vblk = vdev->priv;
+
+ queue_work(virtblk_wq, &vblk->config_work);
+}
+
static int __devinit virtblk_probe(struct virtio_device *vdev)
{
struct virtio_blk *vblk;
@@ -327,6 +372,7 @@ static int __devinit virtblk_probe(struc
vblk->vdev = vdev;
vblk->sg_elems = sg_elems;
sg_init_table(vblk->sg, vblk->sg_elems);
+ INIT_WORK(&vblk->config_work, virtblk_config_changed_work);
/* We expect one virtqueue, for output. */
vblk->vq = virtio_find_single_vq(vdev, blk_done, "requests");
@@ -477,6 +523,8 @@ static void __devexit virtblk_remove(str
{
struct virtio_blk *vblk = vdev->priv;
+ flush_work(&vblk->config_work);
+
/* Nothing should be pending. */
BUG_ON(!list_empty(&vblk->reqs));
@@ -508,27 +556,47 @@ static unsigned int features[] = {
* Use __refdata to avoid this warning.
*/
static struct virtio_driver __refdata virtio_blk = {
- .feature_table = features,
- .feature_table_size = ARRAY_SIZE(features),
- .driver.name = KBUILD_MODNAME,
- .driver.owner = THIS_MODULE,
- .id_table = id_table,
- .probe = virtblk_probe,
- .remove = __devexit_p(virtblk_remove),
+ .feature_table = features,
+ .feature_table_size = ARRAY_SIZE(features),
+ .driver.name = KBUILD_MODNAME,
+ .driver.owner = THIS_MODULE,
+ .id_table = id_table,
+ .probe = virtblk_probe,
+ .remove = __devexit_p(virtblk_remove),
+ .config_changed = virtblk_config_changed,
};
static int __init init(void)
{
+ int error;
+
+ virtblk_wq = alloc_workqueue("virtio-blk", 0, 0);
+ if (!virtblk_wq)
+ return -ENOMEM;
+
major = register_blkdev(0, "virtblk");
- if (major < 0)
- return major;
- return register_virtio_driver(&virtio_blk);
+ if (major < 0) {
+ error = major;
+ goto out_destroy_workqueue;
+ }
+
+ error = register_virtio_driver(&virtio_blk);
+ if (error)
+ goto out_unregister_blkdev;
+ return 0;
+
+out_unregister_blkdev:
+ unregister_blkdev(major, "virtblk");
+out_destroy_workqueue:
+ destroy_workqueue(virtblk_wq);
+ return error;
}
static void __exit fini(void)
{
unregister_blkdev(major, "virtblk");
unregister_virtio_driver(&virtio_blk);
+ destroy_workqueue(virtblk_wq);
}
module_init(init);
module_exit(fini);
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Uwe Kleine-König @ 2011-02-01 20:43 UTC (permalink / raw)
To: Saravana Kannan
Cc: Russell King - ARM Linux, Nicolas Pitre, Dima Zavin,
Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt,
Sascha Hauer, Paul Mundt, linux-kernel, Ben Dooks, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <4D486B59.6010106@codeaurora.org>
Hello,
On Tue, Feb 01, 2011 at 12:21:45PM -0800, Saravana Kannan wrote:
> If the driver is calling clk_prepare() right next to clk_enable()
> knowing it's been already prepared and will hence be "atomic" (this
> is actually not true), then by your description, it's pointless to
> call clk_prepare().
Well not completely, as it increases the reference count. The advantage
would be that clk_enable counts addionally as prepare, so it would be
impossible to unprepare an enabled clock. And the other way round an
unprepared clock would never be enabled.
> If you want the driver to call clk_prepare() in atomic context
> because it will be atomic in most cases -- well, that's wrong. It's
> either atomic or is NOT atomic. There is no in between. If a call is
> NOT atomic, it can't be called in atomic context. Long story short,
> if you expect clk_prepare() to be atomic under any circumstance, it
> beats the point of introducing clk_prepare().
Well, with my suggestion it's atomic when certain precondions are given.
IMHO that's better than "atomic in most cases" because the caller can
assert that everything goes smooth.
These preconditions are asserted when the driver writer is careful
enough to stick to the API.
Either my idea is bad or I'm unable to sell it appropriately. Be it as
it is, I will stop to make a case for it.
Best regards and thanks for your try,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Uwe Kleine-König @ 2011-02-01 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D486B59.6010106@codeaurora.org>
Hello,
On Tue, Feb 01, 2011 at 12:21:45PM -0800, Saravana Kannan wrote:
> If the driver is calling clk_prepare() right next to clk_enable()
> knowing it's been already prepared and will hence be "atomic" (this
> is actually not true), then by your description, it's pointless to
> call clk_prepare().
Well not completely, as it increases the reference count. The advantage
would be that clk_enable counts addionally as prepare, so it would be
impossible to unprepare an enabled clock. And the other way round an
unprepared clock would never be enabled.
> If you want the driver to call clk_prepare() in atomic context
> because it will be atomic in most cases -- well, that's wrong. It's
> either atomic or is NOT atomic. There is no in between. If a call is
> NOT atomic, it can't be called in atomic context. Long story short,
> if you expect clk_prepare() to be atomic under any circumstance, it
> beats the point of introducing clk_prepare().
Well, with my suggestion it's atomic when certain precondions are given.
IMHO that's better than "atomic in most cases" because the caller can
assert that everything goes smooth.
These preconditions are asserted when the driver writer is careful
enough to stick to the API.
Either my idea is bad or I'm unable to sell it appropriately. Be it as
it is, I will stop to make a case for it.
Best regards and thanks for your try,
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: @ 2011-02-01 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D486B59.6010106@codeaurora.org>
Hello,
On Tue, Feb 01, 2011 at 12:21:45PM -0800, Saravana Kannan wrote:
> If the driver is calling clk_prepare() right next to clk_enable()
> knowing it's been already prepared and will hence be "atomic" (this
> is actually not true), then by your description, it's pointless to
> call clk_prepare().
Well not completely, as it increases the reference count. The advantage
would be that clk_enable counts addionally as prepare, so it would be
impossible to unprepare an enabled clock. And the other way round an
unprepared clock would never be enabled.
> If you want the driver to call clk_prepare() in atomic context
> because it will be atomic in most cases -- well, that's wrong. It's
> either atomic or is NOT atomic. There is no in between. If a call is
> NOT atomic, it can't be called in atomic context. Long story short,
> if you expect clk_prepare() to be atomic under any circumstance, it
> beats the point of introducing clk_prepare().
Well, with my suggestion it's atomic when certain precondions are given.
IMHO that's better than "atomic in most cases" because the caller can
assert that everything goes smooth.
These preconditions are asserted when the driver writer is careful
enough to stick to the API.
Either my idea is bad or I'm unable to sell it appropriately. Be it as
it is, I will stop to make a case for it.
Best regards and thanks for your try,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Kernel 2.6.32-5-amd64 fails to boot.
From: Rudy Zijlstra @ 2011-02-01 20:43 UTC (permalink / raw)
To: lrhorer; +Cc: 'Linux RAID'
In-Reply-To: <9A.25.13137.3DB684D4@cdptpa-omtalb.mail.rr.com>
Hi Leslie,
On 02/01/2011 09:23 PM, Leslie Rhorer wrote:
> I have been attempting to upgrade a Debian "Squeeze" Linux box from
> 2.6.32-3-amd64 to 2.6.32-5-amd64, but the upgrade is a non-starter. GRUB2
> comes up just fine, but when I select the new kernel version, a number of
> announcements flash by too fast to seen. I am not 100% certain, but I
> believe the initrd starts to load OK. Some text flies by far too quickly to
> be seen, but then an error pops up concerning an address space collision of
> some PCI device. Then it shows three errors for RAID devices md1. md2, and
> md3, saying they are already in use. Immediately thereafter the system shows
> errors concerning the RAID targets being already in use, after which point
> the system complains it can't mount / (md2), /dev, /sys, or /proc (in that
> order) because the sources do not exist (if /dev/md2 does not exist, how can
> it be busy?). Thereafter, of course, it fails to find init, since / is not
> mounted. It then tries to run BusyBox, but Busybox complains:
>
> /bin/sh: can't access tty; job control turned off
>
> After that, it attempts to put up an initramfs prompt, but of course with no
> tty access, it just hangs completely. Not surprisingly, recovery mode
> doesn't boot, either. It gives a bit more detail in the output, but nothing
> illuminating. The old kernel (2.6.32-3-amd64) boots just fine.
>
Can you enable serial console and catch the console output that way?
Cheers
Rudy
> Obviously there is a problem in the initramfs, probably with mdadm, but
> what? What should I try to manipulate in the initrd so I can find out what
> is failing?
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" 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
* RE: Bootable Raid-1
From: Leslie Rhorer @ 2011-02-01 20:43 UTC (permalink / raw)
To: naira, linux-raid
In-Reply-To: <4D486B2B.6030609@faccat.br>
> I have read several articles on the internet and researched in the
> messages list, but I'm still having trouble configuring a raid level 1
> array that is bootable.
>
> I configured a server some time agowith Gentoo Linux, Kernel
> 2.6.28-hardened-r9, mdadm - v3.0 and 2 IDE hard drives, this is working
> correctly. For this installation iused as a basis for consultation
> Article http://en.gentoo-wiki.com/wiki/Migrate_to_RAID
>
> Now, I want to use two SATA drives in raid level 1,
>
> Now i have Gentoo Linux with kernel 2.6.36-hardened-r6 and mdadm -
> v3.1.4 and the instructions of Article dont work. The kernel was
> configured with support for disks raid autodetect and supported the raid
> level 1. But in the logs of dmesg does not run the auto-detection of the
> disks to the array, so in the boot when mounting the root device /
> dev/md2 the system can not find the device.
>
> When I run mdadm - auto-detect the array are found somewhere but still
> displays message indicating that the raid device is not a valid
> partition table.
>
> How can you configure a raid level 1 with bootable disks / dev / sda and
> / dev / sdb?
> I want three partitions:
> /dev/md1 - swap - /dev/sda1, /dev/sdb1
> /dev/md2 - boot - /dev/sda2, /dev/sdb2
> /dev/md3 - / - /dev/sda3, /dev/sdb3
>
> I am using grub as bootloader.
This is very similar to my boot configuration on my two servers. I
suspect your problem is the metadata. What version of superblock are you
using for /dev/md2? GRUB2 does not recognize a version 1.x superblock.
Since the boot images are quite small, and don't require an array of many
disks, there is nothing wrong with the 0.90 superblock, however. If your
/dev/md2 array is not a 0.9 version superblock, try converting it. Here is
my configuration from one of the servers:
ARRAY /dev/md0 level=raid6 num-devices=10 metadata=01.2 name=Backup:0
UUID=431244d6:45d9635a:e88b3de5:92f30255
ARRAY /dev/md1 level=raid1 num-devices=2 metadata=0.90
UUID=4cde286c:0687556a:4d9996dd:dd23e701
ARRAY /dev/md2 level=raid1 num-devices=2 metadata=01.2 name=Backup:2
UUID=d45ff663:9e53774c:6fcf9968:21692025
ARRAY /dev/md3 level=raid1 num-devices=2 metadata=01.2 name=Backup:3
UUID=51d22c47:10f58974:0b27ef04:5609d357
Where md0 is a large (11T) data array, md1 is boot, md2 is root, and
md3 is swap. The partitioning layout of the boot drives is the same as
yours.
^ permalink raw reply
* Re: [patch 07/28] posix-timers: Convert clock_nanosleep_restart to clockid_to_kclock()
From: John Stultz @ 2011-02-01 20:42 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110201134418.131263211@linutronix.de>
On Tue, 2011-02-01 at 13:51 +0000, Thomas Gleixner wrote:
> plain text document attachment
> (posix-timers-convert-nanosleep-restart.patch)
> Use the new kclock decoding function in clock_nanosleep_restart. No
> need to check kclock here as the restart block always contains a valid
> clockid. If not, we are in serious trouble anyway.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: John Stultz <john.stultz@linaro.org>
> Cc: Richard Cochran <richard.cochran@omicron.at>
One nit.
> -long
> -clock_nanosleep_restart(struct restart_block *restart_block)
> +long clock_nanosleep_restart(struct restart_block *restart_block)
> {
> clockid_t which_clock = restart_block->arg0;
> + struct k_clock *kc = clockid_to_kclock(which_clock);
>
> - return CLOCK_DISPATCH(which_clock, nsleep_restart,
> - (restart_block));
> + return kc->nsleep_restart(restart_block);
> }
Should you be checking if kc is null before dereferencing? Or am I being
overly paranoid?
thanks
-john
^ permalink raw reply
* [Buildroot] [PATCH] Enable ccache for u-boot compile
From: Peter Korsgaard @ 2011-02-01 20:43 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1296580381-4658-2-git-send-email-mort@bork.org>
>>>>> "Martin" == Martin Hicks <mort@bork.org> writes:
Martin> Just needed to pass in ccache as a prefix to the CROSS_TARGET variable.
Martin> Signed-off-by: Martin Hicks <mort@bork.org>
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* RE: [PATCH] dcdbas: force SMI to happen when expected
From: Douglas_Warzecha @ 2011-02-01 20:42 UTC (permalink / raw)
To: linux-kernel, Stuart_Hayes
In-Reply-To: <07E32F241046DA418A0381C1225BFC011A453F262B@AUSX7MCPS301.AMER.DELL.COM>
On 01/18/2011 12:21 PM, Stuart Hayes wrote:
> The dcdbas driver can do an I/O write to cause a SMI to occur. On some
> systems I/O writes are posted in the chipset and don't complete
> immediately. This can result in the SMI happening at a later time.
> This can result in random failures since the SMI handler expects the
> EBX register to contain a pointer, and the handler can write to memory.
>
> Performing an I/O read to the same address as the I/O write will force
> the I/O write to complete. The patch is against the 2.6.37 kernel and
> has been tested.
>
> Signed-off-by: Stuart Hayes <stuart_hayes@dell.com>
Acked-by: Doug Warzecha <douglas_warzecha@dell.com>
^ permalink raw reply
* [Buildroot] [PATCH] Enable ccache for kernel compile
From: Peter Korsgaard @ 2011-02-01 20:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1296580381-4658-1-git-send-email-mort@bork.org>
>>>>> "Martin" == Martin Hicks <mort@bork.org> writes:
Martin> Just needed to pass in ccache as a prefix to the CROSS_TARGET variable.
Martin> Signed-off-by: Martin Hicks <mort@bork.org>
Committed, thanks.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: Re: Nvidia 9500GT Xen VGA passthru
From: Sander Eikelenboom @ 2011-02-01 20:41 UTC (permalink / raw)
To: Anish Patel; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <4D485E69.3040707@gmail.com>
Hello Anish,
Could you post some information about your setup, so others can benefit from it ?
- dom0 kernel version / config ?
- Xen hypervisor version ?
- domU OS and graphics driver version ?
- domU config file ?
- Additional patches applied to xen ?
- Brand/model primary graphics card ?
- Brand/model secondary graphics card ?
- Intel (vt-d) or AMD (iommu) platform ?
I have done some attempts my self, but only succeeded to get vga safe mode in windows XP so far.
--
Sander
Tuesday, February 1, 2011, 8:26:33 PM, you wrote:
> Hi All,
> I have managed to get the 2nd vga passed though. I had to use
> AMD/ATI card to get this done.
> Thanks
> Anish
> On 01/31/11 14:26, Pasi Kärkkäinen wrote:
>> On Mon, Jan 31, 2011 at 11:39:51AM -0500, Anish Patel wrote:
>>> I have this almost working now, I think the only thing that i need to
>>> change is to add a gfx_passthru=2 option to let xen know not to read
>>> from /dev/mem then an option to tell it what VGA rom to use. Are there
>>> any patches for 4.01 for this?
>>>
>> I think gfx_passthru can only use 0 or 1 nowadays.
>>
>> Patches probably need to be forward-ported to current Xen..
>> most of them are for xen-unstable from the Xen 3.5 days..
>>
>> -- Pasi
>>
>>> Thanks
>>> Anish
>>> On 01/31/11 06:50, Pasi Kärkkäinen wrote:
>>>> On Sun, Jan 30, 2011 at 12:42:56AM -0500, Peter van der Maas wrote:
>>>>> I really have not played with too much after the proof of concept. I do recall something eventually breaking the config, perhaps a Xen update. I've since put the hardware to better use, although I am still intrigued by Xen. At the time, I was working with a team that was giving serious consideration to virtualizing their platform, and what better way to learn than dig in and get my hands dirty.
>>>>>
>>>>> I tried to include as much detail at the time, with the plethora of different Xen builds, BIOS's updates, etc.
>>>>>
>>>>> If someone has something specific I can try to help, but doubtful I will be of any use. For example, I did not realize Xen 4.x was even released. Recent projects I've been working on do not lend themselves well to virtualization; however, I might have to give Xen 4.0 shot - just to play, of course. There were some serious changes happening with Xen, the Linux kernel, and KVM when I stopped playing.
>>>>>
>>>> Ok.
>>>>
>>>> I mainly meant if you remember what custom patches did you have to use/create?
>>>> Most probably you had to do some vBar=pBar hacking, right?
>>>>
>>>> I guess I'll have to try this myself one day and document the process
>>>> with current Xen versions..
>>>>
>>>> -- Pasi
>>>>
>>>>
>>>>> Sorry I could not be of more help.
>>>>>
>>>>> Peter van der Maas
>>>>> peter&pjv-c.com
>>>>>
>>>>> -----Original Message-----
>>>>> From: Pasi Kärkkäinen [mailto:pasik@iki.fi]
>>>>> Sent: Saturday, January 29, 2011 2:04 PM
>>>>> To: Peter van der Maas
>>>>> Cc: xen-users@lists.xensource.com; anish.mailing.list@gmail.com; xen-devel@lists.xensource.com
>>>>> Subject: Nvidia 9500GT Xen VGA passthru
>>>>>
>>>>>
>>>>> Hello Peter,
>>>>>
>>>>> Some people have been asking for tips about Nvidia Xen VGA passthru,
>>>>> so maybe you could help?
>>>>>
>>>>> Could you post the exact steps you did?
>>>>>
>>>>> Have you tried with Xen 4.0.x after your initial experiments in 2009?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> -- Pasi
>>>>>
>>>>> On Mon, Jan 26, 2009 at 02:16:32PM -0500, Peter J. van der Maas wrote:
>>>>>> I am happy to announce that I have successfully (and finally!) been able
>>>>>> to pass a PCIe graphics card via VT-d to a Windows XP HVM DomU.
>>>>>>
>>>>>>
>>>>>>
>>>>>> About time!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Config:
>>>>>>
>>>>>> -Intel Q6600 Core 2 Quad-Core, G0 stepping (I think)
>>>>>>
>>>>>> -Intel DQ35JO Motherboard, Q35 Chipset, BIOS v.991 (1/9/09), VT and VT-d
>>>>>> enabled
>>>>>>
>>>>>> -nVidia 9500GT (for VT-d passthrough - DomU)
>>>>>>
>>>>>> -nVidia GeForce2 MX200 (Dom0 console)
>>>>>>
>>>>>> -Xen (build: xen-unstable, recent as of ~ 1/25/09 1:00AM-EST)
>>>>>>
>>>>>> -Dom0: Linux-2.6.18.8-xen (via xen-unstable.hg)
>>>>>>
>>>>>> -DomU: Windows XP (pro, sp3, 32-bit)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Once the VT-d bugs were recently corrected (thank you, xen-devel!),
>>>>>> everything went fairly smoothly. Still very buggy yet (its
>>>>>> xen-unstable!), but overall it works.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Make sure support for the PCI-backend is compiled into the kernel (not
>>>>>> just a module) and that you have your pciback.hide options in grub
>>>>>> (late-binding may work, but I haven't tried).
>>>>>>
>>>>>>
>>>>>>
>>>>>> Good luck!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Peter van der Maas
>>>>>> _______________________________________________
>>>>>> Xen-users mailing list
>>>>>> Xen-users@lists.xensource.com
>>>>>> http://lists.xensource.com/xen-users
--
Best regards,
Sander mailto:linux@eikelenboom.it
^ permalink raw reply
* Re: [patch 06/28] posix-timers: Convert clock_nanosleep to clockid_to_kclock()
From: john stultz @ 2011-02-01 20:41 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <20110201134418.034175556@linutronix.de>
On Tue, 2011-02-01 at 13:51 +0000, Thomas Gleixner wrote:
> plain text document attachment (posix-timers-convert-nanosleep.patch)
> Use the new kclock decoding function in clock_nanosleep and cleanup all
> kclocks which use the default functions.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: John Stultz <john.stultz@linaro.org>
> Cc: Richard Cochran <richard.cochran@omicron.at>
Acked-by: John Stultz <johnstul@us.ibm.com>
^ permalink raw reply
* Trouble using bcm4318 compact flash with b43 driver
From: Larry Finger @ 2011-02-01 20:40 UTC (permalink / raw)
To: b43-dev
In-Reply-To: <20110201154135.00006f0b@unknown>
On 02/01/2011 08:41 AM, dylan cristiani wrote:
> i have some news: i went back to kernel version 2.6.26 and it worked
> so i moved forward kernel by kernel and it works till kernel 2.6.32;
> first kernel that shows up the problem is 2.6.33 and, at module loading
> time i can see for the first time, after loading firmware, the following
> debug info (don't know if it's helpful but same message happears in
> every non-working kernel from 2.6.33 to 2.6.37):
>
> "b43-phy0 warning: Invalid max-TX-power value in SPROM"
Between 2.6.32 and 2.6.33, there were only 6 patches that touched SSB. Two of
them (e33761e and 3ba6018) affected SPROM writing, one (37ace3d) was only for
PCMCIA, and one (ac2752c) only affected logging of a core scan. The two
remaining are 391ae22 that fixed an SDIO typo and 8b45499 that put host pointers
in a union should be the only ones that needed testing.
Those patches are attached. Try each of them in turn to 2.6.33 with a
'patch -p1 -R < patch_name' If it doesn't help, use the same command without the
"-R" to reapply. I'm guessing that 8b45499 is more likely to be the problem, and
I would try it first.
Larry
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_391ae22
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110201/340c8ec1/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_8b45499
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110201/340c8ec1/attachment-0001.ksh>
^ permalink raw reply
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
From: Scott Wood @ 2011-02-01 20:40 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20110201202050.CA1CFB187@gemini.denx.de>
On Tue, 1 Feb 2011 21:20:50 +0100
Wolfgang Denk <wd@denx.de> wrote:
> Dear Scott Wood,
>
> In message <20110201135136.0817fe5a@udp111988uds.am.freescale.net> you wrote:
> >
> > > > Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
> > > > used? So before, anything that board/cpu code adds directly to LDFLAGS
> > > > (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
> > > > used in the final link. After 8aba9dc, only things in
> > > > PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.
> > >
> > > And this is correct for all boards?
> >
> > By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the
> > switch back to LDFLAGS? It's not obvious to me that the dropping of
>
> I don;t understand why you contine to talk about "switch to
> PLATFORM_LDFLAGS in 8aba9dc". There was no such switch - at least I
> cannot see it.
>
> I see only a switch in your patch. This is why I'm asking.
Before 8aba9dc, the flags for the final link were produced by taking
the existing LDFLAGS, and adding:
-Bstatic -T <linkerscript> $(PLATFORM_LDFLAGS) -Ttext <addr>.
This included anything that cpu/board code added to LDFLAGS -- some
architectures added --gc-sections, x86 added --cref, etc. Since the above
flags are added to LDFLAGS, rather than replacing them, these flags got used
in the final link.
Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the
source for the flags for the final link. It generates LDFLAGS_u-boot using
PLATFORM_LDFLAGS, not LDFLAGS. It converts most of the board/cpu updates to
LDFLAGS into LDFLAGS_u-boot, but it missed --cref.
I don't see any other LDFLAGS changes in board/cpu code, so the distinction
between using LDFLAGS and PLATFORM_LDFLAGS should have no other impact on
current boards. However, the patch appears to be intended to support
platform linker flags that need to be used during partial link, which
would involve board/cpu additions to LDFLAGS. This change would break that
only if those options need to be used for partial link *only*, and cannot be
used in the final link. In such a case I'd suggest using something like
LDFLAGS_PARTIAL to make this explicit. But I'd be surprised if that
were actually the case.
If you're looking to cut down on the number of variables, it's not clear to
me what PLATFORM_LDFLAGS is supposed to mean distinct from adding to
LDFLAGS.
-Scott
^ permalink raw reply
* Re: [RFC][PATCH 0/6] more detailed per-process transparent hugepage statistics
From: Andrea Arcangeli @ 2011-02-01 20:39 UTC (permalink / raw)
To: Dave Hansen; +Cc: linux-kernel, linux-mm, Michael J Wolf, Andrew Morton
In-Reply-To: <1296580547.27022.3370.camel@nimitz>
On Tue, Feb 01, 2011 at 09:15:47AM -0800, Dave Hansen wrote:
> On Tue, 2011-02-01 at 16:38 +0100, Andrea Arcangeli wrote:
> > On Mon, Jan 31, 2011 at 04:33:57PM -0800, Dave Hansen wrote:
> > > I'm working on some more reports that transparent huge pages and
> > > KSM do not play nicely together. Basically, whenever THP's are
> > > present along with KSM, there is a lot of attrition over time,
> > > and we do not see much overall progress keeping THP's around:
> > >
> > > http://sr71.net/~dave/ibm/038_System_Anonymous_Pages.png
> > >
> > > (That's Karl Rister's graph, thanks Karl!)
> >
> > Well if the pages_sharing/pages_shared count goes up, this is a
> > feature not a bug.... You need to print that too in the chart to show
> > this is not ok
>
> Here are the KSM sharing bits for the same run:
>
> http://sr71.net/~dave/ibm/009_KSM_Pages.png
>
> It bounces around a little bit on the ends, but it's fairly static
> during the test, even when there's a good downward slope on the THP's.
>
> Hot of the presses, Karl also managed to do a run last night with the
> khugepaged scanning rates turned all the way up:
>
> http://sr71.net/~dave/ibm/038_System_Anonymous_Pages-scan-always.png
>
> The THP's there are a lot more stable. I'd read that as saying that the
> scanning probably just isn't keeping up with whatever is breaking the
> pages up.
This is exactly the case. But note that it's not obvious that keeping
the hugepage number up steady is beneficial in terms of final
performance: what happens now is you split and collapse (collapse
requires copy so it's more costly than split) hugepages at higher
frequency than before (the hugepages are still split but now they're
collapsed faster and ksm has to split them again). So now the speedup
from hugepages needs to also offset the cost of the more frequent
split/collapse events that didn't happen before.
So I guess considering the time is of the order of 2/3 hours and there
are "only" 88G of memory, speeding up khugepaged is going to be
beneficial considering how big boost hugepages gives to the guest with
NPT/EPT and even bigger boost for regular shadow paging, but it also
depends on guest. In short khugepaged by default is tuned in a way
that can't run in the way of the CPU.
I recall Avi once suggested someday we'd need khugepaged running at
100% load cpu like it may happen for ksmd. It's not needed yet though
but this is just to say you're perfectly right assuming the default
scanning rate may be too slow. But it's really meant to be tuned
depending on the size of the system, how many cores, how many gb of
ram to scan etc, if KSM is on, etc...
KSM internal checksum check before adding rmap_items to the unstable
tree already should prevent false sharing between ksm and
khugepaged. Plus khugepaged will stay away if the page is shared by
KSM. So because of this the risk of false sharing is low even running
both at 100% load on the same VM.
khugepaged default scan rate may be good idea to increase too for
large systems with lots of cpus and lots of memory, the default is
super paranoid and to be optimistic to still get a net gain for the
netbooks and cellphones if any collapse happens ;).
I'm generally very pleased to see these charts.
It reminds me that Microsoft and Oracle can't support hugepages and
KSM simultaneously, and at least Oracle Xen doesn't even have KSM at
all (there's some attempt to share guest cache or find equal I/O or
stuff like that but it won't help for guest anonymous memory which
incidentally is where HPC at places like LHC needs KSM running). Xen
doesn't even support swapping (easy to use THP in hypervisor if you
don't support swapping, of course Oracle Xen wouldn't support swapping
even if it would use 4k pages.. ;).
So current status of KSM over THP, where KSM scans inside THP pages,
and where 2m pages, 4k regular pages, and 4k KSM nonlinar pages with
special rmap_item are mixed in the same VMA, and where both regular 4k
pages, 2m pages and even the ksm pages are all swappable, and with mmu
notifier keeping shadow MMU or NPT/EPT in full synchrony with the
Linux VM so that both the KSM and THP algorithms are 100%
secondary-mmu agnostic, is quite a milestone for 2.6.38 and I hope
this will be a good proof of how the KVM design is superior and with
less effort we can achieve things that they may never support with
equal or better performance (in the KSM case our shared guest
filesystem cache remains readonly mapped and natively handled by guest
without any paravirt, like if KSM didn't merge anything).
> I'm happy to hold on to them for another release. I'm actually going to
> go look at the freezes I saw now that I have these out in the wild.
I'm also going to have a closer look. The other report you can see
search for subject "khugepaged" in lkml from Jindřich (I think
compaction is too heavy, a walk in the park compared to lumpy reclaim
but we need to make it more latency friendly, I also got a report that
latency increases with heavy I/O that I think is the same thing that
Jindřich sees).
Yet another report shows a full hang with khugepaged waiting on
mmap_sem but I think that is not related to THP, maybe something hung
on the mmap_sem, khugepaged doesn't seem the holder of it.
I myself had an issue with PROVE_LOCKING and I deadlocked inside
_raw_spin_unlock_irq (how can I possibly deadlock inside unlock? must
be prove locking bug? I didn't yet check if there have been updates in
that area).
There is also a known bug that I didn't fix yet and it's the next
thing I need to address and it's the pgd_lock hold with irq disabled
taking the page_table_lock. That is buggy with THP=off too, but it
only triggers with NR_CPUS small enough so to disable PT locks (for
small smp builds PT lock becomes the page_table_lock and then it'll
deadlock when sending IPI with page_table_lock hold because the
vmalloc fault will take pgd_lock with irqs disabled). I've no idea why
pgd_lock is taken with irq disabled.
No other issue. It's not as bad as it seems, likely turning
congestion_wait in compaction and breaking the compaction look and a
few other tweaks to compaction will solve the latency issue with lots
of dirty cache. the pgd_lock is likely easily fixable too. Your issue
and the mmap_sem read mode hang I didn't look into yet but they may
not be related to this. Also your issue looked like the pgd_lock bug
that I already know about, so maybe it's nothing new (maybe the
mmap_sem too, I've no idea at the moment). I never reproduced this
myself yet. Anyway there's nothing really concerning, no mm corruption
or weird oops whatsoever ever reported, a spinlock or mmap_sem
deadlock not enough to worry me ;).
> I'll probably stick them in a git tree and keep them up to date.
>
> Are there any other THP issues you're chasing at the moment?
I reviewed it too, and I see no problems. So if you fix those two bits
that Johannes pointed out (remove the split that is superfluous after
wait_ if you hold mmap_sem or rmap lock and add the split to the other
walkers not yet covered) I think they can go in now without waiting.
^ permalink raw reply
* Re: [RFC][PATCH 0/6] more detailed per-process transparent hugepage statistics
From: Andrea Arcangeli @ 2011-02-01 20:39 UTC (permalink / raw)
To: Dave Hansen; +Cc: linux-kernel, linux-mm, Michael J Wolf, Andrew Morton
In-Reply-To: <1296580547.27022.3370.camel@nimitz>
On Tue, Feb 01, 2011 at 09:15:47AM -0800, Dave Hansen wrote:
> On Tue, 2011-02-01 at 16:38 +0100, Andrea Arcangeli wrote:
> > On Mon, Jan 31, 2011 at 04:33:57PM -0800, Dave Hansen wrote:
> > > I'm working on some more reports that transparent huge pages and
> > > KSM do not play nicely together. Basically, whenever THP's are
> > > present along with KSM, there is a lot of attrition over time,
> > > and we do not see much overall progress keeping THP's around:
> > >
> > > http://sr71.net/~dave/ibm/038_System_Anonymous_Pages.png
> > >
> > > (That's Karl Rister's graph, thanks Karl!)
> >
> > Well if the pages_sharing/pages_shared count goes up, this is a
> > feature not a bug.... You need to print that too in the chart to show
> > this is not ok
>
> Here are the KSM sharing bits for the same run:
>
> http://sr71.net/~dave/ibm/009_KSM_Pages.png
>
> It bounces around a little bit on the ends, but it's fairly static
> during the test, even when there's a good downward slope on the THP's.
>
> Hot of the presses, Karl also managed to do a run last night with the
> khugepaged scanning rates turned all the way up:
>
> http://sr71.net/~dave/ibm/038_System_Anonymous_Pages-scan-always.png
>
> The THP's there are a lot more stable. I'd read that as saying that the
> scanning probably just isn't keeping up with whatever is breaking the
> pages up.
This is exactly the case. But note that it's not obvious that keeping
the hugepage number up steady is beneficial in terms of final
performance: what happens now is you split and collapse (collapse
requires copy so it's more costly than split) hugepages at higher
frequency than before (the hugepages are still split but now they're
collapsed faster and ksm has to split them again). So now the speedup
from hugepages needs to also offset the cost of the more frequent
split/collapse events that didn't happen before.
So I guess considering the time is of the order of 2/3 hours and there
are "only" 88G of memory, speeding up khugepaged is going to be
beneficial considering how big boost hugepages gives to the guest with
NPT/EPT and even bigger boost for regular shadow paging, but it also
depends on guest. In short khugepaged by default is tuned in a way
that can't run in the way of the CPU.
I recall Avi once suggested someday we'd need khugepaged running at
100% load cpu like it may happen for ksmd. It's not needed yet though
but this is just to say you're perfectly right assuming the default
scanning rate may be too slow. But it's really meant to be tuned
depending on the size of the system, how many cores, how many gb of
ram to scan etc, if KSM is on, etc...
KSM internal checksum check before adding rmap_items to the unstable
tree already should prevent false sharing between ksm and
khugepaged. Plus khugepaged will stay away if the page is shared by
KSM. So because of this the risk of false sharing is low even running
both at 100% load on the same VM.
khugepaged default scan rate may be good idea to increase too for
large systems with lots of cpus and lots of memory, the default is
super paranoid and to be optimistic to still get a net gain for the
netbooks and cellphones if any collapse happens ;).
I'm generally very pleased to see these charts.
It reminds me that Microsoft and Oracle can't support hugepages and
KSM simultaneously, and at least Oracle Xen doesn't even have KSM at
all (there's some attempt to share guest cache or find equal I/O or
stuff like that but it won't help for guest anonymous memory which
incidentally is where HPC at places like LHC needs KSM running). Xen
doesn't even support swapping (easy to use THP in hypervisor if you
don't support swapping, of course Oracle Xen wouldn't support swapping
even if it would use 4k pages.. ;).
So current status of KSM over THP, where KSM scans inside THP pages,
and where 2m pages, 4k regular pages, and 4k KSM nonlinar pages with
special rmap_item are mixed in the same VMA, and where both regular 4k
pages, 2m pages and even the ksm pages are all swappable, and with mmu
notifier keeping shadow MMU or NPT/EPT in full synchrony with the
Linux VM so that both the KSM and THP algorithms are 100%
secondary-mmu agnostic, is quite a milestone for 2.6.38 and I hope
this will be a good proof of how the KVM design is superior and with
less effort we can achieve things that they may never support with
equal or better performance (in the KSM case our shared guest
filesystem cache remains readonly mapped and natively handled by guest
without any paravirt, like if KSM didn't merge anything).
> I'm happy to hold on to them for another release. I'm actually going to
> go look at the freezes I saw now that I have these out in the wild.
I'm also going to have a closer look. The other report you can see
search for subject "khugepaged" in lkml from JindA?ich (I think
compaction is too heavy, a walk in the park compared to lumpy reclaim
but we need to make it more latency friendly, I also got a report that
latency increases with heavy I/O that I think is the same thing that
JindA?ich sees).
Yet another report shows a full hang with khugepaged waiting on
mmap_sem but I think that is not related to THP, maybe something hung
on the mmap_sem, khugepaged doesn't seem the holder of it.
I myself had an issue with PROVE_LOCKING and I deadlocked inside
_raw_spin_unlock_irq (how can I possibly deadlock inside unlock? must
be prove locking bug? I didn't yet check if there have been updates in
that area).
There is also a known bug that I didn't fix yet and it's the next
thing I need to address and it's the pgd_lock hold with irq disabled
taking the page_table_lock. That is buggy with THP=off too, but it
only triggers with NR_CPUS small enough so to disable PT locks (for
small smp builds PT lock becomes the page_table_lock and then it'll
deadlock when sending IPI with page_table_lock hold because the
vmalloc fault will take pgd_lock with irqs disabled). I've no idea why
pgd_lock is taken with irq disabled.
No other issue. It's not as bad as it seems, likely turning
congestion_wait in compaction and breaking the compaction look and a
few other tweaks to compaction will solve the latency issue with lots
of dirty cache. the pgd_lock is likely easily fixable too. Your issue
and the mmap_sem read mode hang I didn't look into yet but they may
not be related to this. Also your issue looked like the pgd_lock bug
that I already know about, so maybe it's nothing new (maybe the
mmap_sem too, I've no idea at the moment). I never reproduced this
myself yet. Anyway there's nothing really concerning, no mm corruption
or weird oops whatsoever ever reported, a spinlock or mmap_sem
deadlock not enough to worry me ;).
> I'll probably stick them in a git tree and keep them up to date.
>
> Are there any other THP issues you're chasing at the moment?
I reviewed it too, and I see no problems. So if you fix those two bits
that Johannes pointed out (remove the split that is superfluous after
wait_ if you hold mmap_sem or rmap lock and add the split to the other
walkers not yet covered) I think they can go in now without waiting.
--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ 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.