* Re: [Qemu-devel] [PATCH] pci_bridge: fix typo
From: Blue Swirl @ 2011-10-23 20:03 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel
In-Reply-To: <4E9AF419.9040405@redhat.com>
On Sun, Oct 16, 2011 at 15:11, Avi Kivity <avi@redhat.com> wrote:
> On 10/16/2011 04:44 PM, Blue Swirl wrote:
>> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
>> ---
>> hw/pci_bridge.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/hw/pci_bridge.c b/hw/pci_bridge.c
>> index b6287cd..650d165 100644
>> --- a/hw/pci_bridge.c
>> +++ b/hw/pci_bridge.c
>> @@ -319,7 +319,7 @@ int pci_bridge_initfn(PCIDevice *dev)
>> sec_bus->parent_dev = dev;
>> sec_bus->map_irq = br->map_irq;
>> sec_bus->address_space_mem = &br->address_space_mem;
>> - memory_region_init(&br->address_space_mem, "pci_pridge_pci", INT64_MAX);
>> + memory_region_init(&br->address_space_mem, "pci_bridge_pci", INT64_MAX);
>> sec_bus->address_space_io = &br->address_space_io;
>> memory_region_init(&br->address_space_io, "pci_bridge_io", 65536);
>> pci_bridge_region_init(br);
>
> Reviewed-by: Avi Kivity <avi@redhat.com>
Thanks for the review, applied.
^ permalink raw reply
* Re: lvs-users mailing list and archive dead?
From: Tomasz Chmielewski @ 2011-10-23 19:52 UTC (permalink / raw)
To: Graeme Fowler; +Cc: lvs-devel
In-Reply-To: <e6ed933e-c1dc-4931-b97e-89dec46d8617@email.android.com>
On 23.10.2011 20:13, Graeme Fowler wrote:
> It still is, it's still live and is active.
>
> Can you not access it? Does the name resolve?
Ah, indeed it's alive.
I'm not able to resolve names from it from a largish German hosting
provider, Hetzner.
The (IPv4) nameservers for graemef.net are:
ex.graemef.net has address 89.238.178.25
boom.graemef.net has address 82.113.154.29
# dig graemef.net @89.238.178.25
; <<>> DiG 9.7.3 <<>> graemef.net @89.238.178.25
;; global options: +cmd
;; connection timed out; no servers could be reached
# dig graemef.net @82.113.154.29
; <<>> DiG 9.7.3 <<>> graemef.net @82.113.154.29
;; global options: +cmd
;; connection timed out; no servers could be reached
On the other hand, ping works fine, so (some) connectivity works...
--
Tomasz Chmielewski
^ permalink raw reply
* Re: BUG: All network processes hang (brcmsmac/wpa_supplicant)
From: Nico Schottelius @ 2011-10-23 19:48 UTC (permalink / raw)
To: Nico Schottelius
Cc: Arend van Spriel, Eric Dumazet, linux-wireless@vger.kernel.org
In-Reply-To: <20111023105305.GA2489@schottelius.org>
[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]
Update, just triggered it after a suspend/resume cycle:
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
64 bytes from 192.168.42.1: icmp_req=23 ttl=64 time=32.4 ms
64 bytes from 192.168.42.1: icmp_req=24 ttl=64 time=10.7 ms
64 bytes from 192.168.42.1: icmp_req=25 ttl=64 time=9.36 ms
64 bytes from 192.168.42.1: icmp_req=26 ttl=64 time=7.13 ms
64 bytes from 192.168.42.1: icmp_req=27 ttl=64 time=6.92 ms
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
This changes every some seconds right now, because the connection
is established/shutdown and thus dhcpcd retries to get the ip address
every few seconds.
I've restarted the AP, but the situation stays the same.
The other devices in the network work fine, so it's really my system
that behaves "funny".
After that I've reloaded brcmsmac at 84262.797365, after which
the connection time lasted longer, but was also interrupted some
time later.
dmesg attached again.
Cheers,
Nico
--
PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0
[-- Attachment #2: dmesg.gz --]
[-- Type: application/octet-stream, Size: 60890 bytes --]
^ permalink raw reply
* [PATCH] mac80211_hwsim: Claim support for TDLS
From: Jouni Malinen @ 2011-10-23 19:45 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
Signed-off-by: Jouni Malinen <j@w1.fi>
---
drivers/net/wireless/mac80211_hwsim.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Note: Before even thinking of testing this, please take a look at the
RFC patch for handling supported rates configuration unless you want to
crash and burn your kernel.. Anyway, it is useful to get hwsim ready for
TDLS testing and the mac80211 issue is not specific to hwsim and people
who use hwsim are normally capable of patching kernel and familiar with
this mailing list in the first place.. ;-)
With the RFC "mac80211: Fix STA supported rate configuration with dummy
entry" patch in place, I was able to get the TDLS link running in
mac80211_hwsim environment between two WPA2 stations.
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 68455a2..477100d 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -1747,6 +1747,8 @@ static int __init init_mac80211_hwsim(void)
IEEE80211_HW_SUPPORTS_DYNAMIC_SMPS |
IEEE80211_HW_AMPDU_AGGREGATION;
+ hw->wiphy->flags |= WIPHY_FLAG_SUPPORTS_TDLS;
+
/* ask mac80211 to reserve space for magic */
hw->vif_data_size = sizeof(struct hwsim_vif_priv);
hw->sta_data_size = sizeof(struct hwsim_sta_priv);
--
1.7.4.1
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply related
* [ath9k-devel] Can't associate with a particular AP
From: Adrian Chadd @ 2011-10-23 19:45 UTC (permalink / raw)
To: ath9k-devel
In-Reply-To: <20111023181655.30770.qmail@stuge.se>
Just try a PCBSD USB image, which should fire up X as part of the installer.
I think the pcbsd usb images (full and bootonly) are "live", as in
give you a basic desktop environment.
You _should_ be able to configure the wireless through the installer
environment.
That should be enough to verify whether the wifi is working or not.
Adrian
^ permalink raw reply
* Sie haben gewonne
From: Sie haben gewonne @ 2011-10-23 19:14 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 134 bytes --]
Wir empfehlen Ihnen, pdf Attached Datei цffnen,und wenden Sie sich fьr Ihr Agent Lotteriegewinn.
Mit freundlichen GrьЯen,
Management
[-- Attachment #2: NOTARISCHE GEWINNBENACHRICHTIGUNG.pdf --]
[-- Type: application/octet-stream, Size: 52858 bytes --]
^ permalink raw reply
* Snapshot rollback
From: Phillip Susi @ 2011-10-23 19:42 UTC (permalink / raw)
To: linux-btrfs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I created a snapshot of my root subvol, then used btrfs-subvolume
set-default to make the snapshot the default subvol and rebooted. This
seems to have correctly gotten the system to boot from the snapshot
instead of the original subvol, but now /home ( @home subvol ) refuses
to mount claiming that /dev/sda1 is not a valid block device. What gives?
Also, is there no way to move or hard link subvolumes to somewhere other
than their original location?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6kbjoACgkQJ4UciIs+XuJ9cgCgplNTWEmJjW+9fC87y9nO9yao
xcQAoLzsOCVgxsm4a28wKudvyX+7OCpB
=rL1g
-----END PGP SIGNATURE-----
^ permalink raw reply
* [U-Boot] [PATCH] phy/marvell: Rewrite the MV88E1111 phy config function based on kernel code
From: Wolfgang Denk @ 2011-10-23 19:41 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319178713-12472-2-git-send-email-tie-fei.zang@freescale.com>
Dear Roy Zang,
In message <1319178713-12472-2-git-send-email-tie-fei.zang@freescale.com> you wrote:
> The original m88e1111s_config() does not do the SGMII mode
> initialization and is buggy. Rewrite the function according to
> 3.0.6 kernel function m88e1111_config_init() in drivers/net/phy/marvell.c
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> Acked-by: Andy Fleming <afleming@freescale.com>
> Cc: Kumar Gala <galak@kernel.crashing.org>
...
> + /* soft reset */
> + phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, BMCR_RESET);
> + do
> + reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMCR);
> + while (reg & BMCR_RESET);
...
> + /* soft reset */
> + phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, BMCR_RESET);
> + do
> + reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMCR);
> + while (reg & BMCR_RESET);
Do we really need this double reset?
Also, I dislike the potentially infinite loop here - please add a
timeout and an error exit.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A supercomputer is a machine that runs an endless loop in 2 seconds.
^ permalink raw reply
* [RFC] mac80211: Fix STA supported rate configuration with dummy entry
From: Jouni Malinen @ 2011-10-23 19:40 UTC (permalink / raw)
To: Johannes Berg, Arik Nemtsov, Felix Fietkau; +Cc: linux-wireless
TDLS adds a STA entry before full information about the STA is
available. This leaves rate control algorithms in pretty odd state.
Avoid this by claiming the lowest rate to be supported if no supported
rates are indicated and then update the rate control again when the rate
set changes.
Signed-off-by: Jouni Malinen <j@w1.fi>
---
net/mac80211/cfg.c | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
Note: Without this, some rate control algorithms can get quite unhappy
with the TDLS entries and maybe other use cases that could result in no
supported rates. For example, minstral has a pretty horrible loop in
init_sample_table() going to n_srates = n_rates(0) - 1...
Are all rate control algorithms fine with the second
rate_control_rate_init() call? That is needed in the TDLS use case where
the supported rate set is known only after the STA entry has been
added. I guess it would be possible to delay addition of the STA entry
for TDLS until the supported rates are known, but I did not look at the
details on what exactly that would require.
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index a9ded52..b9dae9d 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -682,7 +682,7 @@ static void ieee80211_send_layer2_update(struct sta_info *sta)
netif_rx_ni(skb);
}
-static void sta_apply_parameters(struct ieee80211_local *local,
+static bool sta_apply_parameters(struct ieee80211_local *local,
struct sta_info *sta,
struct station_parameters *params)
{
@@ -691,6 +691,7 @@ static void sta_apply_parameters(struct ieee80211_local *local,
struct ieee80211_supported_band *sband;
struct ieee80211_sub_if_data *sdata = sta->sdata;
u32 mask, set;
+ bool supp_rates_changed = false;
sband = local->hw.wiphy->bands[local->oper_channel->band];
@@ -774,6 +775,16 @@ static void sta_apply_parameters(struct ieee80211_local *local,
rates |= BIT(j);
}
}
+ if (rates == 0) {
+ /*
+ * Rate control algorithms may not like this.. Enable
+ * the lowest rate even if we do not know the exact
+ * supported rate set yet.
+ */
+ rates = BIT(0);
+ }
+ if (sta->sta.supp_rates[local->oper_channel->band] != rates)
+ supp_rates_changed = true;
sta->sta.supp_rates[local->oper_channel->band] = rates;
}
@@ -806,6 +817,8 @@ static void sta_apply_parameters(struct ieee80211_local *local,
}
#endif
}
+
+ return supp_rates_changed;
}
static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
@@ -929,7 +942,8 @@ static int ieee80211_change_station(struct wiphy *wiphy,
ieee80211_send_layer2_update(sta);
}
- sta_apply_parameters(local, sta, params);
+ if (sta_apply_parameters(local, sta, params))
+ rate_control_rate_init(sta);
rcu_read_unlock();
--
1.7.4.1
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply related
* [U-Boot] [PATCH] powerpc/fm: remove the TBIPA setting on platform code
From: Wolfgang Denk @ 2011-10-23 19:37 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319178713-12472-1-git-send-email-tie-fei.zang@freescale.com>
Dear Roy Zang,
In message <1319178713-12472-1-git-send-email-tie-fei.zang@freescale.com> you wrote:
> TBIPA has been set in dtsec_init_phy () funciton in drivers/net/fm/eth.c
>
> So remove the duplicate code on platform Ethernet code.
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> Cc: Andy Fleming <afleming@freescale.com>
> Cc: Kumar Gala <galak@kernel.crashing.org>
Please change the Subject: so everybody understands what you are
doing. "powerpc/fm" is not exactly clear to everybody, and neither is
TBIPA.
Nor is clear which processors / processor families / boards are
affected.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
People are always a lot more complicated than you think. It's very
important to remember that. - Terry Pratchett, _Truckers_
^ permalink raw reply
* [PATCH] mac80211: Fix TDLS support validation in add_station handler
From: Jouni Malinen @ 2011-10-23 19:36 UTC (permalink / raw)
To: John W. Linville, Johannes Berg; +Cc: linux-wireless, Arik Nemtsov
We need to verify whether the command is successful before allocating
the station entry to avoid extra processing. This also fixes a memory
leak on the error path.
Signed-off-by: Jouni Malinen <j@w1.fi>
---
net/mac80211/cfg.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index e253afa..a9ded52 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -832,6 +832,12 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
if (is_multicast_ether_addr(mac))
return -EINVAL;
+ /* Only TDLS-supporting stations can add TDLS peers */
+ if ((params->sta_flags_set & BIT(NL80211_STA_FLAG_TDLS_PEER)) &&
+ !((wiphy->flags & WIPHY_FLAG_SUPPORTS_TDLS) &&
+ sdata->vif.type == NL80211_IFTYPE_STATION))
+ return -ENOTSUPP;
+
sta = sta_info_alloc(sdata, mac, GFP_KERNEL);
if (!sta)
return -ENOMEM;
@@ -841,12 +847,6 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
sta_apply_parameters(local, sta, params);
- /* Only TDLS-supporting stations can add TDLS peers */
- if (test_sta_flag(sta, WLAN_STA_TDLS_PEER) &&
- !((wiphy->flags & WIPHY_FLAG_SUPPORTS_TDLS) &&
- sdata->vif.type == NL80211_IFTYPE_STATION))
- return -ENOTSUPP;
-
rate_control_rate_init(sta);
layer2_update = sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
--
1.7.4.1
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply related
* ****CONGRATULATION!!!, YOU HAVE BEEN AWARDED****
From: DAVID COOMES @ 2011-10-23 18:33 UTC (permalink / raw)
Dear Beneficiary,
The sum of $900,000.00USD has been deposited in your name here in the western union office by Ecowas Organisation, you are to contact Mr. William Knox to collect your money transfer control number (M.T.C.N).
Contact email: wu-claim0001@hotmail.co.uk
Western Union©
Customer Service
^ permalink raw reply
* [U-Boot] Thanks a lot in anticipation of your quick reply.
From: LAAIBAH YAK @ 2011-10-23 19:32 UTC (permalink / raw)
To: u-boot
Dearest One,
I am writing this mail to you With due respect trust and humanity, i appeal to you to exercise a little patience and read through my letter i feel quite safe dealing with you in this important business having gone through your remarkable profile, honestly i am writing this email to you with pains, tears and sorrow from my heart, i will really like to have a good relationship with you and i have a special reason why i decided to contact you, i decided to contact you due to the urgency of my situation.
My name is Miss. Laaibah Justin Yak, 23yrs old female and I from South Sudan.My father was the former Minister for SPLA Affairs and Special Adviser to President Salva Kiir of South Sudan for Decentralization. My father Dr.Justin Yak, and my mother including other top Military officers and top government officials had been on board when the plane crashed on Friday May 02, 2008.
I have chosen to contact you after my prayers and I believe that you will not betray my trust. But rather take me as your own sister. Though you may wonder why I am so soon revealing myself to you without knowing you, well,I will say that my mind convinced me that you are the true person to help me.
More so, I will like to disclose much to you if you can help me to relocate to your country because my uncle have threaten to assassinate me. The amount is $5.6 Million and I have confirmed from the bank in Burkina Faso. You will also help me to place the money in a more profitable business venture in your Country.
However, you will help by recommending a nice University in your country so that I can complete my studies. It is my intention to compensate you with 10% of the total money for your services and the balance shall be my capital in your establishment. As soon as I receive your interest in helping me, I will put things into action immediately.
In the light of the above, I shall appreciate an urgent message indicating your ability and willingness to handle this transaction sincerely. Please do keep this only to your self. I beg you not to disclose it till i come over because I am affraid of my wicked uncle who has threatened to kill me.
Sincerely yours,
Miss Laaibah justin yak
^ permalink raw reply
* Re: [PATCH] DRM: omapdrm DRM/KMS driver for TI OMAP platforms
From: Rob Clark @ 2011-10-23 19:28 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Inki Dae, dri-devel, patches
In-Reply-To: <20111019132753.GA28438@phenom.ffwll.local>
thx Daniel.. I'll shortly be sending an updated patch with some
changes based on your comments and some TODO updates..
On Wed, Oct 19, 2011 at 8:27 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Oct 14, 2011 at 10:45:50AM -0500, Rob Clark wrote:
[snip]
>> + dev->mode_config.min_width = 256;
>> + dev->mode_config.min_height = 256;
>> +
>> + /* note: pvr can't currently handle dst surfaces larger than 2k by 2k */
>> + dev->mode_config.max_width = 2048;
>> + dev->mode_config.max_height = 2048;
>
> Aside we usually put the limits of the scanout engine here, not the limits
> of the 3d core. E.g. i915 has 4k scanout limit with a 2k limit for the 2d
> core, too (for gen3 chipsets).
ok, well 2k is currently also the scanout limit, although in future
I'll have to add some omap revision # checks..
[snip]
>> +static void omap_encoder_dpms(struct drm_encoder *encoder, int mode)
>> +{
>> + struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
>> + struct drm_device *dev = encoder->dev;
>> + struct omap_drm_private *priv = dev->dev_private;
>> + int i;
>> +
>> + DBG("%s: %d", omap_encoder->mgr->name, mode);
>> +
>> + /* managers don't need to do anything for DPMS.. but we do
>> + * need to propagate to the connector, who is actually going
>> + * to enable/disable as needed:
>> + */
>> + for (i = 0; i < priv->num_connectors; i++) {
>> + struct drm_connector *connector = priv->connectors[i];
>> + if (connector->encoder == encoder) {
>> + omap_connector_dpms(connector, mode);
>> + }
>> + }
>> +}
>
> I think the dpms helpers are a bad fit for you, and your abusing
> infrastructure a bit ;-) I think better would be to but
> omap_connector_dpms into the connector dpms function and maybe call
> drm_helper_connector_dpms from there, if you still need the outmagic dpms
> calls on crtcs (with a dummy dpms function on encoders).
>
> Core drm only supports dpms on an connector. The helper function is just
> for the common case where you only have dpms state on crtcs/encoders and
> they need to be as active as the most active connector (see the
> drm_helper_choose_*_dpms functions, too).
ok, I've re-worked this one..
>> +static bool omap_encoder_mode_fixup(struct drm_encoder *encoder,
>> + struct drm_display_mode *mode,
>> + struct drm_display_mode *adjusted_mode)
>> +{
>> + struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
>> + DBG("%s", omap_encoder->mgr->name);
>> + return true;
>> +}
>> +
>> +static void omap_encoder_mode_set(struct drm_encoder *encoder,
>> + struct drm_display_mode *mode,
>> + struct drm_display_mode *adjusted_mode)
>> +{
>> + struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
>> + struct drm_device *dev = encoder->dev;
>> + struct omap_drm_private *priv = dev->dev_private;
>> + int i;
>> +
>> + mode = adjusted_mode;
>> +
>> + DBG("%s: set mode: %dx%d", omap_encoder->mgr->name,
>> + mode->hdisplay, mode->vdisplay);
>> +
>> + for (i = 0; i < priv->num_connectors; i++) {
>> + struct drm_connector *connector = priv->connectors[i];
>> + if (connector->encoder == encoder) {
>> + omap_connector_mode_set(connector, mode);
>> + }
>> + }
>
> This also looks like something the drm helpers should do for you or you're
> using them in a strange way.
>
> drm core does the modeset on a crtc only, drm_crtc_helper_set_config
> should then do the right thing of walking over all connectors/encoders
> calling set_mode and finally the mode_set_base on the crtc (roughly).
>
> I think you need to recheck what stuff you're setting in connectors and
> what in encoders (or if they are just dummies with a 1:1 connector
> mapping).
... but this one, I don't see a better way. The problem is that
omap_dss_driver is sort of a combination of encoder and connector. So
I think this one I live with for now. Long term, once we have
drm_plane stuff, I'm not really sure if it is needed to keep separate
dss and omapdrm layers. So until then I wasn't really trying to do
too much changing of dss APIs.
[snip]
>> +static void omap_framebuffer_destroy(struct drm_framebuffer *fb)
>> +{
>> + struct drm_device *dev = fb->dev;
>> + struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
>> +
>> + DBG("destroy: FB ID: %d (%p)", fb->base.id, fb);
>> +
>> + drm_framebuffer_cleanup(fb);
>
> This is a bit a general mess in kms. All drivers need to call this, and
> for added hilarity
> - drm_crtc.c drm_mode_rmfb has a TODO that this is missing
> - nouveau/radeon only do this _after_ unref'ing the backing storage
> - gma500 also tries to restore the kernel console here which should be
> done in lastclose (because you might disable another userspace fb on
> another output).
>
> Can I prod you to write the patches to clean this up and move
> drm_framebuffer_cleanup into common code?
Ok, sure.. I'll do this, but as a later patch
BR,
-R
^ permalink raw reply
* Re: [PATCH 0/3] ARM 4Kstacks: introduction
From: Tim Bird @ 2011-10-23 19:25 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Ming Lei, Arnd Bergmann, linux-arm-kernel@lists.infradead.org,
Joe Perches, linux kernel, Andi Kleen, Thomas Gleixner, mem
In-Reply-To: <20111022133648.GA21374@n2100.arm.linux.org.uk>
On 10/22/2011 6:36 AM, Russell King - ARM Linux wrote:
> On Sat, Oct 22, 2011 at 04:50:15PM +0800, Ming Lei wrote:
>> On Wed, Oct 19, 2011 at 6:51 PM, Arnd Bergmann<arnd@arndb.de> wrote:
>>> On Tuesday 18 October 2011 17:26:44 Tim Bird wrote:
>>>> Even inside Sony, usage of 4K stacks is limited
>>>> to some very special cases, where memory is exceedingly
>>>> tight (we have one system with 4M of RAM). And we
>>>> don't mind lopping off features or coding around
>>>> problem areas to support our special case.
>>> I would imagine that in those cases, you can gain more by reducing the
>>> number of threads in the system. What is the highest number of
>>> concurrent threads that you expect in a limited use case with no
>>> networking or block devices?
We have about 50 hard real-time threads, that are part of a
software stack for digital cameras that was ported over from
micro-itron. It has taken a _LONG_ time (on the order of a
few years) to tune the Linux system using RT-preempt to run
these threads as is. It would be very painful to re-architect this
part of the system.
Note that these threads don't have any of the issues that
people have raised about filesystem stack depth or printk
recursion, since they avoid a whole range of Linux syscalls
to avoid real-time issues (and stack size issues).
I'm looking at possibly implementing a mixed stack
size system, but I don't know if that will work, or whether
it would be acceptable upstream.
>>> If system run for some time, sometimes it may be difficult for
>>> memory allocator to allocate 2 continuous page frames even there are
>>> many spare page frames in system because of
>>> fragment issue, so the patch does make sense.
> If memory fragmentation is an issue for this, it probably means that we
> need to switch to a software page size of 8K (or maybe 16K) rather than
> stick with the hardware 4K size. That would be a much more reliable
> solution, especially as the L1 page table is 16K (if you're suffering
> from memory fragmentation, the first thing which'd get you is the L1
> page table allocation, not the kernel stack allocation.)
>
>> Anyway, it provides one option for user to apply 4k stack to avoid
>> such kind of process creation failure.
> I refer you to the comments made by people who've tried running with 4K
> stacks on x86, and their _vast_ experience of doing this. If they say
> that it causes stack overflows, then it's a problem.
>
I really don't think anyone on x86 has any experience whatsoever
with anything like this. This is on a digital camera, with a flash
filesystem, with a 10M memory budget, with just about every
in and out-of-tree patch from Linux-tiny applied and configured.
Many of the things that bloat up the kernel just aren't there at
all.
> The possibility of a kernel stack overflow is not something that should
> be taken lightly
Agreed.
This kind of development is done with extensive in-house testing,
and an absolutely fixed users space. This may sound like an
isolated case, but I know Sony is not alone and that lots of
embedded products are developed like this. I'm pretty sure
others would benefit from this patch.
We've already shipped tens of thousands of cameras
with this, with no problems, so it's certainly possible to get it
right.
Whether to include this comes down to a question of whether
the ability of someone to get it wrong should preclude
allowing the *option* into the kernel.
-- Tim
^ permalink raw reply
* [PATCH 0/3] ARM 4Kstacks: introduction
From: Tim Bird @ 2011-10-23 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111022133648.GA21374@n2100.arm.linux.org.uk>
On 10/22/2011 6:36 AM, Russell King - ARM Linux wrote:
> On Sat, Oct 22, 2011 at 04:50:15PM +0800, Ming Lei wrote:
>> On Wed, Oct 19, 2011 at 6:51 PM, Arnd Bergmann<arnd@arndb.de> wrote:
>>> On Tuesday 18 October 2011 17:26:44 Tim Bird wrote:
>>>> Even inside Sony, usage of 4K stacks is limited
>>>> to some very special cases, where memory is exceedingly
>>>> tight (we have one system with 4M of RAM). And we
>>>> don't mind lopping off features or coding around
>>>> problem areas to support our special case.
>>> I would imagine that in those cases, you can gain more by reducing the
>>> number of threads in the system. What is the highest number of
>>> concurrent threads that you expect in a limited use case with no
>>> networking or block devices?
We have about 50 hard real-time threads, that are part of a
software stack for digital cameras that was ported over from
micro-itron. It has taken a _LONG_ time (on the order of a
few years) to tune the Linux system using RT-preempt to run
these threads as is. It would be very painful to re-architect this
part of the system.
Note that these threads don't have any of the issues that
people have raised about filesystem stack depth or printk
recursion, since they avoid a whole range of Linux syscalls
to avoid real-time issues (and stack size issues).
I'm looking at possibly implementing a mixed stack
size system, but I don't know if that will work, or whether
it would be acceptable upstream.
>>> If system run for some time, sometimes it may be difficult for
>>> memory allocator to allocate 2 continuous page frames even there are
>>> many spare page frames in system because of
>>> fragment issue, so the patch does make sense.
> If memory fragmentation is an issue for this, it probably means that we
> need to switch to a software page size of 8K (or maybe 16K) rather than
> stick with the hardware 4K size. That would be a much more reliable
> solution, especially as the L1 page table is 16K (if you're suffering
> from memory fragmentation, the first thing which'd get you is the L1
> page table allocation, not the kernel stack allocation.)
>
>> Anyway, it provides one option for user to apply 4k stack to avoid
>> such kind of process creation failure.
> I refer you to the comments made by people who've tried running with 4K
> stacks on x86, and their _vast_ experience of doing this. If they say
> that it causes stack overflows, then it's a problem.
>
I really don't think anyone on x86 has any experience whatsoever
with anything like this. This is on a digital camera, with a flash
filesystem, with a 10M memory budget, with just about every
in and out-of-tree patch from Linux-tiny applied and configured.
Many of the things that bloat up the kernel just aren't there at
all.
> The possibility of a kernel stack overflow is not something that should
> be taken lightly
Agreed.
This kind of development is done with extensive in-house testing,
and an absolutely fixed users space. This may sound like an
isolated case, but I know Sony is not alone and that lots of
embedded products are developed like this. I'm pretty sure
others would benefit from this patch.
We've already shipped tens of thousands of cameras
with this, with no problems, so it's certainly possible to get it
right.
Whether to include this comes down to a question of whether
the ability of someone to get it wrong should preclude
allowing the *option* into the kernel.
-- Tim
^ permalink raw reply
* Re: [PATCH 2/2] drm/i915: properly prefault for pread/pwrite
From: Keith Packard @ 2011-10-23 19:23 UTC (permalink / raw)
To: Daniel Vetter, Chris Wilson; +Cc: Daniel Vetter, intel-gfx, stable
In-Reply-To: <20111023101830.GE2953@phenom.ffwll.local>
[-- Attachment #1.1: Type: text/plain, Size: 609 bytes --]
On Sun, 23 Oct 2011 12:18:30 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> Hi Keith,
>
> This patch isn't in your -next pull. This papers over a spurious -EFAULT
> in the pwrite/pread paths that actually gets hit in the wild. The real fix
> in the form of a almost complete rewrite of the pwrite/pread paths won't
> be ready for 3.2.
We had several comments wondering whether writing zeros was OK as this
occurs before some potential error returns that should leave the buffer
unmodified. I didn't have a better suggestion, but that seems pretty
sketchy to me.
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: Netfilter TCP Established Timeout
From: Nikolay S. @ 2011-10-23 19:22 UTC (permalink / raw)
To: Erik Schweigert; +Cc: netfilter
In-Reply-To: <CADVVA49349gKbXWK8j9dhGXQ5o2JRT019Jsxyv1vD7zP6j6B+g@mail.gmail.com>
В Чтв, 20/10/2011 в 12:10 -0700, Erik Schweigert пишет:
> On Wed, Oct 19, 2011 at 8:36 PM, Nikolay S. <nowhere@hakkenden.ath.cx> wrote:
> >
> > В Срд, 19/10/2011 в 12:03 -0700, Erik Schweigert пишет:
> > > Hi all,
> > >
> > > I have noticed an oddity in the timeout values of a TCP Established
> > > connection. I currently have the
> > > "nf_conntrack_tcp_timeout_established = 1800".
> > >
> > > # cat /proc/net/nf_conntrack | grep EST
> > > ipv4 2 tcp 6 1385 ESTABLISHED src=192.168.10.25
> > > dst=192.168.10.134 sport=2513 dport=1217 packets=71 bytes=10154
> > > src=192.168.10.134 dst=192.168.10.25 sport=1217 dport=2513 pac1
> > > ----> ipv4 2 tcp 6 1799 ESTABLISHED src=192.168.10.25
> > > dst=192.168.10.134 sport=2550 dport=1217 packets=1142 bytes=121874
> > > src=192.168.10.134 dst=192.168.10.25 sport=1217 dport=2550 1
> > > ipv4 2 tcp 6 1413 ESTABLISHED src=192.168.10.25
> > > dst=192.168.10.134 sport=2515 dport=1217 packets=824 bytes=101370
> > > src=192.168.10.134 dst=192.168.10.25 sport=1217 dport=2515 p1
> > > ipv4 2 tcp 6 263 ESTABLISHED src=192.168.10.25
> > > dst=192.168.10.134 sport=2440 dport=1101 packets=41 bytes=6458
> > > src=192.168.10.134 dst=192.168.10.25 sport=1101 dport=2440 packe1
> > > ipv4 2 tcp 6 1221 ESTABLISHED src=192.168.10.25
> > > dst=192.168.10.134 sport=2512 dport=1101 packets=79 bytes=13578
> > > src=192.168.10.134 dst=192.168.10.25 sport=1101 dport=2512 pac1
> > > # cat /proc/net/nf_conntrack | grep EST
> > > ipv4 2 tcp 6 1369 ESTABLISHED src=192.168.10.25
> > > dst=192.168.10.134 sport=2513 dport=1217 packets=71 bytes=10154
> > > src=192.168.10.134 dst=192.168.10.25 sport=1217 dport=2513 pac1
> > > ----> ipv4 2 tcp 6 296 ESTABLISHED src=192.168.10.25
> > > dst=192.168.10.134 sport=2550 dport=1217 packets=1166 bytes=124610
> > > src=192.168.10.134 dst=192.168.10.25 sport=1217 dport=2550 p1
> > > ipv4 2 tcp 6 1396 ESTABLISHED src=192.168.10.25
> > > dst=192.168.10.134 sport=2515 dport=1217 packets=824 bytes=101370
> > > src=192.168.10.134 dst=192.168.10.25 sport=1217 dport=2515 p1
> > > ipv4 2 tcp 6 247 ESTABLISHED src=192.168.10.25
> > > dst=192.168.10.134 sport=2440 dport=1101 packets=41 bytes=6458
> > > src=192.168.10.134 dst=192.168.10.25 sport=1101 dport=2440 packe1
> > > ipv4 2 tcp 6 1205 ESTABLISHED src=192.168.10.25
> > > dst=192.168.10.134 sport=2512 dport=1101 packets=79 bytes=13578
> > > src=192.168.10.134 dst=192.168.10.25 sport=1101 dport=2512 pac1
> > >
> > > You will notice in the two iterations I have marked above, the timeout
> > > values goes from 1799 to 296 within a 16 second span. Is this a bug
> > > or something inherent to the connection tracking system that I unaware
> > > of.
> >
> > TCP conntrack allows 5 minutes (300 seconds) for hosts to send the
> > acknowledge. Once connection has no unacknowledged segments, timeout
> > will revert to 1800 seconds.
>
> Is this also a user settable value?
No
>
> >
> > >
> > > I am running kernel 2.6.26.5. My current settings of the tunable
> > > conntrack features are:
> > >
> > > nf_conntrack_tcp_be_liberal = 0
> > > nf_conntrack_tcp_loose = 1
> > > nf_conntrack_tcp_max_retrans = 3
> > > nf_conntrack_tcp_timeout_close = 10
> > > nf_conntrack_tcp_timeout_close_wait = 60
> > > nf_conntrack_tcp_timeout_established = 1800
> > > nf_conntrack_tcp_timeout_fin_wait = 120
> > > nf_conntrack_tcp_timeout_last_ack = 30
> > > nf_conntrack_tcp_timeout_max_retrans = 300
> > > nf_conntrack_tcp_timeout_syn_recv = 60
> > > nf_conntrack_tcp_timeout_syn_sent = 120
> > > nf_conntrack_tcp_timeout_time_wait = 120
> > >
> > > Any help or suggestions is appreciated,
> > > Erik
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe netfilter" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> >
>
>
>
> --
> Erik Schweigert
> Email: ejschweigert@gmail.com
> Website: http://www.lainoox.com
^ permalink raw reply
* Re: how to run ceph on top of other local file system
From: sheng qiu @ 2011-10-23 19:22 UTC (permalink / raw)
To: Gregory Farnum; +Cc: ceph-devel
In-Reply-To: <CAF3hT9BwDAnUewrfTeZSWMuJSDHZW765jKF2sgQ2jNa32cLgxw@mail.gmail.com>
hi all,
does ceph only support ext3 and btrfs? i mean if i have another file
system, it support xattr, but it does not support journals, can i
close the journal config and run it with ceph?
i tried to do that by modifying the ceph.conf file (close the journal
on osd). the mkcephfs seems ok, but when i start the service, cosd
will crash.
here's the log:
2011-10-23 13:57:42.224779 7f1845ce6720 ceph version 0.34.commit:
2f039eeeb745622b866d80feda7afa055e15f6d6. process: cosd. pid: 7849
2011-10-23 13:57:42.225679 7f1845ce6720 filestore(/mnt/data/osd.0)
mount FIEMAP ioctl is NOT supported
2011-10-23 13:57:42.225697 7f1845ce6720 filestore(/mnt/data/osd.0)
mount did NOT detect btrfs
2011-10-23 13:57:42.225780 7f1845ce6720 filestore(/mnt/data/osd.0)
mount found snaps <>
2011-10-23 13:57:42.225805 7f1845ce6720 filestore(/mnt/data/osd.0)
mount WARNING: no btrfs, and no journal in writeahead mode; data may
be lost
2011-10-23 13:57:42.225831 7f1845ce6720 filestore(/mnt/data/osd.0)
mount WARNING: not btrfs or ext3; data may be lost
2011-10-23 13:57:42.225836 7f1845ce6720 filestore(/mnt/data/osd.0)
mount WARNING: no journal
*** Caught signal (Aborted) **
in thread 0x7f1845ce6720
ceph version 0.34 (commit:2f039eeeb745622b866d80feda7afa055e15f6d6)
1: ./cosd() [0x5c6304]
2: (()+0xf8f0) [0x7f18458dc8f0]
3: (gsignal()+0x35) [0x7f1844307a75]
4: (abort()+0x180) [0x7f184430b5c0]
5: (__gnu_cxx::__verbose_terminate_handler()+0x115) [0x7f1844bbd8e5]
6: (()+0xcad16) [0x7f1844bbbd16]
7: (()+0xcad43) [0x7f1844bbbd43]
8: (()+0xcae3e) [0x7f1844bbbe3e]
9: (CrushWrapper::decode(ceph::buffer::list::iterator&)+0xac) [0x5611fc]
10: (OSDMap::decode(ceph::buffer::list&)+0x8aa) [0x5622aa]
11: (OSD::get_map(unsigned int)+0x221) [0x52f441]
12: (OSD::init()+0x47e) [0x53792e]
13: (main()+0x2adc) [0x49d07c]
14: (__libc_start_main()+0xfd) [0x7f18442f2c4d]
15: ./cosd() [0x49a179]
2011-10-23 13:58:06.656315 7fcff35c6720 ceph version 0.34.commit:
2f039eeeb745622b866d80feda7afa055e15f6d6. process: cosd. pid: 8596
2011-10-23 13:58:06.657232 7fcff35c6720 filestore(/mnt/data/osd.0)
mount FIEMAP ioctl is NOT supported
2011-10-23 13:58:06.657250 7fcff35c6720 filestore(/mnt/data/osd.0)
mount did NOT detect btrfs
2011-10-23 13:58:06.657285 7fcff35c6720 filestore(/mnt/data/osd.0)
mount found snaps <>
2011-10-23 13:58:06.657302 7fcff35c6720 filestore(/mnt/data/osd.0)
mount WARNING: no btrfs, and no journal in writeahead mode; data may
be lost
2011-10-23 13:58:06.657325 7fcff35c6720 filestore(/mnt/data/osd.0)
mount WARNING: not btrfs or ext3; data may be lost
2011-10-23 13:58:06.657330 7fcff35c6720 filestore(/mnt/data/osd.0)
mount WARNING: no journal
*** Caught signal (Aborted) **
in thread 0x7fcff35c6720
ceph version 0.34 (commit:2f039eeeb745622b866d80feda7afa055e15f6d6)
1: ./cosd() [0x5c6304]
2: (()+0xf8f0) [0x7fcff31bc8f0]
3: (gsignal()+0x35) [0x7fcff1be7a75]
4: (abort()+0x180) [0x7fcff1beb5c0]
5: (__gnu_cxx::__verbose_terminate_handler()+0x115) [0x7fcff249d8e5]
6: (()+0xcad16) [0x7fcff249bd16]
7: (()+0xcad43) [0x7fcff249bd43]
8: (()+0xcae3e) [0x7fcff249be3e]
9: (CrushWrapper::decode(ceph::buffer::list::iterator&)+0xac) [0x5611fc]
10: (OSDMap::decode(ceph::buffer::list&)+0x8aa) [0x5622aa]
11: (OSD::get_map(unsigned int)+0x221) [0x52f441]
12: (OSD::init()+0x47e) [0x53792e]
13: (main()+0x2adc) [0x49d07c]
14: (__libc_start_main()+0xfd) [0x7fcff1bd2c4d]
15: ./cosd() [0x49a179]
does anyone have idea?
Thanks,
Sheng
On Mon, Oct 17, 2011 at 12:31 PM, Gregory Farnum
<gregory.farnum@dreamhost.com> wrote:
> On Mon, Oct 17, 2011 at 10:20 AM, sheng qiu <herbert1984106@gmail.com> wrote:
>> if my local file system does not support extended attributes, can i
>> use it?
> Unfortunately not. Ceph requires xattr support; it uses xattrs for
> internal bookkeeping as well as for its own xattr support.
>
> Most filesystems do support xattrs these days, though; you probably
> just need to specify it as a mount option. :)
> -Greg
>
--
Sheng Qiu
Texas A & M University
Room 302 Wisenbaker
email: herbert1984106@gmail.com
College Station, TX 77843-3259
^ permalink raw reply
* Sie haben gewonne
From: Sie haben gewonne @ 2011-10-23 19:14 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 134 bytes --]
Wir empfehlen Ihnen, pdf Attached Datei цffnen,und wenden Sie sich fьr Ihr Agent Lotteriegewinn.
Mit freundlichen GrьЯen,
Management
[-- Attachment #2: NOTARISCHE GEWINNBENACHRICHTIGUNG.pdf --]
[-- Type: application/octet-stream, Size: 52858 bytes --]
^ permalink raw reply
* Re: [PATCH] drm/i915: forcewake warning fixes in debugfs
From: Keith Packard @ 2011-10-23 19:21 UTC (permalink / raw)
To: Daniel Vetter, Ben Widawsky; +Cc: intel-gfx
In-Reply-To: <20111023101343.GD2953@phenom.ffwll.local>
[-- Attachment #1.1: Type: text/plain, Size: 333 bytes --]
On Sun, 23 Oct 2011 12:13:43 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> Hi Keith,
>
> This patch isn't in your -next pull request. Please consider merging for
> 3.2.
I didn't ever see a reply from Nicolas that it fixed his problem; would
be nice to know whether this actually worked...
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: tag process's future sockets for iptables rules?
From: Nikolay S. @ 2011-10-23 19:20 UTC (permalink / raw)
To: p. awa; +Cc: netfilter
In-Reply-To: <1RI1gs-000H1O-OY@internal.tormail.net>
В Вск, 23/10/2011 в 17:18 +0000, p. awa пишет:
> > >| netfilter_add_tag("public-addresses-proxied-via-tor");
> > >| netfilter_add_tag("internal-addresses-directly");
> > >| netfilter_remove_tag("proxy-dns");
> > >| execlp("wget", ...);
> >
> > A socket option, SO_MARK, for use with setsockopt/getsockopt.
>
> but setsockopt is per socket. i'm looking for something that is
> per process (and inherited by children - in the example, wget).
> this is to replace what i do at the moment, namely
>
> | setgid(123);
> | execlp("wget", ...);
>
> and
>
> # iptables ... -m owner --gid-owner 123 ...
Well, you could do interposition of libc's socket() with LD_PRELOAD, and
call setsockopt SO_MARK in the wrapper.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" 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] drm/i915: disable temporal dithering on the internal panel
From: Keith Packard @ 2011-10-23 19:18 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, intel-gfx
In-Reply-To: <20111023100332.GA2953@phenom.ffwll.local>
[-- Attachment #1.1: Type: text/plain, Size: 317 bytes --]
On Sun, 23 Oct 2011 12:03:32 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> Hi Keith,
>
> This patch hasn't shown up in your -next pull request. Please consider
> merging for 3.2.
So small I missed it? I'll send it in the next set after Dave merges
what I've posted so far.
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: omap3isp: BT.656 support
From: Boris Todorov @ 2011-10-23 19:15 UTC (permalink / raw)
To: Stefan Herbrechtsmeier; +Cc: linux-media
In-Reply-To: <4EA031FD.7020109@cit-ec.uni-bielefeld.de>
On Thu, Oct 20, 2011 at 5:36 PM, Stefan Herbrechtsmeier
<sherbrec@cit-ec.uni-bielefeld.de> wrote:
> Am 20.10.2011 14:14, schrieb Boris Todorov:
>> On Thu, Oct 20, 2011 at 12:03 PM, Stefan Herbrechtsmeier
>> <sherbrec@cit-ec.uni-bielefeld.de> wrote:
>>> Am 20.10.2011 08:56, schrieb Boris Todorov:
>>>> On Wed, Oct 19, 2011 at 7:26 PM, Stefan Herbrechtsmeier
>>>> <sherbrec@cit-ec.uni-bielefeld.de> wrote:
>>>>> Am 18.10.2011 15:33, schrieb Boris Todorov:
>>>>>> Hi
>>>>>>
>>>>>> I'm trying to run OMAP + TVP5151 in BT656 mode.
>>>>>>
>>>>>> I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git).
>>>>>> Plus the following patches:
>>>>>>
>>>>>> TVP5151:
>>>>>> https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150
>>>>>>
>>>>>> The latest RFC patches for BT656 support:
>>>>>>
>>>>>> Enrico Butera (2):
>>>>>> omap3isp: ispvideo: export isp_video_mbus_to_pix
>>>>>> omap3isp: ispccdc: configure CCDC registers and add BT656 support
>>>>>>
>>>>>> Javier Martinez Canillas (1):
>>>>>> omap3isp: ccdc: Add interlaced field mode to platform data
>>>>>>
>>>>>>
>>>>>> I'm able to configure with media-ctl:
>>>>>>
>>>>>> media-ctl -v -r -l '"tvp5150 3-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3
>>>>>> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
>>>>>> media-ctl -v --set-format '"tvp5150 3-005c":0 [UYVY2X8 720x525]'
>>>>>> media-ctl -v --set-format '"OMAP3 ISP CCDC":0 [UYVY2X8 720x525]'
>>>>>> media-ctl -v --set-format '"OMAP3 ISP CCDC":1 [UYVY2X8 720x525]'
>>>>>>
>>>>>> But
>>>>>> ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4
>>>>>>
>>>>>> sleeps after
>>>>>> ...
>>>>>> Buffer 1 mapped at address 0x4021d000.
>>>>>> length: 756000 offset: 1515520
>>>>>> Buffer 2 mapped at address 0x402d6000.
>>>>>> length: 756000 offset: 2273280
>>>>>> Buffer 3 mapped at address 0x4038f000.
>>>>>>
>>>>>> Anyone with the same issue??? This happens with every other v4l test app I used.
>>>>> I had the same issue.
>>>>>
>>>>> Make sure that you disable the xclk when you remove your sensor driver.
>>>>>
>>>>> isp->platform_cb.set_xclk(isp, 0, ISP_XCLK_A)
>>>> How exactly did you solved your problem? I don't see how XCLK in
>>>> _remove will help. Pls explain.
>>> Sorry, I mean deactive / power off your sensor.
>>>> Btw I'm feeding TVP with external clock (not from xtal pins) -
>>>> omap.cam_xclk -> tvp.clk_in
>>> I mean the cam_xclk.
>>>> And I'm using kind of hack to get it:
>>>> isp_probe()
>>>> + isp_set_xclk(isp, 27000000, 1);
>>> This is your problem.
>>>
>>> You should control the clock via board / platform callback from your driver.
>>> Example:
>>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg56627.html
>>>
>>> It is important that you set the clock to zero when your driver is not
>>> in use.
>>>
>>> The problem is connected to the use count of the ISP and some
>>> initialisation which only happen when the counter change between zero
>>> and one.
>>>
>> tvp_probe() needs clock for i2c detected/config. tvp5150_s_power call
>> happens when video starts streaming and if tvp is not configured ->
>> kernel panic.
> I use an other sensor and driver and this config the sensor during start
> stream.
>> And what about the case when TVP is used with OSC on XTAL pins and
>> CLK_IN is not used at all?
> Then your system will work, as you never call isp_set_xclk.
>
> The problem is not the clock, but how the isp driver works.
> It expects, that the sensor driver disable the cam_xclk, if the sensor
> is not used.
>> Maybe I don't fully understand what is happening...
>> or isp_set_xclk() use is messing up with ISP
> On my system I have the same issues as you if I don't set the cam_xclk
> to zero
> during stop streaming.
>
> I haven't investigate in the real cause for the issue. I only released,
> that this
> issue stick together with an always enabled cam_xclk.
>
> Regards,
> Stefan
Thanks Stefan. Now I have IRQs and I'm able to get some image from TVP.
^ permalink raw reply
* [PATCH 2/4] perf ui browser: Use libslang to read keys
From: Arnaldo Carvalho de Melo @ 2011-10-23 19:12 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-kernel, Arnaldo Carvalho de Melo, David Ahern,
Frederic Weisbecker, Mike Galbraith, Paul Mackerras,
Peter Zijlstra, Stephane Eranian
In-Reply-To: <1319397143-20301-1-git-send-email-acme@infradead.org>
From: Arnaldo Carvalho de Melo <acme@redhat.com>
Just another step in stopping the use of libnewt in perf.
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-uy6s534uqxq8tenh6s3k8ocj@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/Makefile | 1 +
tools/perf/builtin-annotate.c | 8 ++--
tools/perf/util/hist.h | 9 +--
tools/perf/util/ui/browser.c | 79 +++++++++++++++++++++----------
tools/perf/util/ui/browsers/annotate.c | 19 +++----
tools/perf/util/ui/browsers/hists.c | 33 ++++++-------
tools/perf/util/ui/keysyms.h | 25 ++++++++++
tools/perf/util/ui/libslang.h | 2 +
tools/perf/util/ui/setup.c | 13 +++++
9 files changed, 125 insertions(+), 64 deletions(-)
create mode 100644 tools/perf/util/ui/keysyms.h
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 37fe930..b98e307 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -472,6 +472,7 @@ else
LIB_H += util/ui/browser.h
LIB_H += util/ui/browsers/map.h
LIB_H += util/ui/helpline.h
+ LIB_H += util/ui/keysyms.h
LIB_H += util/ui/libslang.h
LIB_H += util/ui/progress.h
LIB_H += util/ui/util.h
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 3ea764a..46b4c24 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -118,7 +118,7 @@ static void hists__find_annotations(struct hists *self, int evidx,
int nr_events)
{
struct rb_node *nd = rb_first(&self->entries), *next;
- int key = KEY_RIGHT;
+ int key = K_RIGHT;
while (nd) {
struct hist_entry *he = rb_entry(nd, struct hist_entry, rb_node);
@@ -130,7 +130,7 @@ static void hists__find_annotations(struct hists *self, int evidx,
notes = symbol__annotation(he->ms.sym);
if (notes->src == NULL) {
find_next:
- if (key == KEY_LEFT)
+ if (key == K_LEFT)
nd = rb_prev(nd);
else
nd = rb_next(nd);
@@ -141,10 +141,10 @@ find_next:
key = hist_entry__tui_annotate(he, evidx, nr_events,
NULL, NULL, 0);
switch (key) {
- case KEY_RIGHT:
+ case K_RIGHT:
next = rb_next(nd);
break;
- case KEY_LEFT:
+ case K_LEFT:
next = rb_prev(nd);
break;
default:
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 575bcbc..ff93ddc 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -125,16 +125,13 @@ static inline int hist_entry__tui_annotate(struct hist_entry *self __used,
{
return 0;
}
-#define KEY_LEFT -1
-#define KEY_RIGHT -2
+#define K_LEFT -1
+#define K_RIGHT -2
#else
-#include <newt.h>
+#include "ui/keysyms.h"
int hist_entry__tui_annotate(struct hist_entry *he, int evidx, int nr_events,
void(*timer)(void *arg), void *arg, int delay_secs);
-#define KEY_LEFT NEWT_KEY_LEFT
-#define KEY_RIGHT NEWT_KEY_RIGHT
-
int perf_evlist__tui_browse_hists(struct perf_evlist *evlist, const char *help,
void(*timer)(void *arg), void *arg,
int refresh);
diff --git a/tools/perf/util/ui/browser.c b/tools/perf/util/ui/browser.c
index 06fc9eb..5359f37 100644
--- a/tools/perf/util/ui/browser.c
+++ b/tools/perf/util/ui/browser.c
@@ -11,10 +11,9 @@
#include <sys/ttydefaults.h>
#include "browser.h"
#include "helpline.h"
+#include "keysyms.h"
#include "../color.h"
-int newtGetKey(void);
-
static int ui_browser__percent_color(struct ui_browser *browser,
double percent, bool current)
{
@@ -292,16 +291,55 @@ void ui_browser__update_nr_entries(struct ui_browser *browser, u32 nr_entries)
browser->seek(browser, browser->top_idx, SEEK_SET);
}
+static int ui__getch(int delay_secs)
+{
+ struct timeval timeout, *ptimeout = delay_secs ? &timeout : NULL;
+ fd_set read_set;
+ int err, key;
+
+ FD_ZERO(&read_set);
+ FD_SET(0, &read_set);
+
+ if (delay_secs) {
+ timeout.tv_sec = delay_secs;
+ timeout.tv_usec = 0;
+ }
+
+ err = select(1, &read_set, NULL, NULL, ptimeout);
+
+ if (err == 0)
+ return K_TIMER;
+
+ if (err == -1) {
+ if (errno == EINTR)
+ return K_RESIZE;
+ return K_ERROR;
+ }
+
+ key = SLang_getkey();
+ if (key != K_ESC)
+ return key;
+
+ FD_ZERO(&read_set);
+ FD_SET(0, &read_set);
+ timeout.tv_sec = 0;
+ timeout.tv_usec = 20;
+ err = select(1, &read_set, NULL, NULL, &timeout);
+ if (err == 0)
+ return K_ESC;
+
+ SLang_ungetkey(key);
+ return SLkp_getkey();
+}
+
int ui_browser__run(struct ui_browser *self, int delay_secs)
{
int err, key;
- struct timeval timeout, *ptimeout = delay_secs ? &timeout : NULL;
pthread__unblock_sigwinch();
while (1) {
off_t offset;
- fd_set read_set;
pthread_mutex_lock(&ui__lock);
err = __ui_browser__refresh(self);
@@ -310,20 +348,9 @@ int ui_browser__run(struct ui_browser *self, int delay_secs)
if (err < 0)
break;
- FD_ZERO(&read_set);
- FD_SET(0, &read_set);
+ key = ui__getch(delay_secs);
- if (delay_secs) {
- timeout.tv_sec = delay_secs;
- timeout.tv_usec = 0;
- }
-
- err = select(1, &read_set, NULL, NULL, ptimeout);
- if (err > 0 && FD_ISSET(0, &read_set))
- key = newtGetKey();
- else if (err == 0)
- break;
- else {
+ if (key == K_RESIZE) {
pthread_mutex_lock(&ui__lock);
SLtt_get_screen_size();
SLsmg_reinit_smg();
@@ -335,9 +362,9 @@ int ui_browser__run(struct ui_browser *self, int delay_secs)
}
if (self->use_navkeypressed && !self->navkeypressed) {
- if (key == NEWT_KEY_DOWN || key == NEWT_KEY_UP ||
- key == NEWT_KEY_PGDN || key == NEWT_KEY_PGUP ||
- key == NEWT_KEY_HOME || key == NEWT_KEY_END ||
+ if (key == K_DOWN || key == K_UP ||
+ key == K_PGDN || key == K_PGUP ||
+ key == K_HOME || key == K_END ||
key == ' ') {
self->navkeypressed = true;
continue;
@@ -346,7 +373,7 @@ int ui_browser__run(struct ui_browser *self, int delay_secs)
}
switch (key) {
- case NEWT_KEY_DOWN:
+ case K_DOWN:
if (self->index == self->nr_entries - 1)
break;
++self->index;
@@ -355,7 +382,7 @@ int ui_browser__run(struct ui_browser *self, int delay_secs)
self->seek(self, +1, SEEK_CUR);
}
break;
- case NEWT_KEY_UP:
+ case K_UP:
if (self->index == 0)
break;
--self->index;
@@ -364,7 +391,7 @@ int ui_browser__run(struct ui_browser *self, int delay_secs)
self->seek(self, -1, SEEK_CUR);
}
break;
- case NEWT_KEY_PGDN:
+ case K_PGDN:
case ' ':
if (self->top_idx + self->height > self->nr_entries - 1)
break;
@@ -376,7 +403,7 @@ int ui_browser__run(struct ui_browser *self, int delay_secs)
self->top_idx += offset;
self->seek(self, +offset, SEEK_CUR);
break;
- case NEWT_KEY_PGUP:
+ case K_PGUP:
if (self->top_idx == 0)
break;
@@ -389,10 +416,10 @@ int ui_browser__run(struct ui_browser *self, int delay_secs)
self->top_idx -= offset;
self->seek(self, -offset, SEEK_CUR);
break;
- case NEWT_KEY_HOME:
+ case K_HOME:
ui_browser__reset_index(self);
break;
- case NEWT_KEY_END:
+ case K_END:
offset = self->height - 1;
if (offset >= self->nr_entries)
offset = self->nr_entries - 1;
diff --git a/tools/perf/util/ui/browsers/annotate.c b/tools/perf/util/ui/browsers/annotate.c
index 1a12d8f..4e0cb7f 100644
--- a/tools/perf/util/ui/browsers/annotate.c
+++ b/tools/perf/util/ui/browsers/annotate.c
@@ -6,6 +6,7 @@
#include "../../sort.h"
#include "../../symbol.h"
#include <pthread.h>
+#include <newt.h>
static void ui__error_window(const char *fmt, ...)
{
@@ -265,18 +266,14 @@ static int annotate_browser__run(struct annotate_browser *self, int evidx,
}
switch (key) {
- case -1:
- /*
- * FIXME we need to check if it was
- * es.reason == NEWT_EXIT_TIMER
- */
+ case K_TIMER:
if (timer != NULL)
timer(arg);
if (delay_secs != 0)
symbol__annotate_decay_histogram(sym, evidx);
continue;
- case NEWT_KEY_TAB:
+ case K_TAB:
if (nd != NULL) {
nd = rb_prev(nd);
if (nd == NULL)
@@ -284,7 +281,7 @@ static int annotate_browser__run(struct annotate_browser *self, int evidx,
} else
nd = self->curr_hot;
break;
- case NEWT_KEY_UNTAB:
+ case K_UNTAB:
if (nd != NULL)
nd = rb_next(nd);
if (nd == NULL)
@@ -299,8 +296,8 @@ static int annotate_browser__run(struct annotate_browser *self, int evidx,
if (annotate_browser__toggle_source(self))
ui_helpline__puts(help);
continue;
- case NEWT_KEY_ENTER:
- case NEWT_KEY_RIGHT:
+ case K_ENTER:
+ case K_RIGHT:
if (self->selection == NULL) {
ui_helpline__puts("Huh? No selection. Report to linux-kernel@vger.kernel.org");
continue;
@@ -350,8 +347,8 @@ static int annotate_browser__run(struct annotate_browser *self, int evidx,
timer, arg, delay_secs);
}
continue;
- case NEWT_KEY_LEFT:
- case NEWT_KEY_ESCAPE:
+ case K_LEFT:
+ case K_ESC:
case 'q':
case CTRL('c'):
goto out;
diff --git a/tools/perf/util/ui/browsers/hists.c b/tools/perf/util/ui/browsers/hists.c
index a06e7d9..af12e6f 100644
--- a/tools/perf/util/ui/browsers/hists.c
+++ b/tools/perf/util/ui/browsers/hists.c
@@ -344,7 +344,7 @@ static int hist_browser__run(struct hist_browser *self, const char *ev_name,
/* Expand the whole world. */
hist_browser__set_folding(self, true);
break;
- case NEWT_KEY_ENTER:
+ case K_ENTER:
if (hist_browser__toggle_fold(self))
break;
/* fall thru */
@@ -872,8 +872,8 @@ static int perf_evsel__hists_browse(struct perf_evsel *evsel, int nr_events,
}
switch (key) {
- case NEWT_KEY_TAB:
- case NEWT_KEY_UNTAB:
+ case K_TAB:
+ case K_UNTAB:
if (nr_events == 1)
continue;
/*
@@ -891,7 +891,7 @@ static int perf_evsel__hists_browse(struct perf_evsel *evsel, int nr_events,
goto zoom_dso;
case 't':
goto zoom_thread;
- case NEWT_KEY_F1:
+ case K_F1:
case 'h':
case '?':
ui__help_window("h/?/F1 Show this window\n"
@@ -909,11 +909,11 @@ static int perf_evsel__hists_browse(struct perf_evsel *evsel, int nr_events,
"d Zoom into current DSO\n"
"t Zoom into current Thread\n");
continue;
- case NEWT_KEY_ENTER:
- case NEWT_KEY_RIGHT:
+ case K_ENTER:
+ case K_RIGHT:
/* menu */
break;
- case NEWT_KEY_LEFT: {
+ case K_LEFT: {
const void *top;
if (pstack__empty(fstack)) {
@@ -931,7 +931,7 @@ static int perf_evsel__hists_browse(struct perf_evsel *evsel, int nr_events,
goto zoom_out_thread;
continue;
}
- case NEWT_KEY_ESCAPE:
+ case K_ESC:
if (!left_exits &&
!ui__dialog_yesno("Do you really want to exit?"))
continue;
@@ -1091,12 +1091,11 @@ static int perf_evsel_menu__run(struct perf_evsel_menu *menu,
key = ui_browser__run(&menu->b, delay_secs);
switch (key) {
- case -1:
- /* FIXME we need to check if it was es.reason == NEWT_EXIT_TIMER */
+ case K_TIMER:
timer(arg);
continue;
- case NEWT_KEY_RIGHT:
- case NEWT_KEY_ENTER:
+ case K_RIGHT:
+ case K_ENTER:
if (!menu->selection)
continue;
pos = menu->selection;
@@ -1114,19 +1113,19 @@ browse_hists:
arg, delay_secs);
ui_browser__show_title(&menu->b, title);
switch (key) {
- case NEWT_KEY_TAB:
+ case K_TAB:
if (pos->node.next == &evlist->entries)
pos = list_entry(evlist->entries.next, struct perf_evsel, node);
else
pos = list_entry(pos->node.next, struct perf_evsel, node);
goto browse_hists;
- case NEWT_KEY_UNTAB:
+ case K_UNTAB:
if (pos->node.prev == &evlist->entries)
pos = list_entry(evlist->entries.prev, struct perf_evsel, node);
else
pos = list_entry(pos->node.prev, struct perf_evsel, node);
goto browse_hists;
- case NEWT_KEY_ESCAPE:
+ case K_ESC:
if (!ui__dialog_yesno("Do you really want to exit?"))
continue;
/* Fall thru */
@@ -1136,9 +1135,9 @@ browse_hists:
default:
continue;
}
- case NEWT_KEY_LEFT:
+ case K_LEFT:
continue;
- case NEWT_KEY_ESCAPE:
+ case K_ESC:
if (!ui__dialog_yesno("Do you really want to exit?"))
continue;
/* Fall thru */
diff --git a/tools/perf/util/ui/keysyms.h b/tools/perf/util/ui/keysyms.h
new file mode 100644
index 0000000..3458b19
--- /dev/null
+++ b/tools/perf/util/ui/keysyms.h
@@ -0,0 +1,25 @@
+#ifndef _PERF_KEYSYMS_H_
+#define _PERF_KEYSYMS_H_ 1
+
+#include "libslang.h"
+
+#define K_DOWN SL_KEY_DOWN
+#define K_END SL_KEY_END
+#define K_ENTER '\r'
+#define K_ESC 033
+#define K_F1 SL_KEY_F(1)
+#define K_HOME SL_KEY_HOME
+#define K_LEFT SL_KEY_LEFT
+#define K_PGDN SL_KEY_NPAGE
+#define K_PGUP SL_KEY_PPAGE
+#define K_RIGHT SL_KEY_RIGHT
+#define K_TAB '\t'
+#define K_UNTAB SL_KEY_UNTAB
+#define K_UP SL_KEY_UP
+
+/* Not really keys */
+#define K_TIMER -1
+#define K_ERROR -2
+#define K_RESIZE -3
+
+#endif /* _PERF_KEYSYMS_H_ */
diff --git a/tools/perf/util/ui/libslang.h b/tools/perf/util/ui/libslang.h
index 2b63e1c..4d54b64 100644
--- a/tools/perf/util/ui/libslang.h
+++ b/tools/perf/util/ui/libslang.h
@@ -24,4 +24,6 @@
#define sltt_set_color SLtt_set_color
#endif
+#define SL_KEY_UNTAB 0x1000
+
#endif /* _PERF_UI_SLANG_H_ */
diff --git a/tools/perf/util/ui/setup.c b/tools/perf/util/ui/setup.c
index 5111f1a..1e6ba06 100644
--- a/tools/perf/util/ui/setup.c
+++ b/tools/perf/util/ui/setup.c
@@ -18,6 +18,18 @@ static void newt_suspend(void *d __used)
newtResume();
}
+static int ui__init(void)
+{
+ int err = SLkp_init();
+
+ if (err < 0)
+ goto out;
+
+ SLkp_define_keysym((char *)"^(kB)", SL_KEY_UNTAB);
+out:
+ return err;
+}
+
static void ui__exit(void)
{
SLtt_set_cursor_visibility(1);
@@ -44,6 +56,7 @@ void setup_browser(bool fallback_to_pager)
use_browser = 1;
newtInit();
+ ui__init();
newtSetSuspendCallback(newt_suspend, NULL);
ui_helpline__init();
ui_browser__init();
--
1.6.2.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.