* Re: [Xenomai-help] configuring user-space xenomai 2.6
From: Patrice Kadionik @ 2011-10-31 13:20 UTC (permalink / raw)
To: xenomai
In-Reply-To: <4EAE9EDE.5030501@domain.hid>
Le 31/10/2011 14:13, Gilles Chanteperdrix a écrit :
Hi,
You have perhaps followed this tutorial for mini2440 (I've worked on
this board in july ;-) ):
http://code.google.com/p/friendlyarm/wiki/Linux_Tutorial
Please try to unset CC and CROSS_COMPILE.
Pat.
> On 10/31/2011 01:52 PM, Łukasz Sacha wrote:
>> This is the line configure generated to test whether compiler works:
>> arm-none-linux-gnueabi-gcc –march=armv4t –mtune=arm920t -o conftest
>> -march=armv4t -march=armv4t conftest.c
>> (notice tripple -march=armv4t)
>>
>> when I execute it it gives me:
>> arm-none-linux-gnueabi-gcc: –march=armv4t: No such file or directory
>> arm-none-linux-gnueabi-gcc: –mtune=arm920t: No such file or directory
>> arm-none-linux-gnueabi-gcc: conftest.c: No such file or directory
>> arm-none-linux-gnueabi-gcc: no input files
>>
>> However with a single -march=armv4t it doesn't work either.
>> luke@domain.hid$
>> arm-none-linux-gnueabi-gcc -march=armv4t –mtune=arm920t -o conftest
>> conftest.c
>> arm-none-linux-gnueabi-gcc: –mtune=arm920t: No such file or directory
>> arm-none-linux-gnueabi-gcc: conftest.c: No such file or directory
>> arm-none-linux-gnueabi-gcc: no input files
>>
>> .. which is strange, because arm-none-linux-gnueabi-gcc --help tells
>> me all the options are ok:
>> "Options starting with -g, -f, -m, -O, -W, or --param are automatically
>> passed on to the various sub-processes invoked by arm-none-linux-gnueabi-gcc."
>>
>> Seems -mtune is not recognized by some subprocess, but which and why?
>>
>> cheers :)
> Strange toolchain. I use codesourcery toolchain and never observed such
> behaviour. You should make sure the toolchain you use works before
> trying and compiling xenomai.
>
--
Patrice Kadionik. F6KQH / F4CUQ
-----------
+----------------------------------------------------------------------+
+"Tout doit etre aussi simple que possible, pas seulement plus simple" +
+----------------------------------------------------------------------+
+ Patrice Kadionik http://www.enseirb-matmeca.fr/~kadionik +
+ IMS Laboratory http://www.ims-bordeaux.fr/ +
+ ENSEIRB-MATMECA http://www.enseirb-matmeca.fr +
+ PO BOX 99 fax : +33 5.56.37.20.23 +
+ 33402 TALENCE Cedex voice : +33 5.56.84.23.47 +
+ FRANCE +
+----------------------------------------------------------------------+
^ permalink raw reply
* Re: Xen dom0 linux kernel 3.1 boot failure ptwr_emulate: could not get_page_from_l1e
From: Tobias Heinlein @ 2011-10-31 13:17 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <05c3da5dc6158197e28d62e853ac2f04@tjhsst.edu>
Hi,
2013pfoley <2013pfoley <at> tjhsst.edu> writes:
> [..]
>
> [ 0.000000] last_pfn = 0x63b5ef max_arch_pfn = 0x400000000
> [ 0.000000] last_pfn = 0xdf62d max_arch_pfn = 0x400000000
> [ 0.000000] found SMP MP-table at [ffff8800000f4f80] f4f80
> (XEN) mm.c:945:d0 Error getting mfn 100 (pfn 5555555555555555) from L1
> entry 8000000000100461 for l1e_owner=0, pg_owner=0
> (XEN) mm.c:5046:d0 ptwr_emulate: could not get_page_from_l1e()
> [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at
> (null)
> [ 0.000000] IP: [<ffffffff81008a5a>] xen_set_pte+0x3a/0x1f0
> [ 0.000000] PGD 0
> [ 0.000000] Oops: 0003 [#1] SMP
> [ 0.000000] CPU 0
> [ 0.000000] Modules linked in:
> [ 0.000000]
> [ 0.000000] Pid: 0, comm: swapper Not tainted 3.1.0 #4 HP ProLiant
> DL380 G6
I get the exact same error here. Reading from your output, it seems we have the
same hardware; I have this problem on a HP ProLiant DL380 G6, too.
After a wild hint from a guy on ##xen to play around with the BIOS settings, I
was able to narrow down the problem to a setting called "MPS Table Mode". It is
set to "Full Table APIC" by default (with which the crash occurs), but when it's
set to "Disabled" Xen boots the kernel just fine.
FWIW, the help text of the setting is: "Multi Processor Specification (MPS)
Table / APIC Setting is used for interrupt routing. Certain unsupported
operating systems may require setting the MPS Table Mode to APIC Disabled."
(BTW, the kernel itself boots fine without Xen. So I'm not sure if this belongs
to the LKML at all.)
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 3/3] piix4 acpi xen support
From: Anthony PERARD @ 2011-10-31 13:18 UTC (permalink / raw)
To: John Baboval; +Cc: xen-devel, Stefano Stabellini, qemu-devel, Ian Campbell
In-Reply-To: <1320064920.23193.79.camel@zakaz.uk.xensource.com>
On Mon, Oct 31, 2011 at 12:41, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> Please CC xen-devel on patches which impact the Xen support in qemu.
>
> On Fri, 2011-10-28 at 15:38 -0400, John Baboval wrote:
>> When in xen mode, handle the view of pm ioport appropriately.
>>
>> I'm not entirely comfortable with this patch, since it relies on values
>> that are hard coded into the DSDT that is shipped with Xen. There has to
>> be a better way to handle it, but I haven't thought of what that might
>> be yet... Perhaps there should be an acpi_xen.c. Or perhaps the Xen
>> table should be modified to match the device model. Or perhaps there is
>> a good way to match them up dynamically.
>
> Anthony Perard posted a patch to xen-devel last week (series entitled
> "hvmloader/DSDT change to handle PCI hotplug with QEMU upstream") which
> makes the Xen ACPI tables compatible with the upstream QEMU PM registers
> etc. I think that covers this issue too?
Actually, Xen unstable should already have the necessary change to
cover everythings in this patch since a while. So QEMU does not need
to be modified.
If something does not work, could you tell me what?
Regards,
--
Anthony PERARD
^ permalink raw reply
* Re: [PATCH 3/3] piix4 acpi xen support
From: Anthony PERARD @ 2011-10-31 13:18 UTC (permalink / raw)
To: John Baboval; +Cc: xen-devel, Stefano Stabellini, qemu-devel, Ian Campbell
In-Reply-To: <1320064920.23193.79.camel@zakaz.uk.xensource.com>
On Mon, Oct 31, 2011 at 12:41, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> Please CC xen-devel on patches which impact the Xen support in qemu.
>
> On Fri, 2011-10-28 at 15:38 -0400, John Baboval wrote:
>> When in xen mode, handle the view of pm ioport appropriately.
>>
>> I'm not entirely comfortable with this patch, since it relies on values
>> that are hard coded into the DSDT that is shipped with Xen. There has to
>> be a better way to handle it, but I haven't thought of what that might
>> be yet... Perhaps there should be an acpi_xen.c. Or perhaps the Xen
>> table should be modified to match the device model. Or perhaps there is
>> a good way to match them up dynamically.
>
> Anthony Perard posted a patch to xen-devel last week (series entitled
> "hvmloader/DSDT change to handle PCI hotplug with QEMU upstream") which
> makes the Xen ACPI tables compatible with the upstream QEMU PM registers
> etc. I think that covers this issue too?
Actually, Xen unstable should already have the necessary change to
cover everythings in this patch since a while. So QEMU does not need
to be modified.
If something does not work, could you tell me what?
Regards,
--
Anthony PERARD
^ permalink raw reply
* [lm-sensors] max1111 doesn't implement the standard sysfs interface
From: Jean Delvare @ 2011-10-31 13:18 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <20111031141642.0ed2ccc1@endymion.delvare>
Hi Eric,
It was pointed to me that the max1111 driver doesn't implement the
standard sysfs interface for hwmon drivers (as described in
Documentation/hwmon/sysfs-interface). It exports files adc[0-3]_in, which
aren't part of the standard interface. Presumably these should be
renamed to in[0-3]_input. Renaming them is probably not sufficient
though, as I see no scaling done in the driver. As the MAX1111 chip has
a documented full scale of 2.048V, I take it that the LSB of the ADC
has a weight of 8 mV. Exporting raw register values to user-space is
not OK.
So I would appreciate a fixup patch quickly. Otherwise we'll have to
remove the max1111 driver completely, so that it doesn't get used as a
(bad) example by other driver authors [1]. I'm sorry I did not spot the
problem when reviewing the driver originally.
[1] http://lists.lm-sensors.org/pipermail/lm-sensors/2011-October/034070.html
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* [U-Boot] Attention:Beneficiary
From: Nokia Uk Promotion @ 2011-10-31 13:17 UTC (permalink / raw)
To: u-boot
Attention:Beneficiary,
Your email address has won you ?750.000 (GBP) in the on-going Nokia Uk
Annual Anniversary 2011.
For cliams send Name Address, Phone Number,via
Email:uknokiamobileprom at live.com
and call +44 7045754954
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: [PATCH 12/13] mtd/docg3: add ECC correction code
From: Mike Dunn @ 2011-10-31 13:16 UTC (permalink / raw)
To: linux-mtd
In-Reply-To: <1319824292-11085-13-git-send-email-robert.jarzmik@free.fr>
Hi Robert,
A few comments (limited to the bch decode for now)...
On 10/28/2011 10:51 AM, Robert Jarzmik wrote:
>
> /**
> + * doc_correct_data - Fix if need be read data from flash
> + * @docg3: the device
> + * @buf: the buffer of read data (512 + 7 + 1 bytes)
> + * @calc_ecc: the hardware calculated ECC
To avoid confusion with the terminology in Ivan's BCH algorithm, I wouldn't call
it calc_ecc. It's actually recv_ecc ^ calc_ecc, where recv_ecc is what the hw
read from the ecc field of the oob data, and calc_ecc is what the hw calculated
from the page data. Maybe just hwecc or similiar.
> + *
> + * Checks if the received data matches the ECC, and if an error is detected,
> + * tries to fix the bit flips (at most 4) in the buffer buf. As the docg3
> + * understands the (data, ecc, syndroms) in an inverted order in comparison to
> + * the BCH library, the function reverses the order of bits (ie. bit7 and bit0,
> + * bit6 and bit 1, ...) for all ECC data.
> + *
> + * Returns number of fixed bits (0, 1, 2, 3, 4) or -EBADMSG if too many bit
> + * errors were detected and cannot be fixed.
> + */
> +static int doc_ecc_bch_fix_data(struct docg3 *docg3, void *buf, u8 *calc_ecc)
> +{
> + u8 ecc[DOC_ECC_BCH_T + 1];
> + int errorpos[DOC_ECC_BCH_T + 1], i, numerrs;
> +
> + for (i = 0; i < DOC_ECC_BCH_SIZE; i++)
> + ecc[i] = bitrev8(calc_ecc[i]);
> + numerrs = decode_bch(docg3_bch, NULL, DOC_ECC_BCH_COVERED_BYTES,
> + NULL, ecc, NULL, errorpos);
This looks right, with the redefined DOC_ECC_BCH_COVERED_BYTES (now 520).
Some commentary would be helpful (though maybe I'm too verbose)...
/*
* The hardware ecc unit produces oob_ecc ^ calc_ecc. The kernel's bch
* algorithm is used to decode this. However the hw operates on page
* data in a bit order that is the reverse of that of the bch alg,
* requiring that the bits be reversed on the result. Thanks to Ivan
* Djelic for his analysis.
*/
I recommend you test this. One way would be to compile the bch algorithm in
userspace and use it to generate the ecc for a 520 byte test vector. Reverse
the bits of this ecc, then flip a few bits in the test vector and write it to a
page in flash, with your driver modified to write the calculated ecc instead of
that served up by the hardware. Then when you read the page, the above code
should identify and correct the bits you flipped (assuming a genuine flash error
did not occur while reading back the page). I have the bch alg modified for
userspace, if that would help.
Alternatively, you could just fill the flash with a fixed pattern, then read all
the pages, waiting for an error to occur so that correct correction (ha) can be
verified.
> + if (numerrs < 0)
> + return numerrs;
I recommend you check for the -EINVAL return value and issue a big fat error.
Maybe BUG_ON(numerrs == -EINVAL), at least for now.
Another explanatory comment here...
/* undo last step in BCH alg (modulo mirroring not needed) */
> +
> + for (i = 0; i < numerrs; i++)
> + errorpos[i] = (errorpos[i] & ~7) | (7 - (errorpos[i] & 7));
> + for (i = 0; i < numerrs; i++)
> + change_bit(errorpos[i], buf);
> +
> + doc_dbg("doc_ecc_bch_fix_data: flipped %d bits\n", numerrs);
> + return numerrs;
> +}
> +
> +
Thanks,
Mike
^ permalink raw reply
* [lm-sensors] max1111 doesn't implement the standard sysfs interface
From: Jean Delvare @ 2011-10-31 13:16 UTC (permalink / raw)
To: lm-sensors
Hi Eric,
It was pointed to me that the max1111 driver doesn't implement the
standard sysfs interface for hwmon drivers (as described in
Documentation/hwmon/sysfs-interface). It exports files adc[0-3]_in, which
aren't part of the standard interface. Presumably these should be
renamed to in[0-3]_input. Renaming them is probably not sufficient
though, as I see no scaling done in the driver. As the MAX1111 chip has
a documented full scale of 2.048V, I take it that the LSB of the ADC
has a weight of 8 mV. Exporting raw register values to user-space is
not OK.
So I would appreciate a fixup patch quickly. Otherwise we'll have to
remove the max1111 driver completely, so that it doesn't get used as a
(bad) example by other driver authors [1]. I'm sorry I did not spot the
problem when reviewing the driver originally.
[1] http://lists.lm-sensors.org/pipermail/lm-sensors/2011-October/034070.html
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: [PATCH 5/7] ath6kl: Invoke wow suspend/resume calls during PM operations
From: Kalle Valo @ 2011-10-31 13:16 UTC (permalink / raw)
To: Raja Mani; +Cc: linux-wireless
In-Reply-To: <4EAE7038.7010306@qca.qualcomm.com>
On 10/31/2011 11:54 AM, Raja Mani wrote:
> On Friday 28 October 2011 06:45 PM, Kalle Valo wrote:
>> On 10/25/2011 01:37 PM, rmani@qca.qualcomm.com wrote:
>>> From: Raja Mani<rmani@qca.qualcomm.com>
>>>
>>> --- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
>>> +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
>>> @@ -1606,6 +1606,19 @@ static int ar6k_cfg80211_suspend(struct wiphy *wiphy,
>>> struct cfg80211_wowlan *wow)
>>> {
>>> struct ath6kl *ar = wiphy_priv(wiphy);
>>> + int ret;
>>> +
>>> + if (wow&& ath6kl_cfg80211_ready(ar)&&
>>> + test_bit(CONNECTED,&ar->flag)&&
>>> + ath6kl_hif_keep_pwr_caps(ar)) {
>>> +
>>> + /* Flush all non control pkts in Tx path */
>>> + ath6kl_tx_data_cleanup(ar);
>>> +
>>> + ret = ath6kl_pm_wow_suspend(ar, wow);
>>> + if (ret)
>>> + return ret;
>>> + }
>>
>> This is now confusing. Some of the suspend logic is now in sdio.c and
>> some here. It's better to have everything in one place, that is in
>> sdio.c. We just need to add an interface so that sdio.c can request the
>> correct suspend mode.
>
> Do you want me to keep ath6kl_pm_wow_suspend() implementation in
> cfg80211.c file and move only above code to ath6kl_sdio_suspend() ?
I gave this more thought and in my suspend patches earlier today I added
this function:
int ath6kl_cfg80211_suspend(struct ath6kl *ar,
enum ath6kl_cfg_suspend_mode mode)
{
int ret;
ath6kl_cfg80211_stop(ar);
switch (mode) {
case ATH6KL_CFG_SUSPEND_DEEPSLEEP:
/* save the current power mode before enabling power save */
ar->wmi->saved_pwr_mode = ar->wmi->pwr_mode;
ret = ath6kl_wmi_powermode_cmd(ar->wmi, 0, REC_POWER);
if (ret) {
ath6kl_warn("wmi powermode command failed during suspend: %d\n",
ret);
}
ar->state = ATH6KL_STATE_DEEPSLEEP;
break;
You can add a new mode for WOW and call your wow functions from that
function. And you need to make changes to ath6kl_sdio_suspend() so that
it will enable WOW in correct cases. Also I added a state variable
ar->state and hopefully we don't need a separate wow state anymore.
Kalle
^ permalink raw reply
* config ARCH_AT91SAM9X5
From: Marc Kleine-Budde @ 2011-10-31 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1320062362.14409.58.camel@x61.thuisdomein>
On 10/31/2011 12:59 PM, Paul Bolle wrote:
> 0) Since the commits
> 9baeb7e4 ("at91: Add ARCH_ID and basic cpu macros [...]"),
> b9e379bc ("net/can: allow CAN_AT91 on AT91SAM9X5"), and
> 8c3583b6 ("at91: use structure to store the current soc")
>
> the mainline kernel tree uses the Kconfig symbol ARCH_AT91SAM9X5 and the
> preprocessor macro CONFIG_ARCH_AT91SAM9X5.
>
> 1) But there's currently no Kconfig entry ARCH_AT91SAM9X5. (Neither is
> there a direct definition of the macro CONFIG_ARCH_AT91SAM9X5.)
> Shouldn't a Kconfig entry for ARCH_AT91SAM9X5 be added (to
> arch/arm/mach-at91/Kconfig)?
Talking for the at91_can driver (which has been done by me):
The driver and Kconfig have been prepared for the upcoming 5series AT91
SOCs.
Basically the same applies to the commit 9baeb7e4 ("at91: Add ARCH_ID
and basic cpu macros [...]").
But the 5series hasn't bee merged yet. Nicolas and Jean-Christophe can
probably tell you more.
regards, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111031/7e70a2cc/attachment.sig>
^ permalink raw reply
* [PATCH] Remove unnecessary casting in thermometer plugin
From: Santiago Carot-Nemesio @ 2011-10-31 13:16 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Santiago Carot-Nemesio
---
thermometer/thermometer.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/thermometer/thermometer.c b/thermometer/thermometer.c
index 0d85102..8f0a5ea 100644
--- a/thermometer/thermometer.c
+++ b/thermometer/thermometer.c
@@ -200,7 +200,7 @@ static void read_interval_cb(guint8 status, const guint8 *pdu, guint16 len,
{
struct characteristic *ch = user_data;
uint8_t value[ATT_MAX_MTU];
- uint16_t *p, interval;
+ uint16_t interval;
int vlen;
if (status != 0) {
@@ -219,9 +219,7 @@ static void read_interval_cb(guint8 status, const guint8 *pdu, guint16 len,
return;
}
- p = (uint16_t *) value;
- interval = btohs(bt_get_unaligned(p));
-
+ interval = att_get_u16(&value[0]);
change_property(ch->t, "Interval", &interval);
}
--
1.7.7.1
^ permalink raw reply related
* [Bug 41592] [Radeon] The display often freezes with gnome-shell 3.2
From: bugzilla-daemon @ 2011-10-31 13:14 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-41592-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=41592
Nicolas Peninguy <npeninguy@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |npeninguy@gmail.com
--- Comment #15 from Nicolas Peninguy <npeninguy@gmail.com> 2011-10-31 06:14:45 PDT ---
May be this is related to https://bugzilla.gnome.org/show_bug.cgi?id=650857 ?
(But Intel and NVidia owners are also affected)
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [U-Boot] [PATCH 1/5] arm/km: adapt bootcounter evaluation
From: Holger Brunck @ 2011-10-31 13:14 UTC (permalink / raw)
To: u-boot
In-Reply-To: <F766E4F80769BD478052FB6533FA745D1A14DD884F@SC-VEXCH4.marvell.com>
Hi Prafulla,
On 10/31/2011 09:48 AM, Prafulla Wadaskar wrote:
>> Anyway Wolfgang or Albert, who should pick up the patches for
>> our Keymile
>> Kirkwood boards?
>>
>> This two series have only board specific patches:
>> http://lists.denx.de/pipermail/u-boot/2011-
>> September/101328.html
>> http://lists.denx.de/pipermail/u-boot/2011-
>> September/102534.html
>
> Applied both these patches to u-boot-marvell.git master branch
>
please pull the two patch series, not only these two patches which are the first
patches of the two series. All in all it consists of seven patches.
Thanks.
Regards
Holger
^ permalink raw reply
* Re: [Xenomai-help] configuring user-space xenomai 2.6
From: Gilles Chanteperdrix @ 2011-10-31 13:13 UTC (permalink / raw)
To: Łukasz Sacha; +Cc: xenomai
In-Reply-To: <CAAeYjMn83FgbqTZRB7E_S4FHP11V-tzdP1eNcY6+n2DJ2SmrGw@domain.hid>
On 10/31/2011 01:52 PM, Łukasz Sacha wrote:
> This is the line configure generated to test whether compiler works:
> arm-none-linux-gnueabi-gcc –march=armv4t –mtune=arm920t -o conftest
> -march=armv4t -march=armv4t conftest.c
> (notice tripple -march=armv4t)
>
> when I execute it it gives me:
> arm-none-linux-gnueabi-gcc: –march=armv4t: No such file or directory
> arm-none-linux-gnueabi-gcc: –mtune=arm920t: No such file or directory
> arm-none-linux-gnueabi-gcc: conftest.c: No such file or directory
> arm-none-linux-gnueabi-gcc: no input files
>
> However with a single -march=armv4t it doesn't work either.
> luke@domain.hid$
> arm-none-linux-gnueabi-gcc -march=armv4t –mtune=arm920t -o conftest
> conftest.c
> arm-none-linux-gnueabi-gcc: –mtune=arm920t: No such file or directory
> arm-none-linux-gnueabi-gcc: conftest.c: No such file or directory
> arm-none-linux-gnueabi-gcc: no input files
>
> .. which is strange, because arm-none-linux-gnueabi-gcc --help tells
> me all the options are ok:
> "Options starting with -g, -f, -m, -O, -W, or --param are automatically
> passed on to the various sub-processes invoked by arm-none-linux-gnueabi-gcc."
>
> Seems -mtune is not recognized by some subprocess, but which and why?
>
> cheers :)
Strange toolchain. I use codesourcery toolchain and never observed such
behaviour. You should make sure the toolchain you use works before
trying and compiling xenomai.
--
Gilles.
^ permalink raw reply
* Re: [Qemu-devel] GSoC mentor summit QEMU users session
From: Peter Maydell @ 2011-10-31 13:12 UTC (permalink / raw)
To: Alexander Graf; +Cc: qemu-devel@nongnu.org Developers
In-Reply-To: <4639B135-B96A-43A0-B4FA-6DDCBE3FBA92@suse.de>
On 29 October 2011 14:52, Alexander Graf <agraf@suse.de> wrote:
> We should also show people unmaintained areas. The conclusion was a wiki
> page with subsystems and status so people know what to expect. Maybe we
> could generate this from the MAINTAINERS file?
Sounds like a good idea, although I think we might need to expand
MAINTAINERS a bit -- I get the impression that there are a lot of
"little bits" that fall into the gaps between the top-level areas
marked out in MAINTAINERS.
> Also, an easy way of counterfighting the feeling ignored part is
> to tell people that they just hit an unmaintained area. There's
> nothing more frustrating than sending a patch and get no reply.
> Receiving a reply "Sorry, this area is unmaintained. Please find
> someone to review it." would already be enough for most people.
The difficulty that strikes me with this is that I'm not sure any
one person can reliably look at a patch and say "that's for an
unmaintained area" (at least, I know what areas I can review but
I have no idea about everybody else...) So you can only really
tell by default, ie if the patch sits for a few weeks without
any reply...
> A lot of people seem to also have code that doesn't make sense
> upstream, for example implementing a one-off device that only
> really matters for their own devboard which nobody else owns.
> For such cases, having a plugin framework would be handy. I
> interestingly enough got into the same discussion on LinuxCon
> with some QEMU downstreams.
If we get the qdev rework done then I think we're probably in
a better position to have a plugin framework for devices. (There
are some issues about API and ABI stability guarantees, of course.)
-- PMM
^ permalink raw reply
* Re: [PATCH] echo: fix octal escaping with \1...\7
From: Eric Blake @ 2011-10-31 13:12 UTC (permalink / raw)
To: Mike Frysinger; +Cc: Herbert Xu, dash, bug-libtool
In-Reply-To: <201110310023.45138.vapier@gentoo.org>
[adding bug-libtool]
On 10/30/2011 10:23 PM, Mike Frysinger wrote:
> On Sunday 30 October 2011 23:41:58 Herbert Xu wrote:
>> Mike Frysinger wrote:
>>> POSIX states that octal escape sequences should take the form \0num
>>> when using echo. dash however additionally treats \num as an octal
>>> sequence. This breaks some packages (like libtool) who attempt to
>>> use strings with these escape sequences via variables to execute sed
>>> (since sed ends up getting passed a byte instead of a literal \1).
That's a bug in libtool for using "echo '\1'" and expecting sane
behavior. Can you provide more details on this libtool bug, so we can
get it fixed in libtool? Or perhaps it has already been fixed in modern
libtool, and you are just encountering it in an older version?
>>
>> OK this is a bit of problem. From our conversation I had the
>> impression that you were referring to the lack of support of
>> escape codes, rather than unwanted support.
>>
>> If it was the former I could easily add it if POSIX said so,
>> however, as this is an existing feature there may well be scripts
>> out there that depend on it. So removing it is not an option
>> unless it is explicitly forbidden by POSIX.
>
> i'm not seeing how this jives with dash's goal. if it intends to be a
> fast/small POSIX compliant shell while punting (almost) all the rest, then why
> carry additional functionality that POSIX doesn't even mention in passing ?
> this isn't "documented but optional extended functionality", but rather the
> realm of "anything goes". otherwise we approach the same realm that dash was
> created to avoid -- carrying lots of cruft that slow things down because
> scripts use it rather than POSIX mandating it.
>
> as a comparison, bash/ksh/tcsh/zsh/busybox[ash] all behave the way my patch
> updates dash to operate ... i would test more shells, but these tend to be the
> standards that everyone compares against. i can't see people writing scripts
> that only work under dash either.
>
>> In any case, scripts that rely on escape codes like this are
>> simply broken and should either be fixed to use printf or just
>> run with #!/bin/bash.
>
> they're relying on these escape codes not being interpreted as escape codes
> (which every other shell appears to do), not the other way around
Scripts that rely on a certain interpretation of "echo '\1'" are broken
regardless of how dash behaves; but that said, since POSIX doesn't
require dash's current behavior, and since the proposed patch makes dash
both smaller and more like other shells in treating it as an extension
that means a literal 1 rather than an octal escape, I would be in favor
of making the change in dash.
--
Eric Blake eblake@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
^ permalink raw reply
* Re: [lm-sensors] [RFC][PATCH] hwmon: add support for MCP3204/3208
From: Jean Delvare @ 2011-10-31 13:11 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <201110311247.p9VClrVx017871@home.pavel.comp>
Hi Paul,
On Mon, 31 Oct 2011 17:04:33 +0400, Paul Fertser wrote:
> On Mon, Oct 31, 2011 at 01:54:33PM +0100, Jean Delvare wrote:
> > > but at least the max1111 uses the former. Waiting for your feedback.
> >
> > Thanks for pointing this out. I don't know how it managed to sneak in,
> > but it shouldn't have. I'll ask the driver author to align with the
> > standard interface quickly, otherwise we'll have to delete the driver
> > altogether.
>
> What do you propose to use for raw ADC data then? How should i
> proceed?
Raw ADC data isn't supposed to be exported by hardware monitoring
drivers in the first place. If you need to do this, then hwmon is the
wrong place. Look at iio instead, maybe it allows this (not even sure).
hwmon drivers expose voltage values to user-space in mV, always. If the
LSB weight depends on the platform somehow, you may be able to pass it
as platform data to the I2C slave device, so that the driver can scale
properly.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: [PATCH 2/7] ath6kl: Add wmi functions to configure wow mode and host sleep mode
From: Kalle Valo @ 2011-10-31 13:10 UTC (permalink / raw)
To: Raja Mani; +Cc: linux-wireless
In-Reply-To: <4EAE6FFD.6090403@qca.qualcomm.com>
On 10/31/2011 11:53 AM, Raja Mani wrote:
>>> +static void ath6kl_wmi_relinquish_implicit_pstream_credits(struct wmi *wmi)
>>> >> +{
>>> >> + u16 active_tsids;
>>> >> + u8 stream_exist;
>>> >> + int i;
>>> >> +
>>> >> + /*
>>> >> + * Relinquish credits from all implicitly created pstreams
>>> >> + * since when we go to sleep. If user created explicit
>>> >> + * thinstreams exists with in a fatpipe leave them intact
>>> >> + * for the user to delete.
>>> >> + */
>>> >> + spin_lock_bh(&wmi->lock);
>>> >> + stream_exist = wmi->fat_pipe_exist;
>>> >> + spin_unlock_bh(&wmi->lock);
>>> >> +
>>> >> + for (i = 0; i< WMM_NUM_AC; i++) {
>>> >> + if (stream_exist& (1<< i)) {
>>> >> +
>>> >> + spin_lock_bh(&wmi->lock);
>>> >> + active_tsids = wmi->stream_exist_for_ac[i];
>>> >> + spin_unlock_bh(&wmi->lock);
>>> >> +
>>> >> + /*
>>> >> + * If there are no user created thin streams
>>> >> + * delete the fatpipe
>>> >> + */
>>> >> + if (!active_tsids) {
>>> >> + stream_exist&= ~(1<< i);
>>> >> + /*
>>> >> + * Indicate inactivity to driver layer for
>>> >> + * this fatpipe (pstream)
>>> >> + */
>>> >> + ath6kl_indicate_tx_activity(wmi->parent_dev,
>>> >> + i, false);
>>> >> + }
>>> >> + }
>>> >> + }
>>> >> +
>>> >> + spin_lock_bh(&wmi->lock);
>>> >> + wmi->fat_pipe_exist = stream_exist;
>>> >> + spin_unlock_bh(&wmi->lock);
>> >
>> > The locking here doesn't really make sense. For example, any changes to
>> > wmi->fat_pipe_exist during the for loop will be overwritten. Also lock
>> > handling with wmi->stream_exist_for_ac[i] looks fishy.
>
> Is it fine just removal of both locking (For "active_tsids =
> wmi->stream_exist_for_ac[i]" and "wmi->fat_pipe_exist = stream_exist") ?
>
> I am sure about the impact..Could you please give some point how above
> locking can be improved ?
I haven't reviewed the locking in detail so it's difficult to say. For
example, you could hold the lock the entire duration of for loop. But
that might create deadlocks. Another option is take it into account the
changes happening to fat_pipe_exist while lock is not held.
Kalle
^ permalink raw reply
* Re: [Xenomai-help] Interruption of sata hard driver's during real-time task running
From: Gilles Chanteperdrix @ 2011-10-31 13:10 UTC (permalink / raw)
To: Donggu Kang; +Cc: Xenomai help
In-Reply-To: <CAAtf-FdauMEM4s7xUNjm7GKEvUE6di5f=h-yU9Qxbwh1Y5yPZw@domain.hid>
On 10/31/2011 12:39 PM, Donggu Kang wrote:
> Dear Gilles
>
> I re-made xenomai task that use etherlab kernel module.
> Xenomai task is working as kernel module.
>
> As your comment, when I call the etherlab api, the mode of real-time
> task is changed to secondary mode.
> And the real-time task could be interrupted by linux irq. right?
>
> but, In "Xenomai's primary and secondary domains" section of "Life
> With Adeos" says, xenomai have interrupt shield function.
> So, if I turn on the interrupt shield option, latency could be more reduced.
>
> Is it collect ?
The interrupt shield no longer exists. If you want a task to meet its
deadlines, it should remain in primary mode.
Please do not send private mails.
--
Gilles.
^ permalink raw reply
* Re: wl1251 and NoA protocol
From: Luciano Coelho @ 2011-10-31 13:10 UTC (permalink / raw)
To: Andrés García Saavedra; +Cc: linux-wireless
In-Reply-To: <CADxqDgEvsObWbnPTViPF5g_TOS2WRJoJK4OnEzehbdQwwgzNDQ@mail.gmail.com>
On Tue, 2011-10-18 at 11:13 +0200, Andrés García Saavedra wrote:
> Hi all,
>
> I would like to test Notice of Absence powersaving protocol for
> 802.11abg WLANs on some current android smartphone. My question is
> regarding the wl1251 driver implementation for TI chipsets:
>
> * Does the chipset/current implementation support sleep/awake
> triggers? (or at least quiet elements?) -> This means, can I command
> the NIC to stay quiet (slept) for certain duration of time?
>
> My plan is to implement/test a Notice of Absence protocol where the
> driver would trigger absent (quiet/sleep) periods according to the
> beacon's NoA IE. Ive seen in the code the wl1251_ps_elp_sleep/wakeup
> functions that might be reused for this purpose (?)
>
> * Last (lazy) question. AFAIK only the google dev 1 phone uses this
> chipset. Is there any 1ghz android device that could benefit of this
> driver?
You should look for a device with some newer chip, like the wl1271, for
instance. We are currently developing the wl12xx driver (for wl127x and
wl128x) a lot more actively than wl1251. Besides, I don't think there's
any newer Android phone using wl1251...
--
Cheers,
Luca.
^ permalink raw reply
* Re: NFS4ERR_STALE_CLIENTID loop
From: Chuck Lever @ 2011-10-31 13:07 UTC (permalink / raw)
To: David Flynn; +Cc: Myklebust, Trond, J. Bruce Fields, linux-nfs
In-Reply-To: <20111029195249.GE2011@rd.bbc.co.uk>
On Oct 29, 2011, at 3:52 PM, David Flynn wrote:
> * Myklebust, Trond (Trond.Myklebust@netapp.com) wrote:
>>> -----Original Message-----
>>> From: Chuck Lever [mailto:chuck.lever@oracle.com]
>>> On Oct 29, 2011, at 2:47 PM, J. Bruce Fields wrote:
>>>> Yes, and it's not something I care that strongly about, really, my
>>>> only observation is that this sort of failure (an implementation
>>>> bug on one side or another resulting in a loop) seems to have been
>>>> common (based on no hard data, just my vague memories of list
>>>> threads), and the results fairly obnoxious (possibly even for
>>>> unrelated hosts on the network).
>>>> So if there's some simple way to fail more gracefully it might be
>>>> helpful.
>>>
>>> For what it's worth, I agree that client implementations should
>>> attempt to behave more gracefully in the face of server problems, be
>>> they the result of bugs or the result of other issues specific to
>>> that server. Problems like this make NFSv4 as a protocol look bad.
>>
>> I can't see what a client can do in this situation except possibly just
>> give up after a while and throw a SERVER_BROKEN error (which means data
>> loss). That still won't make NFSv4 look good...
>
> Indeed, it is a quite the dilemma.
>
> I agree that giving and guaranteeing unattended data loss is bad (data
> loss at the behest of an operator is ok, afterall they can always fence
> a broken machine).
David, what would help immensely is if you can find a reliable way of reproducing this. So far we have been unable to find a reproducer.
> Looking at some of the logs again, even going back to the very original
> case, it appears to be about 600us between retries (RTT=400us). Is
> there any way to make that less aggressive?, eg 1s? -- that'd reduce the
> impact by three orders of magnitude. What would be the down-side? How
> often do you expect to get a BAD_STATEID error?
>
> ..david
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply
* Re: CPU hyperthreading turned on after soft power-cycle
From: Clarinet @ 2011-10-31 13:06 UTC (permalink / raw)
To: Ben Hutchings; +Cc: 647095, LKML
In-Reply-To: <1319988329.6759.88.camel@deadeye>
On 10/30/2011 4:25 PM, Ben Hutchings wrote:
> On Sun, 2011-10-30 at 07:05 -0400, Jiri Polach wrote:
>> Package: linux-2.6
>> Version: 2.6.39-3~bpo60+1
>> Severity: normal
>>
>>
>> When the computer is turned off using "shutdown -h" or "halt" command,
>> the hypertherading BIOS setting is changed - even if hypertherading is
>> disabled in BIOS, the kernel detects twice as many "processors" on
>> next boot as if hyperthreading was enabled. Please see details below.
>>
>> I have observed the problem on several Supermicro platforms with
>> various Intel Xeon processors. The particular case I report was
>> observed on Supermicro X8DTT-F mainboard with two Intel Xeon E5645
>> processors (6core). The problem can be reproduced the following way:
>
> By my understanding of how hyperthreading is controlled, this has to be
> a BIOS bug, as you seem to have suspected. But if the BIOS behaviour is
> kernel version-dependent, then presumably there is something the kernel
> can do to work around it.
Yes, there are reasons that support my suspicion that BIOS is not doing
its work properly. But I cannot prove it until it is clear what has been
changed in the kernel.
>> 1. Turn on the computer, go to BIOS setup and turn "Simultaneous
>> multithreading" to "Disabled". Boot Debian.
>>
>> 2. Check with "cat /proc/cpuinfo" that the system reports 12 CPUs (2 x
>> six-core processor).
>>
>> 3. (optionally) Reboot the system (shutdown -r) and check that there
>> are still 12 CPUs detected and reported.
>>
>> 4. Halt the system using "shutdown -h" or "halt", turn it on again,
>> and boot Debian.
>
> I assume from this that shutdown -h is configured to turn the system
> off.
I do not know. I have been using mostly "halt" to shutdown the system
and turn the server off and I tried "shutdown -h" only several times to
see if there is any difference. Both commands have turned the computer
off, but I did not do any special "shutdown -h" configuration.
>> 5. Check the number of CPUs reported - it will show you that there are
>> 24 CPUs as if hyperthreading was enabled.
>>
>> 6. Reboot and go to BIOS setup - it still shows that "Simultaneous
>> multithreading" is set to "Disabled". Do not change anythig, just
>> select "Save and Exit". Boot Debian and check the number of CPUs - it
>> now shows 12 CPUs again.
>>
>> I have tested several kernel versions and it seems that this behavior
>> appeared for the first time somewhere between 2.6.35.7 and 2.6.38.6
>> versions (ok = does not show the decribed behavior, not ok = does
>> show):
>>
>> * linux-image-2.6.32-5-amd64 official Debian - ok
>> * linux-image-2.6.39-bpo.2-amd64 official Debian from backports - not
>> ok
>>
>> * linux 2.6.35.7 - custom compiled from source - ok
>> * linux 2.6.38.6 - custom compiled from source - not ok
>> * linux 2.6.39.4 - custom compiled from source - not ok
>> * linux 3.0.4 - custom compiled from source - not ok
>
> That might be too large a range for developers to consider. Can you
> test some versions between 2.6.35.7 and 2.6.38.6 (bisection)?
OK, after another day of testing it seems that the problem appears in
2.6.38.1, because
* linux 2.6.37.6 - custom compiled from source - ok
* linux 2.6.38.1 - custom compiled from source - not ok
Best regards,
Jiri Polach
> Ben.
>
>> I have exchnged many e-mails with Supermicro distributor who
>> apparently is in direct contact with Supermicro technicians. They more
>> or less deny any responsibility for this problem and repeatedly point
>> to the fact that some (older) kernels do not exhibit this behavior so
>> it must be a kernel problem. Their representative writes:
>>
>> "I discussed this with supermicro and they informed me that the Kernel
>> itself is causing the issue, that it may be sending the hyperthreading
>> command code to the BIOS."
>>
>> Although I do not completely agree with their arguments, my knowledge
>> is not deep enough to recognize where exactly the core of the problem
>> is so I report this as a bug in a hope that someone will know what
>> happens when a kernel turns a computer off and what has changed in
>> kernel somewhere between the versions I mention above. I have asked
>> Supermicro distributor for more information on what they think happens
>> there and what exactly they mean by "hyperhreading command code" and I
>> am waiting for their response.
>>
>> -- Package-specific info:
>> ** Version:
>> Linux version 2.6.39-bpo.2-amd64 (Debian 2.6.39-3~bpo60+1) (norbert@tretkowski.de) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 SMP Tue Jul 26 10:35:23 UTC 2011
> [...]
>> ** Model information
>> sys_vendor: Supermicro
>> product_name: X8DTT
>> product_version: 1234567890
>> chassis_vendor: Supermicro
>> chassis_version: 1234567890
>> bios_vendor: American Megatrends Inc.
>> bios_version: 080016
>> board_vendor: Supermicro
>> board_name: X8DTT
>> board_version: 2.0
> [...]
^ permalink raw reply
* [PATCH V2 1/2] ahci_platform: use dev_get_platdata()
From: JiSheng Zhang @ 2011-10-31 13:20 UTC (permalink / raw)
To: jgarzik; +Cc: linux-ide, avorontsov, linux-pm, linux-kernel
Use dev_get_platdata() to retrieve the struct ahci_platform_data data
from the platform.
Signed-off-by: JiSheng Zhang <jszhang3@gmail.com>
---
drivers/ata/ahci_platform.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index c03277d..45edba9 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -65,7 +65,7 @@ static struct scsi_host_template ahci_platform_sht = {
static int __init ahci_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct ahci_platform_data *pdata = dev->platform_data;
+ struct ahci_platform_data *pdata = dev_get_platdata(dev);
const struct platform_device_id *id = platform_get_device_id(pdev);
struct ata_port_info pi = ahci_port_info[id->driver_data];
const struct ata_port_info *ppi[] = { &pi, NULL };
@@ -191,7 +191,7 @@ err0:
static int __devexit ahci_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct ahci_platform_data *pdata = dev->platform_data;
+ struct ahci_platform_data *pdata = dev_get_platdata(dev);
struct ata_host *host = dev_get_drvdata(dev);
ata_host_detach(host);
--
1.7.6.3
^ permalink raw reply related
* Re: No line out on latest Mac Mini
From: John Frankish @ 2011-10-31 13:05 UTC (permalink / raw)
To: alsa-devel@alsa-project.org; +Cc: kapouer@melix.org
In-Reply-To: <4EA2E18D.2040505@melix.org>
> On 22/10/2011 16:01, John Frankish wrote:
> >> Hi,
> >> i have an imac 12,2 (2011) and i had to change GPIO with hda_analyzer
> >> to get some sound on line out.
> >>
> >> Jérémy.
> >
> > Thanks - I see something like this with hda_analyser:
> >
> > Global Input Amplifier Caps-> <- Global Output Amplifier Caps
> >
> > GPIO
> > out-dir enable unsol sticky wake data [0]
> > [1] x x [x]
> > [2]
> > [3] x x x
> >
> > ..where [1] data enables/disables line out and [3] data enables/disables the
> internal speaker.
> > [1] data was not checked and doing so got things working - a big thank you
> for this.
> >
> > Line out continues to work after closing hda_analyser, but do you know
> > what it actually changes so I Can make it permanent across reboots?
>
> A patch that applies to recent kernels :
> https://gist.github.com/1306112
>
> The pincfg won't probably apply for you -- but it show how you can hack
> something.
>
Thanks - I had a go at making a patch, but couldn't get things to work.
Is there a howto anywhere?
Otherwise, I guess I'll have to wait for a later version of alsa...
^ permalink raw reply
* Re: [MIPS]clocks_calc_mult_shift() may gen a too big mult value
From: John Stultz @ 2011-10-31 13:03 UTC (permalink / raw)
To: Chen Jie
Cc: Yong Zhang, linux-mips, LKML, tglx, yanhua, 项宇,
zhangfx, 孙海勇
In-Reply-To: <CAGXxSxUHGN99hXK8K5k9ayVfMenAWAbWVpqkotix_JyUbPCU+w@mail.gmail.com>
On Mon, 2011-10-31 at 18:48 +0800, Chen Jie wrote:
> Hi,
>
> 2011/10/31 Yong Zhang <yong.zhang0@gmail.com>:
> > On Mon, Oct 31, 2011 at 5:00 PM, Chen Jie <chenj@lemote.com> wrote:
> >> Hi all,
> >>
> >> On MIPS, with maxsec=4, clocks_calc_mult_shift() may generate a very
> >> big mult, which may easily cause timekeeper.mult overflow within
> >> timekeeping jobs.
> >
> > Hmmm, why not use clocksource_register_hz()/clocksource_register_khz()
> > instead? it's more convenient.
>
> Thanks for the suggestion. And sorry for I didn't notice the upstream
> code has already hooked to clocksource_register_hz() in csrc-r4k.c
> (We're using r4000 clock source)
>
> I'm afraid this still doesn't fix my case. Through
> clocksource_register_hz()->__clocksource_register_scale()->__clocksource_updatefreq_scale,
> I got a calculated maxsec = (0xffffffff - (0xffffffff>>5))/250000500 =
> 16 # assume mips_hpt_frequency=250000500
>
> With this maxsec, I got a mult of 0xffffde72, still too big.
Hrmm. Yong Zang is right to suggest clocksource_register_hz(), as the
intention of that code is to try to avoid these sorts of issues.
What is the corresponding shift value you're getting for the value
above?
Could you annotate clocks_calc_mult_shift() a little bit to see where
things might be going wrong?
thanks
-john
^ 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.