* [PATCH v2 for 2.6.36 1/2] cpuimx27: fix compile when ULPI is selected
From: Eric Bénard @ 2010-10-08 8:37 UTC (permalink / raw)
To: linux-arm-kernel
without this patch we get :
arch/arm/mach-imx/built-in.o: In function `eukrea_cpuimx27_init':
eukrea_mbimx27-baseboard.c:(.init.text+0x44c): undefined reference to `mxc_ulpi_access_ops'
Signed-off-by: Eric B?nard <eric@eukrea.com>
---
v2 : remove SPI's select which leaked in previous patch
arch/arm/mach-imx/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index c5c0369..2f7e272 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -122,6 +122,7 @@ config MACH_CPUIMX27
select IMX_HAVE_PLATFORM_IMX_I2C
select IMX_HAVE_PLATFORM_IMX_UART
select IMX_HAVE_PLATFORM_MXC_NAND
+ select MXC_ULPI if USB_ULPI
help
Include support for Eukrea CPUIMX27 platform. This includes
specific configurations for the module and its peripherals.
--
1.7.0.4
^ permalink raw reply related
* Re: RT on 2.6.34
From: walimis @ 2010-10-08 8:37 UTC (permalink / raw)
To: Esben Haabendal; +Cc: Sven-Thorsten Dietrich, linux-rt-users
In-Reply-To: <87aampt8e0.fsf@eha.doredevelopment.dk>
On Fri, Oct 08, 2010 at 10:07:35AM +0200, Esben Haabendal wrote:
>walimis <walimisdev@gmail.com> writes:
>
>> On Tue, Oct 05, 2010 at 11:40:46PM -0700, Sven-Thorsten Dietrich wrote:
>>> If I read this correctly, WR ported RT to 2.6.34.
>>>
>>> Anyone out there to confirm?
>> Yes, it's true.
>
>Ok, where do I download this from?
there is a open source version of windriver kernel:
git://git.pokylinux.org/linux-2.6-windriver
please try "preempt_rt" branch.
walimis
>
>/Esben
^ permalink raw reply
* Re: [RFC PATCH 1/2] perf_events: add support for per-cpu per-cgroup monitoring (v4)
From: Stephane Eranian @ 2010-10-08 8:36 UTC (permalink / raw)
To: Li Zefan
Cc: eranian, linux-kernel, peterz, mingo, paulus, davem, fweisbec,
perfmon2-devel, robert.richter, acme
In-Reply-To: <4CAE69E5.5080007@cn.fujitsu.com>
On Fri, Oct 8, 2010 at 2:46 AM, Li Zefan <lizf@cn.fujitsu.com> wrote:
>>>>> +#ifdef CONFIG_CGROUPS
>>>>> +struct perf_cgroup_time {
>>>>> + u64 time;
>>>>> + u64 timestamp;
>>>>> +};
>>>>> +
>>>>> +struct perf_cgroup {
>>>>> + struct cgroup_subsys_state css;
>>>>> + struct perf_cgroup_time *time;
>>>>> +};
>>>> Can we avoid adding this perf cgroup subsystem? It has 2 disavantages:
>>>>
>>> Well, I need to maintain some timing information for each cgroup. This has
>>> to be stored somewhere.
>>>
>
> Seems you can simply store it in struct perf_event?
>
No, timing has to be shared by events monitoring the same cgroup at
the same time.
Works like a timestamp. It needs to be centralized for all events
attached to the same
cgroup.
>>>> - If one mounted cgroup fs without perf cgroup subsys, he can't monitor it.
>>> That's unfortunately true ;-)
>>>
>>>> - If there are several different cgroup mount points, only one can be
>>>> monitored.
>>>>
>>>> To choose which cgroup hierarchy to monitor, hierarchy id can be passed
>>>> from userspace, which is the 2nd column below:
>>>>
>>> Ok, I will investigate this. As long as the hierarchy id is unique AND it can be
>>> searched, then we can use it. Using /proc is fine with me.
>>>
>>>> $ cat /proc/cgroups
>>>> #subsys_name hierarchy num_cgroups enabled
>>>> debug 0 1 1
>>>> net_cls 0 1 1
>>>>
>>
>> If I mount all subsystems:
>> mount -t cgroup none /dev/cgroup
>> Then, I get:
>> #subsys_name hierarchy num_cgroups enabled
>> cpuset 1 1 1
>> cpu 1 1 1
>> perf_event 1 1 1
>>
>> In other words, the hierarchy id is not unique.
>> If the perf_event is not mounted, then hierarchy id = 0.
>>
>
> Yes, it's unique. ;)
>
> You mounted them together, and that's a cgroup hierarchy, so
> they have the same hierarchy id.
>
> If you mount them seperately:
>
> # mount -t cgroup -o debug xxx /cgroup1
> # mount -t cgroup -o net_cls xxx /cgroup2/
> # cat /proc/cgroups
> #subsys_name hierarchy num_cgroups enabled
> debug 1 1 1
> net_cls 2 1 1
>
Ok, but if you mount perf_event twice, you get the
same hierarchy id for it:
# mount -t cgroup -operf_event none /cgroup
# cat /proc/cgroups
#subsys_name hierarchy num_cgroups enabled
cpuset 0 1 1
cpu 0 1 1
perf_event 1 1 1
# mount -t cgroup -operf_event none /cgroup2
# cat /proc/cgroups
#subsys_name hierarchy num_cgroups enabled
cpuset 0 1 1
cpu 0 1 1
perf_event 1 1 1
It does not seem like I can mount the same subsystem
twice with difference hierarchies:
# umount /cgroup2
# mount -t cgroup -operf_event,cpuset none /cgroup2
mount: none already mounted or /cgroup2 busy
# mount -t cgroup none /cgroup2
mount: none already mounted or /cgroup2 busy
> They now have different hierarchy id, because they belong
> to different cgroup hierarchy.
>
> So pid + hierarchy_id locates the cgroup.
>
I cannot do task's pid + cgroup hierarchy_id. It's one or the
other.
>> I have tried mounting cgroupfs in multiple places at the same
>> time. Whatever directory I used, I got to the right css.
>>
>> Am I missing your point here?
>>
>
> I should use the words "cgroup hierarchies" instead of mount points..
>
Can you mount the same subsystem multiple times with DIFFERENT
hierarchies?
^ permalink raw reply
* Re: [PATCH] Fix problem with invalid read from array
From: Lukasz Pawlik @ 2010-10-08 8:35 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <AANLkTim4WEh7ZLTiWbhiWcv1VXV+jpb_V8NqJjeq=OzH@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]
Attaching patch without change in src/adapter.c file.
Lukasz Pawlik
2010/10/6 Lukasz Pawlik <lucas.pawlik@gmail.com>:
> Hi,
>
> Sorry. My bad. It was never my intention to change src/adapter.c. I've
> prepared two patches with the same name and of course send the wrong
> one. Problem with invalid read fix change made in src/sdpd-service.c
> file.
>
> Lukasz
>
> 2010/10/6 Johan Hedberg <johan.hedberg@gmail.com>:
>> Hi Lukasz,
>>
>> On Wed, Oct 06, 2010, Lukasz Pawlik wrote:
>>> This patch fix problem with reading data from out of the array range in
>>> function used to create EIR response.
>>
>> You'll need to explain in more detail exactly what was wrong with the
>> old code and how your patch fixes it (and why it is the correct fix).
>>
>>> - uint8_t data[240];
>>> + uint8_t data[242];
>>
>> Why 242? The core spec defines the EIR data as a 240 byte field.
>>
>>> - uuid128_data[SIZEOF_UUID128 - k])
>>> + uuid128_data[SIZEOF_UUID128 - 1 - k])
>>
>> This change looks fine (the index of the last byte is sizeof(uuid128) - 1).
>>
>> Johan
>>
>
[-- Attachment #2: 0001-Fix-problem-with-invalid-read-from-array.patch --]
[-- Type: text/x-patch, Size: 876 bytes --]
From 5e6ca8e9dff0ced5aacc1cbfa12318680ade957a Mon Sep 17 00:00:00 2001
From: Lukasz Pawlik <lucas.pawlik@gmail.com>
Date: Fri, 8 Oct 2010 09:23:26 +0200
Subject: [PATCH] Fix problem with invalid read from array
This patch fix problem with reading data from out of the array range in
function used to create EIR response.
---
src/sdpd-service.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/sdpd-service.c b/src/sdpd-service.c
index 26ab9a5..67dd9af 100644
--- a/src/sdpd-service.c
+++ b/src/sdpd-service.c
@@ -204,7 +204,7 @@ static void eir_generate_uuid128(sdp_list_t *list,
for (i = 0; i < index; i++) {
for (k = 0; k < SIZEOF_UUID128; k++) {
if (uuid128[i * SIZEOF_UUID128 + k] !=
- uuid128_data[SIZEOF_UUID128 - k])
+ uuid128_data[SIZEOF_UUID128 - 1 - k])
break;
}
if (k == SIZEOF_UUID128)
--
1.7.0.4
^ permalink raw reply related
* Re: Re: build break in xl.c in python
From: Gianni Tedesco @ 2010-10-08 8:33 UTC (permalink / raw)
To: Kay, Allen M; +Cc: Xen-devel, Vincent Hanquez, Stefano Stabellini
In-Reply-To: <1286526537.12843.130.camel@qabil.uk.xensource.com>
On Fri, 2010-10-08 at 09:28 +0100, Gianni Tedesco wrote:
> On Fri, 2010-10-08 at 01:28 +0100, Kay, Allen M wrote:
> > I'm getting a build break in python xl code. Looks like the following changeset did not make the corresponding parameter change from the caller site in python:
> >
> > -static int do_pci_remove(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev)
> > +static int do_pci_remove(libxl__gc *gc, uint32_t domid,
> > + libxl_device_pci *pcidev, int force)
> >
> >
> > Changeset:
> >
> > 31 hours ago: xl: Implement PCI passthrough force removal
> > changeset 22229: 1385b15e168f
> > tag: tip
> > author: Gianni Tedesco <gianni.tedesco@citrix.com>
> > date: Wed Oct 06 17:38:15 2010 +0100
> > files: tools/libxl/libxl.h tools/libxl/libxl_pci.c tools/libxl/xl_cmdimpl.c
>
> You are right, I should have realised! It also breaks the ocaml binding.
>
> Vincent, I have patched this so that it builds but perhaps you want to
> expose the new PCI force removal in the ocaml binding? I just set
> 'force' parameter to always be zero for now to keep it building and
> running same as before.
Actually, ignore the deliberate mistake in python part of that patch :)
Correct patch is below:
---
xl: Fix build in python binding since API change in 22229:1385b15e168f
Signed-off-by: Gianni Tedesco <gianni.tedesco@citrix.com>
diff -r 1385b15e168f tools/ocaml/libs/xl/xl_stubs.c
--- a/tools/ocaml/libs/xl/xl_stubs.c Wed Oct 06 17:38:15 2010 +0100
+++ b/tools/ocaml/libs/xl/xl_stubs.c Fri Oct 08 09:33:27 2010 +0100
@@ -638,7 +638,7 @@ value stub_xl_pci_remove(value info, val
device_pci_val(&gc, &c_info, info);
INIT_CTX();
- ret = libxl_device_pci_remove(&ctx, Int_val(domid), &c_info);
+ ret = libxl_device_pci_remove(&ctx, Int_val(domid), &c_info, 0);
if (ret != 0)
failwith_xl("pci_remove", &lg);
FREE_CTX();
diff -r 1385b15e168f tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c Wed Oct 06 17:38:15 2010 +0100
+++ b/tools/python/xen/lowlevel/xl/xl.c Fri Oct 08 09:33:27 2010 +0100
@@ -441,15 +441,16 @@ static PyObject *pyxl_pci_del(XlObject *
{
Py_device_pci *pci;
PyObject *obj;
- int domid;
- if ( !PyArg_ParseTuple(args, "iO", &domid, &obj) )
+ int domid, force = 0;
+
+ if ( !PyArg_ParseTuple(args, "iO|i", &domid, &obj, &force) )
return NULL;
if ( !Pydevice_pci_Check(obj) ) {
PyErr_SetString(PyExc_TypeError, "Xxpected xl.device_pci");
return NULL;
}
pci = (Py_device_pci *)obj;
- if ( libxl_device_pci_remove(&self->ctx, domid, &pci->obj) ) {
+ if ( libxl_device_pci_remove(&self->ctx, domid, &pci->obj, force) ) {
PyErr_SetString(xl_error_obj, "cannot remove pci device");
return NULL;
}
^ permalink raw reply
* Re: [PATCH] fast-import: Allow filemodify to set the root
From: Gabriel Filion @ 2010-10-08 8:33 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: David Barr, Git Mailing List, Jonathan Nieder, Sverre Rabbelier,
Johannes Sixt
In-Reply-To: <20101008081509.GA2845@kytes>
Hello,
On 2010-10-08 04:15, Ramkumar Ramachandra wrote:
> diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
> index 966ba4f..90a4666 100644
> --- a/Documentation/git-fast-import.txt
> +++ b/Documentation/git-fast-import.txt
> @@ -524,6 +524,9 @@ start with double quote (`"`).
> If an `LF` or double quote must be encoded into `<path>` shell-style
> quoting should be used, e.g. `"path/with\n and \" in it"`.
>
> +Additionally, in `040000` mode, `<path>` may also be an empty string
> +(`""`) to specify the root of the tree.
> +
> The value of `<path>` must be in canonical form. That is it must not:
>
> * contain an empty directory component (e.g. `foo//bar` is invalid),
Thanks for keeping documentation up to date :)
Although, I think the documentation should be a bit more precise about
what "specifying the root of the tree" means for a 'filemodify' command
and its implication on performance (i.e. why there's actually this
special case in the syntax)
--
Gabriel Filion
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_uart: Fix typo in stats for sco tx
From: Marcel Holtmann @ 2010-10-08 8:33 UTC (permalink / raw)
To: Karl Beldan; +Cc: Jiri Kosina, linux-bluetooth
In-Reply-To: <1286481430-6761-1-git-send-email-karl.beldan@gmail.com>
Hi Karl,
> s/stat.cmd_tx++/stat.sco_tx++ for HCI_SCODATA_PKT
>
> Signed-off-by: Karl Beldan <karl.beldan@gmail.com>
> Cc: Marcel Holtmann <marcel@holtmann.org>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* RE: [RFC PATCH] staging: iio: adc: ad7476 new SPI ADC driver
From: Hennerich, Michael @ 2010-10-08 8:33 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: linux-iio@vger.kernel.org, Drivers
In-Reply-To: <4CAE0097.5020702@cam.ac.uk>
Jonathan Cameron wrote on 2010-10-07:
> On 10/07/10 15:36, michael.hennerich@analog.com wrote:
>> From: Michael Hennerich <michael.hennerich@analog.com>
>>
> Hi Michael,
>
> Just a quick look tonight, I'll take a closer one tomorrow.
>
>> New driver handling: AD7475, AD7476, AD7477, AD7478, AD7466, AD7=
467,
>> AD7468, AD7495 SPI micropower and high speed 12-/10-/8-Bit ADCs
>>
>> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
>> ---
>> drivers/staging/iio/adc/ad7476.h | 66 +++++++
>> drivers/staging/iio/adc/ad7476_core.c | 324
>> +++++++++++++++++++++++++++++++++
>> drivers/staging/iio/adc/ad7476_ring.c | 184 +++++++++++++++++++
>> 3 files changed, 574 insertions(+), 0 deletions(-) create mode
>> 100644 drivers/staging/iio/adc/ad7476.h create mode 100644
>> drivers/staging/iio/adc/ad7476_core.c
>> create mode 100644 drivers/staging/iio/adc/ad7476_ring.c
>> diff --git a/drivers/staging/iio/adc/ad7476.h
>> b/drivers/staging/iio/adc/ad7476.h
>> new file mode 100644
>> index 0000000..499a773
>> --- /dev/null
>> +++ b/drivers/staging/iio/adc/ad7476.h
>> @@ -0,0 +1,66 @@
>> +/*
>> + * AD7476/5/7/8 (A) SPI ADC driver
>> + *
>> + * Copyright 2010 Analog Devices Inc.
>> + *
>> + * Licensed under the GPL-2 or later.
>> + */
>> +#ifndef IIO_ADC_AD7476_H_
>> +#define IIO_ADC_AD7476_H_
>> +
>> +#define RES_MASK(bits) ((1 << (bits)) - 1)
>> +
>> +/*
>> + * TODO: struct ad7476_platform_data needs to go into
>> +include/linux/iio */
>> +
>> +struct ad7476_platform_data {
>> + char name[12];
> Why provide the name as platform data? Isn't an appropriate id table
> and correct board info for the spi bus a better bet?
>
> The id stuff hasn't been available for spi devices for that long, but
> it is now and makes things a lot easier. Similar to i2c but you have
> to use spi_get_device_id to get it from the spi_device struct.
Yeah - of course that's even better - I didn't know that this was added to
the spi bus driver recently - I'll update.
>> + unsigned int vref_mv; +}; + +struct ad7476_chip_=
info {
>> + char name[12]; Easier as a const char * =
and appropriate const
>> string asignment? + u8 bits; + u8 =
storagebits; + u8 res_sh=
ift;
>> + char sign; + unsigned int =
int_vref_mv; + struct
>> attribute_group *scan_attrs; +};
> I'll look at the rest tomorrow.
>
>
> Jonathan
Greetings,
Michael
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036 Geschaeft=
sfuehrer Thomas Wessel, William A. Martin, Margaret Seif
^ permalink raw reply
* [Qemu-devel] [PATCH] tcg: Fix compiler error (comparison of unsigned expression)
From: Stefan Weil @ 2010-10-08 8:32 UTC (permalink / raw)
To: QEMU Developers; +Cc: Blue Swirl, Hollis Blanchard
In-Reply-To: <AANLkTi=AFOyVNAtvQ_1s6LW=S9WiW4Z6vkGOZWExctE6@mail.gmail.com>
When qemu is configured with --enable-debug-tcg,
gcc throws this warning (or error with -Werror):
tcg/tcg.c:1030: error: comparison of unsigned expression >= 0 is always true
Fix it by removing the >= 0 part.
The type cast to 'unsigned' catches negative values of op
(which should never happen).
This is a modification of Hollis Blanchard's patch.
Cc: Hollis Blanchard <hollis@penguinppc.org>
Cc: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
---
tcg/tcg.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tcg/tcg.c b/tcg/tcg.c
index e0a9030..0cdef0d 100644
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -1027,7 +1027,7 @@ void tcg_add_target_add_op_defs(const TCGTargetOpDef *tdefs)
if (tdefs->op == (TCGOpcode)-1)
break;
op = tdefs->op;
- assert(op >= 0 && op < NB_OPS);
+ assert((unsigned)op < NB_OPS);
def = &tcg_op_defs[op];
#if defined(CONFIG_DEBUG_TCG)
/* Duplicate entry in op definitions? */
--
1.7.1
^ permalink raw reply related
* [U-Boot] [PATCH V2 3/3] Kirkwood: Changes specific to ARM relocation support
From: Wolfgang Denk @ 2010-10-08 8:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4CAECE3E.6020305@free.fr>
Dear Albert ARIBAUD,
In message <4CAECE3E.6020305@free.fr> you wrote:
>
> BTW, Wolfgang, is your offer to provide a branch to put ELF relocation
> related changes still valid? Even periodically rebased against master
> would be perfect... Otherwise I can set one up if you prefer.
Of course this is still valid, but
- I'm late with updating the u-boot-arm repo because I got stuck in
this "little" task I started to make some progress with the Makefile
/ boards.cfg cleanup (that turned out to burn more time than
expected)
- I lost a bit track of which exact version of the patches I should
use. If you could please be so kind and send me a short reference to
the current ones (messag-ID or similar).
Thanks.
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
"I find this a nice feature but it is not according to the documen-
tation. Or is it a BUG?" "Let's call it an accidental feature. :-)"
- Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>
^ permalink raw reply
* Re: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging
From: Marcel Holtmann @ 2010-10-08 8:32 UTC (permalink / raw)
To: Alan Cox
Cc: Savoy, Pavan, Jiri Slaby, gregkh@suse.de,
linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
linux-bluetooth
In-Reply-To: <20101007213503.657bcab0@lxorguk.ukuu.org.uk>
Hi Alan,
> > ldisc is the ONLY way to do it, isn't it? Do I have any other option?
>
> Userspace but even then it wouldn't solve your problem
>
> > The situation was something similar here.
> > What I was trying to get to is how we can have a per-device context if a driver is just a line discipline driver?
>
> tty->driver_data
> TTY private data
> tty->disc_data
> LDISC per instance private data
>
> So when your ldisc is opened attach your data to the tty->disc_data, and
> when it is closed free the data.
>
> > I have 3 sub-devices if you will on a device which is interfaced over UART,
> > One of them is Bluetooth which requires any UART Bluetooth device to have its
> > Own line discipline - N_HCI.
>
> The problem is that your chip by the sound of it does not talk the
> bluetooth ldisc - it talks something more complex.
>
> The obvious question then is
>
> Does it talk
>
> 1. HCI with bits nailed on
> 2. Something rather different which contains muxed data some of
> which is reformatted up to create HCI
>
> In the first case it may be worth seeing if the existing N_HCI could
> support forwarding unknown frame types to a helper. In the latter it's a
> lot trickier. It is possible to create a mux tty layer (see n_gsm.c) but
> that is almost certainly overkill for this.
>
> I wonder what Marcel thinks in terms of re-using the bluetooth ldisc ?
If you get a sane proposal, then yes, N_HCI could act as multiplexer and
forward certain frame types.
This all depends on how clear the separation is. If you expect to send
HCI commands from these "clients" then there is a problem with the
Bluetooth subsystem and its enforced flow control. You don't wanna mess
with that since it has side effects. And I am not giving outside drivers
real control over. The Bluetooth drivers have to stay dumb transport
drivers without any Bluetooth core logic.
So can you give me a few quick hints on what you would need to forward
actually.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Fix SRAO/SRAR MCE injecting on guest without MCG_SER_P
From: Hidetoshi Seto @ 2010-10-08 8:31 UTC (permalink / raw)
To: Huang Ying
Cc: Avi Kivity, Marcelo Tosatti, kvm@vger.kernel.org, Andi Kleen,
Dean Nelson
In-Reply-To: <1286526314.7768.97.camel@yhuang-dev>
(2010/10/08 17:25), Huang Ying wrote:
> On real machine, if MCG_SER_P in MSR_MCG_CAP is not set, SRAO/SRAR MCE
> should not be raised by hardware. This patch makes QEMU-KVM to follow
> the same rule.
>
> Reported-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
> Signed-off-by: Huang Ying <ying.huang@intel.com>
> ---
> qemu-kvm.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> --- a/qemu-kvm.c
> +++ b/qemu-kvm.c
> @@ -1134,7 +1134,7 @@ static void sigbus_handler(int n, struct
> void *ctx)
> {
> #if defined(KVM_CAP_MCE) && defined(TARGET_I386)
> - if (first_cpu->mcg_cap && siginfo->ssi_addr
> + if ((first_cpu->mcg_cap & MCG_SER_P) && siginfo->ssi_addr
> && siginfo->ssi_code == BUS_MCEERR_AO) {
> uint64_t status;
> void *vaddr;
> @@ -1324,7 +1324,7 @@ static void kvm_on_sigbus(CPUState *env,
> unsigned long paddr;
> int r;
>
> - if (env->mcg_cap && siginfo->si_addr
> + if ((env->mcg_cap & MCG_SER_P) && siginfo->si_addr
> && (siginfo->si_code == BUS_MCEERR_AR
> || siginfo->si_code == BUS_MCEERR_AO)) {
> if (siginfo->si_code == BUS_MCEERR_AR) {
> @@ -1356,7 +1356,7 @@ static void kvm_on_sigbus(CPUState *env,
> if (do_qemu_ram_addr_from_host(vaddr, &ram_addr) ||
> !kvm_physical_memory_addr_from_ram(kvm_state, ram_addr, (target_phys_addr_t *)&paddr)) {
> fprintf(stderr, "Hardware memory error for memory used by "
> - "QEMU itself instaed of guest system!\n");
> + "QEMU itself instead of guest system!\n");
> /* Hope we are lucky for AO MCE */
> if (siginfo->si_code == BUS_MCEERR_AO) {
> return;
Reviewed-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Thanks,
H.Seto
^ permalink raw reply
* Re: [PATCH 2/2] configure.in: don't rely on test -a, not all shells support it
From: Simon McVittie @ 2010-10-08 8:31 UTC (permalink / raw)
To: alsa-devel
In-Reply-To: <20101008080658.GA11099@reptile.pseudorandom.co.uk>
[-- Attachment #1.1: Type: text/plain, Size: 397 bytes --]
On Fri, 08 Oct 2010 at 09:06:58 +0100, Simon McVittie wrote:
> Notably, /bin/sh in Debian and Ubuntu is dash, which doesn't.
Sorry, I'd misinterpreted the error produced when grep fails (fixed by patch
1/2). Recent dash versions do support test -a, so patch 2/2 turns out to be
unnecessary on current Debian, although it might conceivably be useful for
backports to older Ubuntu versions.
S
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH v2] procfs: fix numbering in /proc/locks
From: Jerome Marchand @ 2010-10-08 8:29 UTC (permalink / raw)
To: Andrew Morton
Cc: Matthew Wilcox, Pavel Emelyanov, Linux Kernel Mailing List,
xiyou.wangcong
In-Reply-To: <20101007162702.7db08f5b.akpm@linux-foundation.org>
On 10/08/2010 01:27 AM, Andrew Morton wrote:
> On Tue, 05 Oct 2010 14:14:11 +0200
> Jerome Marchand <jmarchan@redhat.com> wrote:
>
>> On 09/30/2010 02:38 PM, Jerome Marchand wrote:
>>>
>>> The lock number in /proc/locks (first field) is implemented by a counter
>>> (private field of struct seq_file) which is incremented at each call of
>>> locks_show() and reset to 1 in locks_start() whatever the offset is. It
>>> should be reset according to the actual position in the list.
>>>
>>> Moreover, locks_show() can be called twice to print a single line thus
>>> skipping a number. The counter should be incremented in locks_next().
>>>
>>> Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
>>> ---
>>> locks.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fs/locks.c b/fs/locks.c
>>> index ab24d49..49d7343 100644
>>> --- a/fs/locks.c
>>> +++ b/fs/locks.c
>>> @@ -2166,19 +2166,19 @@ static int locks_show(struct seq_file *f, void *v)
>>> list_for_each_entry(bfl, &fl->fl_block, fl_block)
>>> lock_get_status(f, bfl, (long)f->private, " ->");
>>>
>>> - f->private++;
>>> return 0;
>>> }
>>>
>>> static void *locks_start(struct seq_file *f, loff_t *pos)
>>> {
>>> lock_kernel();
>>> - f->private = (void *)1;
>>> + f->private = (void *) (*pos + 1);
>>
>> That cast trigger a warning on some arch:
>> "warning: cast to pointer from integer of different size"
>>
>> There is no real risk here. At worst /proc/locks will show wrong number
>> if there is more than 2^32 locks, but should I mute the warning it with
>> something like:
>> f->private = (void *) (size_t) (*pos + 1);
>> ?
>
> Putting a loff_t into a void* is a pretty alarming thing to do. If
> we're really going to do that then use a (long) cast and put a very
> good comment at the code site explaining why the bug doesn't matter, so
> people aren't misled.
>
> But really, why sweat it? kmalloc the eight bytes, make ->private
> point at that and we never have to think about it again. Bonus points
> for doing this without any typecasts ;)
>
That's definitely cleaner. I'll do that.
Thanks,
Jerome
^ permalink raw reply
* Re: build break in xl.c in python
From: Gianni Tedesco @ 2010-10-08 8:28 UTC (permalink / raw)
To: Kay, Allen M; +Cc: Xen-devel, Vincent Hanquez, Stefano Stabellini
In-Reply-To: <987664A83D2D224EAE907B061CE93D530163EA9749@orsmsx505.amr.corp.intel.com>
On Fri, 2010-10-08 at 01:28 +0100, Kay, Allen M wrote:
> I'm getting a build break in python xl code. Looks like the following changeset did not make the corresponding parameter change from the caller site in python:
>
> -static int do_pci_remove(libxl__gc *gc, uint32_t domid, libxl_device_pci *pcidev)
> +static int do_pci_remove(libxl__gc *gc, uint32_t domid,
> + libxl_device_pci *pcidev, int force)
>
>
> Changeset:
>
> 31 hours ago: xl: Implement PCI passthrough force removal
> changeset 22229: 1385b15e168f
> tag: tip
> author: Gianni Tedesco <gianni.tedesco@citrix.com>
> date: Wed Oct 06 17:38:15 2010 +0100
> files: tools/libxl/libxl.h tools/libxl/libxl_pci.c tools/libxl/xl_cmdimpl.c
You are right, I should have realised! It also breaks the ocaml binding.
Vincent, I have patched this so that it builds but perhaps you want to
expose the new PCI force removal in the ocaml binding? I just set
'force' parameter to always be zero for now to keep it building and
running same as before.
---
xl: Fix build in python binding since API change in 22229:1385b15e168f
Signed-off-by: Gianni Tedesco <gianni.tedesco@citrix.com>
diff -r 1385b15e168f tools/ocaml/libs/xl/xl_stubs.c
--- a/tools/ocaml/libs/xl/xl_stubs.c Wed Oct 06 17:38:15 2010 +0100
+++ b/tools/ocaml/libs/xl/xl_stubs.c Fri Oct 08 09:25:22 2010 +0100
@@ -638,7 +638,7 @@ value stub_xl_pci_remove(value info, val
device_pci_val(&gc, &c_info, info);
INIT_CTX();
- ret = libxl_device_pci_remove(&ctx, Int_val(domid), &c_info);
+ ret = libxl_device_pci_remove(&ctx, Int_val(domid), &c_info, 0);
if (ret != 0)
failwith_xl("pci_remove", &lg);
FREE_CTX();
diff -r 1385b15e168f tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c Wed Oct 06 17:38:15 2010 +0100
+++ b/tools/python/xen/lowlevel/xl/xl.c Fri Oct 08 09:25:22 2010 +0100
@@ -441,15 +441,16 @@ static PyObject *pyxl_pci_del(XlObject *
{
Py_device_pci *pci;
PyObject *obj;
- int domid;
- if ( !PyArg_ParseTuple(args, "iO", &domid, &obj) )
+ int domid, force = 0;
+
+ if ( !PyArg_ParseTuple(args, "iO|i", &domid, &obj) )
return NULL;
if ( !Pydevice_pci_Check(obj) ) {
PyErr_SetString(PyExc_TypeError, "Xxpected xl.device_pci");
return NULL;
}
pci = (Py_device_pci *)obj;
- if ( libxl_device_pci_remove(&self->ctx, domid, &pci->obj) ) {
+ if ( libxl_device_pci_remove(&self->ctx, domid, &pci->obj, force) ) {
PyErr_SetString(xl_error_obj, "cannot remove pci device");
return NULL;
}
^ permalink raw reply
* [Bug 29367] [KMS] Assertion `boi->space_accounted' failed. on rv280
From: bugzilla-daemon @ 2010-10-08 8:28 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-29367-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=29367
--- Comment #5 from Andrew Randrianasulu <randrik@mail.ru> 2010-10-08 01:28:21 PDT ---
(In reply to comment #4)
> Could you try the patch in bug 21374 which looks like a similar issue?
Patch from https://bugs.freedesktop.org/show_bug.cgi?id=21374#c5 not
applicable to latest mesa without modifications. I'll try to apply it manually,
but right now i have different card in AGP slot, so testing will take some
time. Thanks for pointer!
--
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
* [Buildroot] buildroot not support c++ compliing
From: Phil Edworthy @ 2010-10-08 8:28 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1286525870.3703.16.camel@olyvine-desktop.logiways-sz.cn>
Hi Olyvine,
> > Which external toolchain are you using ?
> >
> > Thomas
>
> STLinux's sh4-linux-
I'm using CodeSourcery's sh4 toolchain for Renesas devices, this works fine
for me. It might be worth trying it:
http://www.codesourcery.com/sgpp/lite/superh
Phil
^ permalink raw reply
* [PATCH 3/3] mx51: Move OTG initialisation for all boards to a single file
From: Amit Kucheria @ 2010-10-08 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101007074853.GZ28242@pengutronix.de>
On Thu, Oct 7, 2010 at 10:48 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> Added Daniel to Cc as he might say something here aswell.
>
> On Thu, Oct 07, 2010 at 03:58:48AM +0300, Amit Kucheria wrote:
>> The OTG initialisation is the same for all MX51 boards currently known. Move
>> to a common file.
>>
>> Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
>> ---
>> ?arch/arm/mach-mx5/Makefile ? ? ? ? ? ? | ? ?2 +-
>> ?arch/arm/mach-mx5/board-cpuimx51.c ? ? | ? 25 +-------------------
>> ?arch/arm/mach-mx5/board-mx51_babbage.c | ? 25 +-------------------
>> ?arch/arm/mach-mx5/board-mx51_efikamx.c | ? 23 +-----------------
>> ?arch/arm/mach-mx5/usb.c ? ? ? ? ? ? ? ?| ? 40 ++++++++++++++++++++++++++++++++
>> ?5 files changed, 44 insertions(+), 71 deletions(-)
>> ?create mode 100644 arch/arm/mach-mx5/usb.c
>>
>> diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
>> index d1aac9c..1daba15 100644
>> --- a/arch/arm/mach-mx5/Makefile
>> +++ b/arch/arm/mach-mx5/Makefile
>> @@ -3,7 +3,7 @@
>> ?#
>>
>
> [snip]
>
>> ?{
>> ? ? ? u32 v;
>> diff --git a/arch/arm/mach-mx5/board-mx51_efikamx.c b/arch/arm/mach-mx5/board-mx51_efikamx.c
>> index b00502a..93734ae 100644
>> --- a/arch/arm/mach-mx5/board-mx51_efikamx.c
>> +++ b/arch/arm/mach-mx5/board-mx51_efikamx.c
>> @@ -37,7 +37,7 @@
>> ?#include "devices-imx51.h"
>> ?#include "devices.h"
>>
>> -#define ? ? ?MX51_USB_PLL_DIV_24_MHZ 0x01
>> +extern int initialize_otg_port(struct platform_device *pdev);
>>
>> ?static struct pad_desc mx51efikamx_pads[] = {
>> ? ? ? /* UART1 */
>> @@ -65,27 +65,6 @@ static inline void mxc_init_imx_uart(void)
>> ?}
>> ?#endif /* SERIAL_IMX */
>>
>> -/* This function is board specific as the bit mask for the plldiv will also
>> - * be different for other Freescale SoCs, thus a common bitmask is not
>> - * possible and cannot get place in /plat-mxc/ehci.c.
>> - */
>> -static int initialize_otg_port(struct platform_device *pdev)
>> -{
>> - ? ? u32 v;
>> - ? ? void __iomem *usb_base;
>> - ? ? void __iomem *usbother_base;
>> - ? ? usb_base = ioremap(MX51_OTG_BASE_ADDR, SZ_4K);
>> - ? ? usbother_base = (void __iomem *)(usb_base + MX5_USBOTHER_REGS_OFFSET);
>> -
>> - ? ? /* Set the PHY clock to 19.2MHz */
>> - ? ? v = __raw_readl(usbother_base + MXC_USB_PHY_CTR_FUNC2_OFFSET);
>> - ? ? v &= ~MX5_USB_UTMI_PHYCTRL1_PLLDIV_MASK;
>> - ? ? v |= MX51_USB_PLL_DIV_24_MHZ;
>> - ? ? __raw_writel(v, usbother_base + MXC_USB_PHY_CTR_FUNC2_OFFSET);
>> - ? ? iounmap(usb_base);
>> - ? ? return 0;
>> -}
>> -
>> ?static struct mxc_usbh_platform_data dr_utmi_config = {
>> ? ? ? .init ? = initialize_otg_port,
>> ? ? ? .portsc = MXC_EHCI_UTMI_16BIT,
>> diff --git a/arch/arm/mach-mx5/usb.c b/arch/arm/mach-mx5/usb.c
>> new file mode 100644
>> index 0000000..277f957
>> --- /dev/null
>> +++ b/arch/arm/mach-mx5/usb.c
>> @@ -0,0 +1,40 @@
>> +/*
>> + * Copyright (C) 2010 Linaro Limited
>> + *
>> + * The code contained herein is licensed under the GNU General Public
>> + * License. You may obtain a copy of the GNU General Public License
>> + * Version 2 or later at the following locations:
>> + *
>> + * http://www.opensource.org/licenses/gpl-license.html
>> + * http://www.gnu.org/copyleft/gpl.html
>> + */
>> +
>> +#include <linux/platform_device.h>
>> +#include <linux/io.h>
>> +
>> +#include <mach/hardware.h>
>> +#include <mach/mxc_ehci.h>
>> +
>> +#define ? ? ?MX51_USB_PLL_DIV_24_MHZ 0x01
>> +
>> +/* This function is SoC specific as the bit mask for the plldiv will also
>> + * be different for other Freescale SoCs, thus a common bitmask is not
>> + * possible and cannot get place in /plat-mxc/ehci.c.
>> + */
>> +int initialize_otg_port(struct platform_device *pdev)
>> +{
>
> First of all please do not introduce global functions without the
> correct prefix, mx51_ in this case.
>
> I have recently looked at the way the USB phy settings are handled on
> i.MX and it's coming to its limits. Currently the phy settings are coded
> into generic flags, passed to the usb driver which then calls
> mxc_initialize_usb_hw() which dispatches the different SoCs and translates
> the generic flags back into SoC specific ones. ?While this was doable
> until now it fails badly on i.MX51 as we see here.
> The phy settings are totally static to a given board, so we could simply
> let the board call a mx51_init_usb_phy() which gets a pointer to a
> struct with all relevant register settings. And we could pass this
> function SoC specific register settings without having to encode them
> into generic flags and decode them again later.
OK, working on a patch for mx51 now. It it looks ok, I can convert the rest.
/Amit
^ permalink raw reply
* [PATCH] mxc_udc: add workaround for ENGcm09152 for i.MX35
From: Eric Bénard @ 2010-10-08 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1286196058-2395-1-git-send-email-eric@eukrea.com>
Hi Sascha, Hi Dinh,
Le 04/10/2010 14:40, Eric B?nard a ?crit :
> this patch gives the possibility to workaround bug ENGcm09152
> on i.MX35 when the hardware workaround is also implemented on
> the board.
>
Do you have any feedback on this patch ?
It covers the workaround described on page 25 of the following Errata :
http://cache.freescale.com/files/dsp/doc/errata/IMX35CE.pdf
Thanks
Eric
^ permalink raw reply
* RE: RFC: btusb firmware load help
From: Marcel Holtmann @ 2010-10-08 8:26 UTC (permalink / raw)
To: Johannes Berg
Cc: Shanmugamkamatchi Balashanmugam, Luis Rodriguez, linux-bluetooth,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
Deepak Dhamdhere, Sree Durbha
In-Reply-To: <1286474359.20974.13.camel@jlt3.sipsolutions.net>
Hi Johannes,
> > I am still trying to figure out if this is one stage firmware loading or
> > a two stage firmware loading. This is all pretty unclear and nobody has
> > answered this clearly so far.
>
> afaict, it's just one stage -- either it has sflash and you load ath3k
> firmware over it (the problematic 3002-before-loading case), or it
> doesn't have any firmware (and comes up with 3000) and you load the same
> ath3k firmware over it with a different mechanism, which currently
> announces itself as 3002 but can be changed.
sounds a lot better than what I understood initially. So essentially the
PID assigned for their different devices got screwed up. So that needs
to be fixed now.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v2] x86/therm_throt.c: Fix error handling in thermal_throttle_add_dev
From: Ingo Molnar @ 2010-10-08 8:26 UTC (permalink / raw)
To: Fenghua Yu
Cc: H Peter Anvin, Thomas Gleixner, Guenter Roeck, Jean Delvare,
Jin Dongming, Hidetoshi Seto, linux-kernel, lm-sensors
In-Reply-To: <1283905550-18571-1-git-send-email-fenghua.yu@intel.com>
* Fenghua Yu <fenghua.yu@intel.com> wrote:
> #ifdef CONFIG_HOTPLUG_CPU
> mutex_unlock(&therm_cpu_lock);
> #endif
> +#ifdef CONFIG_HOTPLUG_CPU
> + mutex_unlock(&therm_cpu_lock);
> +#endif
That's all very ugly.
Thanks,
Ingo
^ permalink raw reply
* Re: [lm-sensors] [PATCH v2] x86/therm_throt.c: Fix error handling
From: Ingo Molnar @ 2010-10-08 8:26 UTC (permalink / raw)
To: Fenghua Yu
Cc: H Peter Anvin, Thomas Gleixner, Guenter Roeck, Jean Delvare,
Jin Dongming, Hidetoshi Seto, linux-kernel, lm-sensors
In-Reply-To: <1283905550-18571-1-git-send-email-fenghua.yu@intel.com>
* Fenghua Yu <fenghua.yu@intel.com> wrote:
> #ifdef CONFIG_HOTPLUG_CPU
> mutex_unlock(&therm_cpu_lock);
> #endif
> +#ifdef CONFIG_HOTPLUG_CPU
> + mutex_unlock(&therm_cpu_lock);
> +#endif
That's all very ugly.
Thanks,
Ingo
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* 2.6.36-rc7-next-20101007 failed to compile (arch/arm/kernel/setup.c)
From: Uwe Kleine-König @ 2010-10-08 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4CAE1611.1020105@gai.ru>
Hello,
On Thu, Oct 07, 2010 at 10:48:49PM +0400, Alex Sverdlin wrote:
> make output:
> ...
> CC arch/arm/kernel/ptrace.o
> CC arch/arm/kernel/return_address.o
> CC arch/arm/kernel/setup.o
> /tmp/cccRqJQQ.s: Assembler messages:
> /tmp/cccRqJQQ.s:571: Error: bad instruction `isb'
> make[2]: *** [arch/arm/kernel/setup.o] Error 1
> make[1]: *** [arch/arm/kernel] Error 2
> ...
>
> 2.6.36-rc6 compiled without this problem...
>
> Compiler is GCC 3.4.3, complete toolchain taken from
> http://arm.cirrus.com/files/tools/arm-linux-gcc-3.4.3-1.0.1.tar.bz2
http://news.gmane.org/find-root.php?message_id=<1286308412-8252-1-git-send-email-linus.walleij@stericsson.com>
didn't make it yet into next
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] Fix SRAO/SRAR MCE injecting on guest without MCG_SER_P
From: Huang Ying @ 2010-10-08 8:25 UTC (permalink / raw)
To: Avi Kivity, Marcelo Tosatti
Cc: Hidetoshi Seto, kvm@vger.kernel.org, Andi Kleen, Dean Nelson
On real machine, if MCG_SER_P in MSR_MCG_CAP is not set, SRAO/SRAR MCE
should not be raised by hardware. This patch makes QEMU-KVM to follow
the same rule.
Reported-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: Huang Ying <ying.huang@intel.com>
---
qemu-kvm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -1134,7 +1134,7 @@ static void sigbus_handler(int n, struct
void *ctx)
{
#if defined(KVM_CAP_MCE) && defined(TARGET_I386)
- if (first_cpu->mcg_cap && siginfo->ssi_addr
+ if ((first_cpu->mcg_cap & MCG_SER_P) && siginfo->ssi_addr
&& siginfo->ssi_code == BUS_MCEERR_AO) {
uint64_t status;
void *vaddr;
@@ -1324,7 +1324,7 @@ static void kvm_on_sigbus(CPUState *env,
unsigned long paddr;
int r;
- if (env->mcg_cap && siginfo->si_addr
+ if ((env->mcg_cap & MCG_SER_P) && siginfo->si_addr
&& (siginfo->si_code == BUS_MCEERR_AR
|| siginfo->si_code == BUS_MCEERR_AO)) {
if (siginfo->si_code == BUS_MCEERR_AR) {
@@ -1356,7 +1356,7 @@ static void kvm_on_sigbus(CPUState *env,
if (do_qemu_ram_addr_from_host(vaddr, &ram_addr) ||
!kvm_physical_memory_addr_from_ram(kvm_state, ram_addr, (target_phys_addr_t *)&paddr)) {
fprintf(stderr, "Hardware memory error for memory used by "
- "QEMU itself instaed of guest system!\n");
+ "QEMU itself instead of guest system!\n");
/* Hope we are lucky for AO MCE */
if (siginfo->si_code == BUS_MCEERR_AO) {
return;
^ permalink raw reply
* [Bug 29833] radeon crashes kicad when using modeset
From: bugzilla-daemon @ 2010-10-08 8:25 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-29833-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=29833
--- Comment #14 from Fabio Varesano <fabio.varesano@gmail.com> 2010-10-08 01:25:05 PDT ---
(In reply to comment #13)
> To see which mesa driver you are using try:
> glxinfo | grep OpenGL
[fabio@gamma ~]$ glxinfo | grep OpenGL
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on RV530
OpenGL version string: 2.1 Mesa 7.9
OpenGL shading language version string: 1.20
OpenGL extensions:
[fabio@gamma ~]$
Looks correct to me.
--
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
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.