* Re: update fi-dna initial tuning file
From: Christoph Pfister @ 2011-04-10 18:24 UTC (permalink / raw)
To: Antti Palosaari; +Cc: linux-media@vger.kernel.org
In-Reply-To: <4D9F6341.9020107@iki.fi>
2011/4/8 Antti Palosaari <crope@iki.fi>:
> Moikka Christoph,
>
> Merge attached patch.
Updated, thanks.
> Antti
> --
> http://palosaari.fi/
Christoph
^ permalink raw reply
* Re: [PATCH] [v2] Nios2: Add Altera TSE MAC driver
From: Franck JULLIEN @ 2011-04-10 18:21 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD; +Cc: barebox
In-Reply-To: <20110410105159.GA18343@game.jcrosoft.org>
[-- Attachment #1.1: Type: text/plain, Size: 3188 bytes --]
2011/4/10 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> > > index 0000000..2687377
> > > --- /dev/null
> > > +
> > > +static int tse_get_ethaddr(struct eth_device *edev, unsigned char
> *m)
> > > +{
> > > + /* There is no eeprom */
> > so return the content of the register no?
> >
> > Well, the register is reseted to 0 when the MAC starts so there is no
> > Ethernet address
> > to get.
> >
> except this function is supposed to return the mac address of the device at
> any time so after a set of it it will not be true any more
>
If I implement the function I get a "eth@eth0: got MAC address from EEPROM:
00:00:00:00:00:00" at startup.
That why I returned -1 as what I could find int at91_ether.c......
Or, I could find something to return -1 as long as the MAC address hasn't
been set.
> >
> > > + return -1;
> > > +}
> > > +
> > > +static int tse_eth_send(struct eth_device *edev, void *packet,
> int
> > length)
> > > +{
> > > +
> > > + struct altera_tse_priv *priv = edev->priv;
> > > + struct alt_sgdma_registers *tx_sgdma = priv->sgdma_tx;
> > > + struct alt_sgdma_descriptor *tx_desc = (struct
> > alt_sgdma_descriptor *)priv->tx_desc;
> > > +
> > > + struct alt_sgdma_descriptor *tx_desc_cur = (struct
> > alt_sgdma_descriptor *)&tx_desc[0];
> > > +
> > > + flush_dcache_range((uint32_t)packet, (uint32_t)packet +
> length);
> > > + alt_sgdma_construct_descriptor_burst(
> > > + (struct alt_sgdma_descriptor *)&tx_desc[0],
> > > + (struct alt_sgdma_descriptor *)&tx_desc[1],
> > > + (uint32_t *)packet, /* read addr */
> > > + (uint32_t *)0, /* */
> > > + length, /* length or EOP ,will change
> for
> > each tx */
> > > + 0x1, /* gen eop */
> > > + 0x0, /* read fixed */
> > > + 0x1, /* write fixed or sop */
> > > + 0x0, /* read burst */
> > > + 0x0, /* write burst */
> > > + 0x0 /* channel */
> > please use tab for indent I see other in the patch please check
> >
> > I use tab for indent, spaces for alignment. I checked the patch with
> > checkpatch and it
> > didn't find errors.....
> try to use tab when u can even for alignment please
>
OK........
> >
> >
> > > +
> > why this?
> >
> > Because sometimes (often ?), hardware doesn't run first time. So I
> like to
> > have some information on MII bus running correctly....One day I had a
> PHY
> > getting the address 1 and sometimes this f***ing PHY got 31 and this
> > kind of auto scan helped me to immediately find the problem......
> > I could remove those function if it is a problem....
> so it's no the right place as it's phy specific and not ehtern drivers
> specific
>
We could put this in the MII code ? Or should I simply remove it ?
>
> Best Regards,
> J.
>
[-- Attachment #1.2: Type: text/html, Size: 4528 bytes --]
[-- Attachment #2: Type: text/plain, Size: 149 bytes --]
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: ipset-6.2 testsuite failure
From: Jozsef Kadlecsik @ 2011-04-10 18:18 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Netfilter Developer Mailing List
In-Reply-To: <alpine.LNX.2.01.1104101937470.549@obet.zrqbmnf.qr>
On Sun, 10 Apr 2011, Jan Engelhardt wrote:
> On Thursday 2011-04-07 21:10, Jozsef Kadlecsik wrote:
> >On Thu, 7 Apr 2011, Jan Engelhardt wrote:
> >
> >> Using 2.6.39-rc1+ (kaber/nf-next) with ipset-6.2 (plain, nfnetlink):
> >>
> >> jng-0:/home/jengelh/code/ipset/tests # ./runtest.sh
> >> hash:ip6: Network: Check listing: passed
> >> hash:ip6: Sleep 5s so that elements can time out: passed
> >> hash:ip6: Network: List set: passed
> >> hash:ip6: Network: Check listing: 6a7
> >> > 200:100:10:: timeout 0
> >> FAILED
> >> Failed test: diff -I 'Size in memory.*' .foo hash:ip6.t.list1 && rm .foo
> >> jng-0:/home/jengelh/code/ipset/tests #
> >
> >I was unable to reproduce this with the kernel from Patrick's tree and
> >with ipset-6.2.
> >
> >However, in the testsuite of ipset-6.2 the hash:ip6 tests are not executed
> >just after the ipmap tests: there are missing tests in the listing above.
> >
> >Also, the testsuite in ipset-6.2 contains the tests against the kernel in
> >the package itself: the patches I have submitted today are missing from
> >2.6.39-rc1+
>
> Tried with ipset 6.3 and modules from ipset-6.3, and seems to work.
Thanks! The kernel is a little bit behind the package.
I could add some conditions to the testsuite to check versions
specifically, but that'd need patchlevel reporting from kernel and set
match/target extension versioning in iptables. And that seems a too high
burden.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: Tegra ASoC, multiple boards, platform data, and conditionals in machine driver
From: Olof Johansson @ 2011-04-10 18:18 UTC (permalink / raw)
To: Stephen Warren
Cc: Colin Cross (ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org),
Erik Gilling (konkers-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org),
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF0493EB3B5B-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
Hi,
On Sat, Apr 9, 2011 at 7:52 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> Colin, Erik, Olof,
>
> Do you have any objections to moving arch/arm/mach-tegra/board-*.h and
> gpio-names.h into arch/arch/mach-tegra/include/mach so that the audio
> driver source can include those headers simply?
>
> See the thread below for background.
I would prefer to use platform_data and export the information through there.
I know ASoC is in some sense an exception to the rule, but in general
there should be no need for any code outside of arch/arm/mach-tegra to
have to know anything about the board it is running on, drivers should
be generic enough. Some other platforms use a lot of shared header
files between platform code and drivers, and I have always found that
to be very awkward to follow when reading code, especially if the same
constants are defined in multiple places depending on what board is
built. It also makes it harder to maintain a multiplatform kernel if
configuration data is pulled in at build time instead of runtime (i.e.
headers vs platform_data or similar).
In other words, I would prefer option (b) above.
-Olof
^ permalink raw reply
* [U-Boot] [PATCH v2 2/2] MX31: mx31pdk: Print the cause of reset
From: Fabio Estevam @ 2011-04-10 18:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1302459471-12308-1-git-send-email-festevam@gmail.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- Use 3 bits for rcsr mask
board/freescale/mx31pdk/mx31pdk.c | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mx31pdk/mx31pdk.c b/board/freescale/mx31pdk/mx31pdk.c
index 4ef548f..5fc6319 100644
--- a/board/freescale/mx31pdk/mx31pdk.c
+++ b/board/freescale/mx31pdk/mx31pdk.c
@@ -86,7 +86,30 @@ int board_late_init(void)
int checkboard(void)
{
- printf("Board: i.MX31 MAX PDK (3DS)\n");
+ u32 cause;
+ struct clock_control_regs *ccm =
+ (struct clock_control_regs *)CCM_BASE;
+ puts("Board: MX31PDK [");
+
+ cause = ccm->rcsr & 0x07;
+ switch (cause) {
+ case 0x0000:
+ puts("POR");
+ break;
+ case 0x0001:
+ puts("RST");
+ break;
+ case 0x0002:
+ puts("WDOG");
+ break;
+ case 0x0006:
+ puts("JTAG");
+ break;
+ default:
+ puts("unknown");
+ }
+
+ puts("]\n");
return 0;
}
--
1.6.0.4
^ permalink raw reply related
* [U-Boot] [PATCH v2 1/2] MX31: mx31pdk: Add watchdog support
From: Fabio Estevam @ 2011-04-10 18:17 UTC (permalink / raw)
To: u-boot
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- define BOARD_LATE_INIT in /mx31pdk.h
board/freescale/mx31pdk/mx31pdk.c | 16 ++++++++++++++++
include/configs/mx31pdk.h | 3 +++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/board/freescale/mx31pdk/mx31pdk.c b/board/freescale/mx31pdk/mx31pdk.c
index 3f291fc..4ef548f 100644
--- a/board/freescale/mx31pdk/mx31pdk.c
+++ b/board/freescale/mx31pdk/mx31pdk.c
@@ -28,9 +28,17 @@
#include <netdev.h>
#include <asm/arch/clock.h>
#include <asm/arch/imx-regs.h>
+#include <watchdog.h>
DECLARE_GLOBAL_DATA_PTR;
+#ifdef CONFIG_HW_WATCHDOG
+void hw_watchdog_reset(void)
+{
+ mxc_hw_watchdog_reset();
+}
+#endif
+
int dram_init(void)
{
/* dram_init must store complete ramsize in gd->ram_size */
@@ -68,6 +76,14 @@ int board_init(void)
return 0;
}
+int board_late_init(void)
+{
+#ifdef CONFIG_HW_WATCHDOG
+ mxc_hw_watchdog_enable();
+#endif
+ return 0;
+}
+
int checkboard(void)
{
printf("Board: i.MX31 MAX PDK (3DS)\n");
diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h
index d4c6d16..f5d3ee7 100644
--- a/include/configs/mx31pdk.h
+++ b/include/configs/mx31pdk.h
@@ -61,6 +61,7 @@
#define CONFIG_MXC_UART 1
#define CONFIG_SYS_MX31_UART1 1
+#define CONFIG_HW_WATCHDOG
#define CONFIG_HARD_SPI 1
#define CONFIG_MXC_SPI 1
@@ -98,6 +99,8 @@
*/
#undef CONFIG_CMD_IMLS
+#define BOARD_LATE_INIT
+
#define CONFIG_BOOTDELAY 3
#define CONFIG_EXTRA_ENV_SETTINGS \
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 1/2] ARM: Differentiate SheevaPlugs and DockStars on the basis of the memory size.
From: Alexander Holler @ 2011-04-10 18:14 UTC (permalink / raw)
To: Bernd Petrovitsch
Cc: Russell King - ARM Linux, Alexander Clouter, linux-kernel,
linux-arm-kernel
In-Reply-To: <1302337753.30783.24.camel@thorin>
Hello,
On 09.04.2011 10:29, Bernd Petrovitsch wrote:
Thanks for your helpfull tipps, but I'm writing software since about
30a, and I get paid for that since about 25a.
How long to you that?
If anyone else wants to enter this discussion, sorry, but I will not
answer any more emails here.
Alexander
^ permalink raw reply
* [PATCH 1/2] ARM: Differentiate SheevaPlugs and DockStars on the basis of the memory size.
From: Alexander Holler @ 2011-04-10 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1302337753.30783.24.camel@thorin>
Hello,
On 09.04.2011 10:29, Bernd Petrovitsch wrote:
Thanks for your helpfull tipps, but I'm writing software since about
30a, and I get paid for that since about 25a.
How long to you that?
If anyone else wants to enter this discussion, sorry, but I will not
answer any more emails here.
Alexander
^ permalink raw reply
* Re: [PATCH] fix build warnings on defconfigs
From: Uwe Kleine-König @ 2011-04-10 18:12 UTC (permalink / raw)
To: wanlong.gao
Cc: linux-mips, david.woodhouse, tony, nicolas.ferre, paulus, eric,
sam, sfr, linux, khilman, manuel.lauss, rientjes, mingo, anton,
ben-linux, linux-arm-kernel, linux-kernel, ralf,
santosh.shilimkar, akpm, linuxppc-dev, hans-christian.egtvedt
In-Reply-To: <1302375858-11253-1-git-send-email-wanlong.gao@gmail.com>
On Sun, Apr 10, 2011 at 03:04:18AM +0800, wanlong.gao@gmail.com wrote:
> From: Wanlong Gao <wanlong.gao@gmail.com>
>
> Change the BT_L2CAP and BT_SCO defconfigs from 'm' to 'y',
> since BT_L2CAP and BT_SCO had changed to bool configs.
Pointing out the commit that changed these two in the commit log would
be nice. Something like:
The BT_L2CAP and BT_SCO configs are bool since
6427451 (Bluetooth: Merge L2CAP and SCO modules into bluetooth.ko)
. So change all defconfigs from =m to =y.
Other than that
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH] fix build warnings on defconfigs
From: Uwe Kleine-König @ 2011-04-10 18:12 UTC (permalink / raw)
To: wanlong.gao
Cc: linux, hans-christian.egtvedt, ralf, benh, paulus,
david.woodhouse, akpm, mingo, rientjes, nicolas.ferre, eric, tony,
santosh.shilimkar, khilman, ben-linux, sam, manuel.lauss, galak,
anton, grant.likely, sfr, jwboyer, linux-arm-kernel, linux-kernel,
linux-mips, linuxppc-dev
In-Reply-To: <1302375858-11253-1-git-send-email-wanlong.gao@gmail.com>
On Sun, Apr 10, 2011 at 03:04:18AM +0800, wanlong.gao@gmail.com wrote:
> From: Wanlong Gao <wanlong.gao@gmail.com>
>
> Change the BT_L2CAP and BT_SCO defconfigs from 'm' to 'y',
> since BT_L2CAP and BT_SCO had changed to bool configs.
Pointing out the commit that changed these two in the commit log would
be nice. Something like:
The BT_L2CAP and BT_SCO configs are bool since
6427451 (Bluetooth: Merge L2CAP and SCO modules into bluetooth.ko)
. So change all defconfigs from =m to =y.
Other than that
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Firmware files for Ralink RT28x0
From: Xose Vazquez Perez @ 2011-04-10 18:12 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: linux-wireless, users
In-Reply-To: <BANLkTimp6h9x0JC0HzSpKzdbKLOw=ioUvw@mail.gmail.com>
On 04/10/2011 07:35 PM, Ivo Van Doorn wrote:
> True, but the rt2860 and rt2870 firmware file are outdated in the
> linux-firmware,
> and probably don't support the rt3090 or other more recent chipsets. So before
> they can be removed, those files must be updated.
Larry Finger sent a patch to remove the rt28{6,7}0 staging drivers.
So the rt3070.bin rt3071.bin rt3090.bin files in linux-firmware
also can be removed, because they are included _only_ in the rt28{6,7}0
staging drivers.
^ permalink raw reply
* [PATCH] fix build warnings on defconfigs
From: Uwe Kleine-König @ 2011-04-10 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1302375858-11253-1-git-send-email-wanlong.gao@gmail.com>
On Sun, Apr 10, 2011 at 03:04:18AM +0800, wanlong.gao at gmail.com wrote:
> From: Wanlong Gao <wanlong.gao@gmail.com>
>
> Change the BT_L2CAP and BT_SCO defconfigs from 'm' to 'y',
> since BT_L2CAP and BT_SCO had changed to bool configs.
Pointing out the commit that changed these two in the commit log would
be nice. Something like:
The BT_L2CAP and BT_SCO configs are bool since
6427451 (Bluetooth: Merge L2CAP and SCO modules into bluetooth.ko)
. So change all defconfigs from =m to =y.
Other than that
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v2] lowpan-tools_0.2.2; : fix build with static libnl1
From: Anders Darander @ 2011-04-10 18:07 UTC (permalink / raw)
To: openembedded-devel@lists.openembedded.org
In-Reply-To: <1302456441-3417-1-git-send-email-anders@chargestorm.se>
Hi,
I'm replying to my own mail...
This patch is intended for th org.openembedded.dev branch, as it
requires the libnl -> libnl1 patch by Martin Jansa, wich is applied to
that branch.
This to solves the problem of using lowpan-tools on a system which
otherwise uses libnl2.
* Anders Darander <anders@chargestorm.se> [110410 19:27]:
> * add NL_CFLAGS to a few Makefiles.am
> * git version not fixed
> * build and runtime tested, although only in qemuarm
I forgot to mention that the difference between v2 and v1, is that I
forgot to update PR in the first version. This is corrected in the
current version.
I hope that this patch can be ACK'ed and pushed.
Regards,
Anders
--
Anders Darander
ChargeStorm AB
^ permalink raw reply
* Re: [poky] Illustration of task latency
From: Richard Purdie @ 2011-04-10 18:04 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: poky
In-Reply-To: <1302366380.22904.153.camel@rex>
On Sat, 2011-04-09 at 09:26 -0700, Richard Purdie wrote:
> I've dug into this a bit. When running a given task, it is parsing all
> bbclassextend variants again. I have a simple patch which fixes that
> which I'll cleanup and share.
>
> What I also noticed which was more odd was that the first finalise()
> call was taking 0.2s, subsequent ones were taking 0.1s. It turns out
> that the parsercache which is used by the siggen code isn't functioning
> the way it should with a lot of cache misses. I think this is related to
> the parallel parsing and only saving out cached data from the core, not
> the individual recipes (i.e. the cache from the parser subthreads). I
> suspect we could get some performance improvement by fixing this.
Fixes for the issues I noticed are in:
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=rpurdie/bboptimise
It turns out executing a function at process exit time with
multiprocessing is quite tricky and I'm not 100% sure I'm using public
API with the approach I've ended up using.
The speedups have a good feel to them and show the right things with
benchmarks. It will be interesting to see how much affect they have on
real world build time (which I'll test when I get home next week).
They're also showing a significant reduction in parsing time.
I also noticed that skipped recipes were always being reparsed which is
suboptimial and I've included a work in progress fix for that in the
above branch too.
Cheers,
Richard
^ permalink raw reply
* Re: Firmware files for Ralink RT28x0
From: Ivo Van Doorn @ 2011-04-10 18:06 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Gertjan van Wingerde, linux-wireless
In-Reply-To: <1302457754.5282.219.camel@localhost>
Hi,
>> On Sun, Apr 10, 2011 at 5:56 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
>> > I notice that rt2800{pci,usb} each specify only one firmware image,
>> > regardless of the controller version.
>> >
>> > This is inconsistent with rt28{6,7}0sta and with the firmware images in
>> > linux-firmware.
>>
>> Well the rt2800pci/usb firmware behavior is consistent with the original
>> Ralink drivers (Not sure about the staging drivers, I only look to the drivers
>> on the Ralink website).
>
> Are you referring to the #ifdef BIN_IN_FILE code? This code is not
> enabled, so you should assume it is broken. I suspect that it was
> intended to ease firmware development.
Not only BIN_IN_FILE, but the .bin files provided in the Ralink package
itself. At some point I grabbed all .bin files from all Ralink packages,
and compared them.
I also grabbed the firmware files, which Ralink provided separately,
Basically it was very clear that the firmware provided by rt3070, was
a simple later release of the rt2860 firmware (which is still used
for rt2860 devices).
So with new versions of the firmware, support for new chipsets was
being addded.
> Ralink provides multiple drivers per bus type for RT28xx and later
> chips. For PCI devices they split between RT2860 and RT309x; for USB
> devices they split between RT2870 and RT307x (I think - the chip model
> numbers don't seem to be stated consistently).
>
> In addition, the USB drivers have two separate images packed together
> and they can select different images based on the controller version:
>
> #ifdef RTMP_MAC_USB
> if ((Version != 0x2860) && (Version != 0x2872) && (Version != 0x3070))
> { // Use Firmware V2.
> //printk("KH:Use New Version,part2\n");
> pFirmwareImage = (PUCHAR)&FirmwareImage[FIRMWAREIMAGEV1_LENGTH];
> FileLength = FIRMWAREIMAGEV2_LENGTH;
> }
> else
> {
> //printk("KH:Use New Version,part1\n");
> pFirmwareImage = FirmwareImage;
> FileLength = FIRMWAREIMAGEV1_LENGTH;
> }
> #endif // RTMP_MAC_USB //
>
> The firmware blobs in RT2870 version 2009-08-20 and RT3070 version
> 2009-05-25 are all marked as version 17 (or 0.17), but *they all have
> different contents*.
How do you determine this version? I usually check the last couple
of bytes of the firmware file. (The last 2 bytes of the firmware is the CRC,
but the 2 bytes before that is the version).
> I attempted to maintain the same version selection logic when converting
> the staging drivers to use the firmware loader, since I assumed there
> was a good reason for it.
>
>> As for the linux-firmware that contains some firmware files for rt30** chipsets,
>> but that are not used by rt2800pci/usb for the simple reason that the latest
>> version of the rt2860.bin and rt2870.bin files contain support for
>> those chipsets
>> as well.
>
> So I have heard. But do they still support the original chips
> correctly?
Yes, I am using the latest firmware for my rt2860/2870 devices
without problems.
>> > If you think that a single image per bus type can cover all controllers,
>> > please identify those firmware images, test them on each hardware
>> > generation, and get them into linux-firmware.
>>
>> Updating the firmware files in the linux-firmware tree seems to be
>> close to impossible. Multiple attempts have been made to update the
>> firmware files for rt73usb, rt61pci, rt2800pci and rt2800usb, and every
>> attempt has been ignored.
>> Even when Ralink sent the update directly, and it seemed that the patches
>> were accepted, they were still not applied.
>
> This roughly matches my experience, except that I have been persistent
> enough to get my changes applied eventually.
>
>> So honestly, I think it might be easier to simply remove the Ralink firmware
>> files from the linux-firmware tree, as then at least the users won't accidently
>> use the outdated firmware files from that tree.
>
> linux-firmware is supposed to have all firmware files referenced by any
> version of Linux; therefore these files must not be removed.
I agree that the firmware should be in linux-firmware, but only if they
are the latest version (and it is possible to keep them up-to-date). Having
outdated firmware in the linux-firmware tree only causes more problems.
> If just two files are sufficient then the other files could be replaced
> by symlinks to them.
Why? The patch to remove the staging drivers has been sent out a few
days ago. After that we only have rt2800pci and rt2800usb drivers,
so we can get rid of the rt30xx files completely. ;)
Ivo
^ permalink raw reply
* Re: [OE-core] Illustration of task latency
From: Richard Purdie @ 2011-04-10 18:04 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: poky
In-Reply-To: <1302366380.22904.153.camel@rex>
On Sat, 2011-04-09 at 09:26 -0700, Richard Purdie wrote:
> I've dug into this a bit. When running a given task, it is parsing all
> bbclassextend variants again. I have a simple patch which fixes that
> which I'll cleanup and share.
>
> What I also noticed which was more odd was that the first finalise()
> call was taking 0.2s, subsequent ones were taking 0.1s. It turns out
> that the parsercache which is used by the siggen code isn't functioning
> the way it should with a lot of cache misses. I think this is related to
> the parallel parsing and only saving out cached data from the core, not
> the individual recipes (i.e. the cache from the parser subthreads). I
> suspect we could get some performance improvement by fixing this.
Fixes for the issues I noticed are in:
http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=rpurdie/bboptimise
It turns out executing a function at process exit time with
multiprocessing is quite tricky and I'm not 100% sure I'm using public
API with the approach I've ended up using.
The speedups have a good feel to them and show the right things with
benchmarks. It will be interesting to see how much affect they have on
real world build time (which I'll test when I get home next week).
They're also showing a significant reduction in parsing time.
I also noticed that skipped recipes were always being reparsed which is
suboptimial and I've included a work in progress fix for that in the
above branch too.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 1/8] gitk: fix file highlight when run in subdirectory
From: Martin von Zweigbergk @ 2011-04-10 18:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
In-Reply-To: <20110410015410.GA25368@brick.ozlabs.ibm.com>
Hi Paul,
Thanks for your input. I will work on a re-roll of this series based
on, at least,
your input on patch 8/8. However, I am going away for 4 weeks today and I will
probably not be able to do that until some time after I come back. If
anyone else
cares to do it before then, please go ahead.
On Sat, Apr 9, 2011 at 9:54 PM, Paul Mackerras <paulus@samba.org> wrote:
> I have to admit I wasn't aware of GIT_WORK_TREE before I saw your
> patches. The patches look OK, but I wonder how many of the problems
> would go away if gitk were simply to set GIT_WORK_TREE in the
> environment for the programs it runs, if it is not already set.
Most of the problems I have tried to fix in this series only appear when
GIT_WORK_TREE _is_ set, so I don't think setting it would help. When
it it not set,
setting it to the directory that git detected should have no effect as
far as I can see.
/Martin
^ permalink raw reply
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
From: Blue Swirl @ 2011-04-10 17:57 UTC (permalink / raw)
To: Artyom Tarasenko; +Cc: peter.maydell, qemu-devel, Aurelien Jarno
In-Reply-To: <BANLkTi=DC0NMecn1YCUf=zqu5cBByxhLmA@mail.gmail.com>
On Sun, Apr 10, 2011 at 8:48 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
> On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
>> On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
>>> On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
>>>> On Sun, Apr 10, 2011 at 02:29:59PM +0200, Artyom Tarasenko wrote:
>>>>> Trying to boot some proprietary OS I get qemu-system-sparc64 crash with a
>>>>>
>>>>> tcg/tcg.c:1892: tcg fatal error
>>>>>
>>>>> error message.
>>>>>
>>>>> It looks like it can be a platform independent bug though, because
>>>>> when a '-singlestep' option IS present, qemu doesn't crash and seems
>>>>> to translate the code properly.
>>>>>
>>>>> (gdb) bt
>>>>> #0 0x00000032c2e327f5 in raise () from /lib64/libc.so.6
>>>>> #1 0x00000032c2e33fd5 in abort () from /lib64/libc.so.6
>>>>> #2 0x000000000051933d in tcg_reg_alloc_call (s=<value optimized out>,
>>>>> def=0x89d340, opc=INDEX_op_call, args=0x10acc98, dead_iargs=3) at
>>>>> qemu/tcg/tcg.c:1892
>>>>> #3 0x000000000051a557 in tcg_gen_code_common (s=0x10b8940,
>>>>> gen_code_buf=0x40338b60 "I\213n@H\213] 3\355I\211\256\220") at
>>>>> qemu/tcg/tcg.c:2099
>>>>> #4 tcg_gen_code (s=0x10b8940, gen_code_buf=0x40338b60 "I\213n@H\213]
>>>>> 3\355I\211\256\220") at qemu/tcg/tcg.c:2142
>>>>> #5 0x00000000004d38f1 in cpu_sparc_gen_code (env=0x10cce10,
>>>>> tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffffffd9b4) at
>>>>> qemu/translate-all.c:93
>>>>> #6 0x00000000004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776,
>>>>> cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989
>>>>> #7 0x00000000004d4029 in tb_find_slow (env1=<value optimized out>) at
>>>>> qemu/cpu-exec.c:167
>>>>> #8 tb_find_fast (env1=<value optimized out>) at cpu-exec.c:194
>>>>> #9 cpu_sparc_exec (env1=<value optimized out>) at qemu/cpu-exec.c:556
>>>>> #10 0x0000000000408868 in tcg_cpu_exec () at qemu/cpus.c:1066
>>>>> #11 cpu_exec_all () at qemu/cpus.c:1102
>>>>> #12 0x000000000053c756 in main_loop (argc=<value optimized out>,
>>>>> argv=<value optimized out>, envp=<value optimized out>) at
>>>>> qemu/vl.c:1430
>>>>>
>>>>> I inspected ts->val_type causing the abort() case and it turned out to be 0.
>>>>>
>>>>> The last lines of qemu.log (without -singlestep)
>>>>> IN:
>>>>> 0x00000000011fe9f0: rdpr %pstate, %g1
>>>>> 0x00000000011fe9f4: wrpr %g1, 2, %pstate
>>>>> --------------
>>>>> IN:
>>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1
>>>>> 0x00000000011fe9fc: mov %o1, %o2
>>>>> 0x00000000011fea00: rdpr %tick, %o3
>>>>> 0x00000000011fea04: cmp %o1, %o2
>>>>> 0x00000000011fea08: be %icc, 0x11fea00
>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2
>>>>>
>>>>> Search PC...
>>>>> Search PC...
>>>>> Search PC...
>>>>> Search PC...
>>>>> Search PC...
>>>>> Search PC...
>>>>> --------------
>>>>> IN:
>>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1
>>>>> 0x00000000011fe9fc: mov %o1, %o2
>>>>> 0x00000000011fea00: rdpr %tick, %o3
>>>>> 0x00000000011fea04: cmp %o1, %o2
>>>>> 0x00000000011fea08: be %icc, 0x11fea00
>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2
>>>>>
>>>>> 110521: Data Access MMU Miss (v=0068) pc=00000000011fe9f8
>>>>> npc=00000000011fe9fc SP=000000000180ae41
>>>>> pc: 00000000011fe9f8 npc: 00000000011fe9fc
>>>>>
>>>>> IN:
>>>>> 0x00000000011fea00: rdpr %tick, %o3
>>>>> 0x00000000011fea04: cmp %o1, %o2
>>>>> 0x00000000011fea08: be %icc, 0x11fea00
>>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2
>>>>> --------------
>>>>> IN:
>>>>> 0x00000000011fea10: brz,pn %o2, 0x11fe9f8
>>>>> 0x00000000011fea14: mov %o2, %o4
>>>>> --------------
>>>>> IN:
>>>>> 0x00000000011fea18: rdpr %tick, %o5
>>>>> 0x00000000011fea1c: cmp %o2, %o4
>>>>> 0x00000000011fea20: be %icc, 0x11fea18
>>>>> 0x00000000011fea24: ldub [ %o0 ], %o4
>>>>> --------------
>>>>> IN:
>>>>> 0x00000000011fea28: brz,pn %o4, 0x11fe9f4
>>>>> 0x00000000011fea2c: wrpr %g0, %g1, %pstate
>>>>> <EOF>
>>>>>
>>>>> The crash is 100% reproducible and happens always on the same place,
>>>>> so it's probably a pure TCG issue, not related on getting the
>>>>> external/timer interrupts.
>>>>>
>>>>> Do you need any additional info?
>>>>>
>>>>
>>>> What would be interesting would be to get the corresponding TCG code
>>>> from qemu.log (-d op,op_opt).
>>>
>>>
>>> OP:
>>> ---- 0x11fea28
>>> ld_i64 tmp6,regwptr,$0x20
>>> movi_i64 cond,$0x0
>>> movi_i64 tmp8,$0x0
>>> brcond_i64 tmp6,tmp8,ne,$0x0
>>> movi_i64 cond,$0x1
>>> set_label $0x0
>>>
>>> ---- 0x11fea2c
>>> movi_i64 tmp7,$0x0
>>> xor_i64 tmp0,tmp7,g1
>>> movi_i64 pc,$0x11fea2c
>>> movi_i64 tmp8,$compute_psr
>>> call tmp8,$0x0,$0
>>> movi_i64 tmp8,$0x0
>>> brcond_i64 cond,tmp8,eq,$0x1
>>> movi_i64 npc,$0x11fe9f4
>>> br $0x2
>>> set_label $0x1
>>> movi_i64 npc,$0x11fea30
>>> set_label $0x2
>>> movi_i64 tmp8,$wrpstate
>>> call tmp8,$0x0,$0,tmp0
>>> mov_i64 pc,npc
>>> movi_i64 tmp8,$0x4
>>> add_i64 npc,npc,tmp8
>>> exit_tb $0x0
>>>
>>> OP after liveness analysis:
>>> ---- 0x11fea28
>>> ld_i64 tmp6,regwptr,$0x20
>>> movi_i64 cond,$0x0
>>> movi_i64 tmp8,$0x0
>>> brcond_i64 tmp6,tmp8,ne,$0x0
>>> movi_i64 cond,$0x1
>>> set_label $0x0
>>>
>>> ---- 0x11fea2c
>>> nopn $0x2,$0x2
>>> nopn $0x3,$0x68,$0x3
>>> movi_i64 pc,$0x11fea2c
>>> movi_i64 tmp8,$compute_psr
>>> call tmp8,$0x0,$0
>>> movi_i64 tmp8,$0x0
>>> brcond_i64 cond,tmp8,eq,$0x1
>>> movi_i64 npc,$0x11fe9f4
>>> br $0x2
>>> set_label $0x1
>>> movi_i64 npc,$0x11fea30
>>> set_label $0x2
>>> movi_i64 tmp8,$wrpstate
>>> call tmp8,$0x0,$0,tmp0
>>> mov_i64 pc,npc
>>> movi_i64 tmp8,$0x4
>>> add_i64 npc,npc,tmp8
>>> exit_tb $0x0
>>> end
>>>
>>> Does it mean the last block is processed correctly and the crash
>>> happens on the next instruction which doesn't make it to the log?
>>> The next instruction would be a
>>>
>>> 0x00000000011fea30: retl
>>>
>>> Since it's a branch instruction I guess this would also be a tcg block boundary.
>>
>> Because abort() was called from tcg_reg_alloc_call, I'd say 'retl'
>> (synthetic op for 'jmpl %o8 + 8, %g0') was the problem.
>
> Any idea why? retl is not a rare instruction...
Sorry, calls are generated for helpers, so it's not 'jmpl' but the
call to wrpstate helper.
^ permalink raw reply
* Webmail Quote The Set-Limit überschritten
From: System Administrator @ 2011-04-10 15:48 UTC (permalink / raw)
Ihr Postfach hat die Lagerung Grenze, die 1GB ist als vom
Administrator festgelegt, Sie sind derzeit auf 3.9GB, können Sie nicht
in der Lage zu senden oder zu empfangen, bis Sie neue E-Mail erneut
validieren Ihr Postfach überschritten. Zur erneuten Überprüfung Ihrer
Mailbox bitte hier klicken:
http://95.211.18.138/~dolcevita/iss/account.html
Dank
System-Administrator
^ permalink raw reply
* Re: Firmware files for Ralink RT28x0
From: Ben Hutchings @ 2011-04-10 17:49 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: Gertjan van Wingerde, linux-wireless
In-Reply-To: <BANLkTi=-bRn_6yie1b=wxgVowqZq6+03CQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3513 bytes --]
On Sun, 2011-04-10 at 18:35 +0200, Ivo Van Doorn wrote:
> Hi,
>
> On Sun, Apr 10, 2011 at 5:56 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> > I notice that rt2800{pci,usb} each specify only one firmware image,
> > regardless of the controller version.
> >
> > This is inconsistent with rt28{6,7}0sta and with the firmware images in
> > linux-firmware.
>
> Well the rt2800pci/usb firmware behavior is consistent with the original
> Ralink drivers (Not sure about the staging drivers, I only look to the drivers
> on the Ralink website).
Are you referring to the #ifdef BIN_IN_FILE code? This code is not
enabled, so you should assume it is broken. I suspect that it was
intended to ease firmware development.
Ralink provides multiple drivers per bus type for RT28xx and later
chips. For PCI devices they split between RT2860 and RT309x; for USB
devices they split between RT2870 and RT307x (I think - the chip model
numbers don't seem to be stated consistently).
In addition, the USB drivers have two separate images packed together
and they can select different images based on the controller version:
#ifdef RTMP_MAC_USB
if ((Version != 0x2860) && (Version != 0x2872) && (Version != 0x3070))
{ // Use Firmware V2.
//printk("KH:Use New Version,part2\n");
pFirmwareImage = (PUCHAR)&FirmwareImage[FIRMWAREIMAGEV1_LENGTH];
FileLength = FIRMWAREIMAGEV2_LENGTH;
}
else
{
//printk("KH:Use New Version,part1\n");
pFirmwareImage = FirmwareImage;
FileLength = FIRMWAREIMAGEV1_LENGTH;
}
#endif // RTMP_MAC_USB //
The firmware blobs in RT2870 version 2009-08-20 and RT3070 version
2009-05-25 are all marked as version 17 (or 0.17), but *they all have
different contents*.
I attempted to maintain the same version selection logic when converting
the staging drivers to use the firmware loader, since I assumed there
was a good reason for it.
> As for the linux-firmware that contains some firmware files for rt30** chipsets,
> but that are not used by rt2800pci/usb for the simple reason that the latest
> version of the rt2860.bin and rt2870.bin files contain support for
> those chipsets
> as well.
So I have heard. But do they still support the original chips
correctly?
> > If you think that a single image per bus type can cover all controllers,
> > please identify those firmware images, test them on each hardware
> > generation, and get them into linux-firmware.
>
> Updating the firmware files in the linux-firmware tree seems to be
> close to impossible. Multiple attempts have been made to update the
> firmware files for rt73usb, rt61pci, rt2800pci and rt2800usb, and every
> attempt has been ignored.
> Even when Ralink sent the update directly, and it seemed that the patches
> were accepted, they were still not applied.
This roughly matches my experience, except that I have been persistent
enough to get my changes applied eventually.
> So honestly, I think it might be easier to simply remove the Ralink firmware
> files from the linux-firmware tree, as then at least the users won't accidently
> use the outdated firmware files from that tree.
linux-firmware is supposed to have all firmware files referenced by any
version of Linux; therefore these files must not be removed.
If just two files are sufficient then the other files could be replaced
by symlinks to them.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] tcg/tcg.c:1892: tcg fatal error
From: Artyom Tarasenko @ 2011-04-10 17:48 UTC (permalink / raw)
To: Blue Swirl; +Cc: peter.maydell, qemu-devel, Aurelien Jarno
In-Reply-To: <BANLkTi=Pnbk2zBEudUApz=_-gvoBrkiADA@mail.gmail.com>
On Sun, Apr 10, 2011 at 4:44 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> On Sun, Apr 10, 2011 at 5:09 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
>> On Sun, Apr 10, 2011 at 3:24 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
>>> On Sun, Apr 10, 2011 at 02:29:59PM +0200, Artyom Tarasenko wrote:
>>>> Trying to boot some proprietary OS I get qemu-system-sparc64 crash with a
>>>>
>>>> tcg/tcg.c:1892: tcg fatal error
>>>>
>>>> error message.
>>>>
>>>> It looks like it can be a platform independent bug though, because
>>>> when a '-singlestep' option IS present, qemu doesn't crash and seems
>>>> to translate the code properly.
>>>>
>>>> (gdb) bt
>>>> #0 0x00000032c2e327f5 in raise () from /lib64/libc.so.6
>>>> #1 0x00000032c2e33fd5 in abort () from /lib64/libc.so.6
>>>> #2 0x000000000051933d in tcg_reg_alloc_call (s=<value optimized out>,
>>>> def=0x89d340, opc=INDEX_op_call, args=0x10acc98, dead_iargs=3) at
>>>> qemu/tcg/tcg.c:1892
>>>> #3 0x000000000051a557 in tcg_gen_code_common (s=0x10b8940,
>>>> gen_code_buf=0x40338b60 "I\213n@H\213] 3\355I\211\256\220") at
>>>> qemu/tcg/tcg.c:2099
>>>> #4 tcg_gen_code (s=0x10b8940, gen_code_buf=0x40338b60 "I\213n@H\213]
>>>> 3\355I\211\256\220") at qemu/tcg/tcg.c:2142
>>>> #5 0x00000000004d38f1 in cpu_sparc_gen_code (env=0x10cce10,
>>>> tb=0x7fffe91bc218, gen_code_size_ptr=0x7fffffffd9b4) at
>>>> qemu/translate-all.c:93
>>>> #6 0x00000000004d1fd7 in tb_gen_code (env=0x10cce10, pc=18868776,
>>>> cs_base=18868780, flags=15, cflags=0) at qemu/exec.c:989
>>>> #7 0x00000000004d4029 in tb_find_slow (env1=<value optimized out>) at
>>>> qemu/cpu-exec.c:167
>>>> #8 tb_find_fast (env1=<value optimized out>) at cpu-exec.c:194
>>>> #9 cpu_sparc_exec (env1=<value optimized out>) at qemu/cpu-exec.c:556
>>>> #10 0x0000000000408868 in tcg_cpu_exec () at qemu/cpus.c:1066
>>>> #11 cpu_exec_all () at qemu/cpus.c:1102
>>>> #12 0x000000000053c756 in main_loop (argc=<value optimized out>,
>>>> argv=<value optimized out>, envp=<value optimized out>) at
>>>> qemu/vl.c:1430
>>>>
>>>> I inspected ts->val_type causing the abort() case and it turned out to be 0.
>>>>
>>>> The last lines of qemu.log (without -singlestep)
>>>> IN:
>>>> 0x00000000011fe9f0: rdpr %pstate, %g1
>>>> 0x00000000011fe9f4: wrpr %g1, 2, %pstate
>>>> --------------
>>>> IN:
>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1
>>>> 0x00000000011fe9fc: mov %o1, %o2
>>>> 0x00000000011fea00: rdpr %tick, %o3
>>>> 0x00000000011fea04: cmp %o1, %o2
>>>> 0x00000000011fea08: be %icc, 0x11fea00
>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2
>>>>
>>>> Search PC...
>>>> Search PC...
>>>> Search PC...
>>>> Search PC...
>>>> Search PC...
>>>> Search PC...
>>>> --------------
>>>> IN:
>>>> 0x00000000011fe9f8: ldub [ %o0 ], %o1
>>>> 0x00000000011fe9fc: mov %o1, %o2
>>>> 0x00000000011fea00: rdpr %tick, %o3
>>>> 0x00000000011fea04: cmp %o1, %o2
>>>> 0x00000000011fea08: be %icc, 0x11fea00
>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2
>>>>
>>>> 110521: Data Access MMU Miss (v=0068) pc=00000000011fe9f8
>>>> npc=00000000011fe9fc SP=000000000180ae41
>>>> pc: 00000000011fe9f8 npc: 00000000011fe9fc
>>>>
>>>> IN:
>>>> 0x00000000011fea00: rdpr %tick, %o3
>>>> 0x00000000011fea04: cmp %o1, %o2
>>>> 0x00000000011fea08: be %icc, 0x11fea00
>>>> 0x00000000011fea0c: ldub [ %o0 ], %o2
>>>> --------------
>>>> IN:
>>>> 0x00000000011fea10: brz,pn %o2, 0x11fe9f8
>>>> 0x00000000011fea14: mov %o2, %o4
>>>> --------------
>>>> IN:
>>>> 0x00000000011fea18: rdpr %tick, %o5
>>>> 0x00000000011fea1c: cmp %o2, %o4
>>>> 0x00000000011fea20: be %icc, 0x11fea18
>>>> 0x00000000011fea24: ldub [ %o0 ], %o4
>>>> --------------
>>>> IN:
>>>> 0x00000000011fea28: brz,pn %o4, 0x11fe9f4
>>>> 0x00000000011fea2c: wrpr %g0, %g1, %pstate
>>>> <EOF>
>>>>
>>>> The crash is 100% reproducible and happens always on the same place,
>>>> so it's probably a pure TCG issue, not related on getting the
>>>> external/timer interrupts.
>>>>
>>>> Do you need any additional info?
>>>>
>>>
>>> What would be interesting would be to get the corresponding TCG code
>>> from qemu.log (-d op,op_opt).
>>
>>
>> OP:
>> ---- 0x11fea28
>> ld_i64 tmp6,regwptr,$0x20
>> movi_i64 cond,$0x0
>> movi_i64 tmp8,$0x0
>> brcond_i64 tmp6,tmp8,ne,$0x0
>> movi_i64 cond,$0x1
>> set_label $0x0
>>
>> ---- 0x11fea2c
>> movi_i64 tmp7,$0x0
>> xor_i64 tmp0,tmp7,g1
>> movi_i64 pc,$0x11fea2c
>> movi_i64 tmp8,$compute_psr
>> call tmp8,$0x0,$0
>> movi_i64 tmp8,$0x0
>> brcond_i64 cond,tmp8,eq,$0x1
>> movi_i64 npc,$0x11fe9f4
>> br $0x2
>> set_label $0x1
>> movi_i64 npc,$0x11fea30
>> set_label $0x2
>> movi_i64 tmp8,$wrpstate
>> call tmp8,$0x0,$0,tmp0
>> mov_i64 pc,npc
>> movi_i64 tmp8,$0x4
>> add_i64 npc,npc,tmp8
>> exit_tb $0x0
>>
>> OP after liveness analysis:
>> ---- 0x11fea28
>> ld_i64 tmp6,regwptr,$0x20
>> movi_i64 cond,$0x0
>> movi_i64 tmp8,$0x0
>> brcond_i64 tmp6,tmp8,ne,$0x0
>> movi_i64 cond,$0x1
>> set_label $0x0
>>
>> ---- 0x11fea2c
>> nopn $0x2,$0x2
>> nopn $0x3,$0x68,$0x3
>> movi_i64 pc,$0x11fea2c
>> movi_i64 tmp8,$compute_psr
>> call tmp8,$0x0,$0
>> movi_i64 tmp8,$0x0
>> brcond_i64 cond,tmp8,eq,$0x1
>> movi_i64 npc,$0x11fe9f4
>> br $0x2
>> set_label $0x1
>> movi_i64 npc,$0x11fea30
>> set_label $0x2
>> movi_i64 tmp8,$wrpstate
>> call tmp8,$0x0,$0,tmp0
>> mov_i64 pc,npc
>> movi_i64 tmp8,$0x4
>> add_i64 npc,npc,tmp8
>> exit_tb $0x0
>> end
>>
>> Does it mean the last block is processed correctly and the crash
>> happens on the next instruction which doesn't make it to the log?
>> The next instruction would be a
>>
>> 0x00000000011fea30: retl
>>
>> Since it's a branch instruction I guess this would also be a tcg block boundary.
>
> Because abort() was called from tcg_reg_alloc_call, I'd say 'retl'
> (synthetic op for 'jmpl %o8 + 8, %g0') was the problem.
Any idea why? retl is not a rare instruction...
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
^ permalink raw reply
* [PATCH][Trivial] perf: Only include annotate.h once in tools/perf/util/ui/browsers/annotate.c
From: Jesper Juhl @ 2011-04-10 17:46 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Zijlstra, Paul Mackerras, Ingo Molnar,
Arnaldo Carvalho de Melo, trivial
Including "../../annotate.h" once in
tools/perf/util/ui/browsers/annotate.c is enough. No need to do it twice.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
annotate.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/perf/util/ui/browsers/annotate.c b/tools/perf/util/ui/browsers/annotate.c
index 8c17a87..c1360f7 100644
--- a/tools/perf/util/ui/browsers/annotate.c
+++ b/tools/perf/util/ui/browsers/annotate.c
@@ -5,7 +5,6 @@
#include "../../hist.h"
#include "../../sort.h"
#include "../../symbol.h"
-#include "../../annotate.h"
#include <pthread.h>
static void ui__error_window(const char *fmt, ...)
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: [PATCH] kvm tools: Get rid of the double underscore name convension
From: Ingo Molnar @ 2011-04-10 17:40 UTC (permalink / raw)
To: Asias He; +Cc: Pekka Enberg, Cyrill Gorcunov, kvm
In-Reply-To: <1302447926-12686-1-git-send-email-asias.hejun@gmail.com>
* Asias He <asias.hejun@gmail.com> wrote:
> This patch converts double underscore name convension to
> single underscore name convension project wide.
I think the double underscore came from tools/perf/, and there we use it
instead of class::method() - so it's a class__method kind of differentiator
done in C. So it can make sense in that respect, if it's done consistently.
Thanks,
Ingo
^ permalink raw reply
* Re: ipset-6.2 testsuite failure
From: Jan Engelhardt @ 2011-04-10 17:38 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: Netfilter Developer Mailing List
In-Reply-To: <alpine.DEB.2.00.1104072059250.22730@blackhole.kfki.hu>
On Thursday 2011-04-07 21:10, Jozsef Kadlecsik wrote:
>On Thu, 7 Apr 2011, Jan Engelhardt wrote:
>
>> Using 2.6.39-rc1+ (kaber/nf-next) with ipset-6.2 (plain, nfnetlink):
>>
>> jng-0:/home/jengelh/code/ipset/tests # ./runtest.sh
>> hash:ip6: Network: Check listing: passed
>> hash:ip6: Sleep 5s so that elements can time out: passed
>> hash:ip6: Network: List set: passed
>> hash:ip6: Network: Check listing: 6a7
>> > 200:100:10:: timeout 0
>> FAILED
>> Failed test: diff -I 'Size in memory.*' .foo hash:ip6.t.list1 && rm .foo
>> jng-0:/home/jengelh/code/ipset/tests #
>
>I was unable to reproduce this with the kernel from Patrick's tree and
>with ipset-6.2.
>
>However, in the testsuite of ipset-6.2 the hash:ip6 tests are not executed
>just after the ipmap tests: there are missing tests in the listing above.
>
>Also, the testsuite in ipset-6.2 contains the tests against the kernel in
>the package itself: the patches I have submitted today are missing from
>2.6.39-rc1+
Tried with ipset 6.3 and modules from ipset-6.3, and seems to work.
^ permalink raw reply
* Re: Firmware files for Ralink RT28x0
From: Ivo Van Doorn @ 2011-04-10 17:35 UTC (permalink / raw)
To: Xose Vazquez Perez; +Cc: linux-wireless, users
In-Reply-To: <4DA1E90A.5070902@gmail.com>
Hi.
>> I notice that rt2800{pci,usb} each specify only one firmware image,
>> regardless of the controller version.
>>
>> This is inconsistent with rt28{6,7}0sta and with the firmware images in
>> linux-firmware.
>>
>> If you think that a single image per bus type can cover all controllers,
>> please identify those firmware images, test them on each hardware
>> generation, and get them into linux-firmware.
>
> querida:/datos/kernel/linux-2.6/drivers/net/wireless/rt2x00 $ grep "\.bin" *
> rt2800pci.h:#define FIRMWARE_RT2860 "rt2860.bin"
> rt2800usb.h:#define FIRMWARE_RT2870 "rt2870.bin"
> rt61pci.h:#define FIRMWARE_RT2561 "rt2561.bin"
> rt61pci.h:#define FIRMWARE_RT2561s "rt2561s.bin"
> rt61pci.h:#define FIRMWARE_RT2661 "rt2661.bin"
> rt73usb.h:#define FIRMWARE_RT2571 "rt73.bin"
>
> rt3070.bin rt3071.bin rt3090.bin should be deleted from linux-firmware.
> They were only need by staging drivers.
True, but the rt2860 and rt2870 firmware file are outdated in the
linux-firmware,
and probably don't support the rt3090 or other more recent chipsets. So before
they can be removed, those files must be updated.
Ivo
^ 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.