* [Qemu-devel] [PATCH 23/55] scsi-disk: report media changed via unit attention sense codes
From: Kevin Wolf @ 2011-10-31 13:29 UTC (permalink / raw)
To: anthony; +Cc: kwolf, qemu-devel
In-Reply-To: <1320067830-12093-1-git-send-email-kwolf@redhat.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Building on the previous patch, this one adds a media change callback
to scsi-disk.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
---
hw/scsi-bus.c | 5 +++++
hw/scsi-disk.c | 29 ++++++++++++++++++++++++++++-
hw/scsi.h | 2 ++
3 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index c190509..867b1a8 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -847,6 +847,11 @@ const struct SCSISense sense_code_RESET = {
.key = UNIT_ATTENTION, .asc = 0x29, .ascq = 0x00
};
+/* Unit attention, No medium */
+const struct SCSISense sense_code_UNIT_ATTENTION_NO_MEDIUM = {
+ .key = UNIT_ATTENTION, .asc = 0x3a, .ascq = 0x00
+};
+
/* Unit attention, Medium may have changed */
const struct SCSISense sense_code_MEDIUM_CHANGED = {
.key = UNIT_ATTENTION, .asc = 0x28, .ascq = 0x00
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index a6ef060..880cb22 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -71,6 +71,7 @@ struct SCSIDiskState
int cluster_size;
uint32_t removable;
uint64_t max_lba;
+ bool media_changed;
QEMUBH *bh;
char *version;
char *serial;
@@ -1198,7 +1199,21 @@ static void scsi_destroy(SCSIDevice *dev)
static void scsi_cd_change_media_cb(void *opaque, bool load)
{
- ((SCSIDiskState *)opaque)->tray_open = !load;
+ SCSIDiskState *s = opaque;
+
+ /*
+ * When a CD gets changed, we have to report an ejected state and
+ * then a loaded state to guests so that they detect tray
+ * open/close and media change events. Guests that do not use
+ * GET_EVENT_STATUS_NOTIFICATION to detect such tray open/close
+ * states rely on this behavior.
+ *
+ * media_changed governs the state machine used for unit attention
+ * report. media_event is used by GET EVENT STATUS NOTIFICATION.
+ */
+ s->media_changed = load;
+ s->tray_open = !load;
+ s->qdev.unit_attention = SENSE_CODE(UNIT_ATTENTION_NO_MEDIUM);
}
static bool scsi_cd_is_tray_open(void *opaque)
@@ -1217,6 +1232,15 @@ static const BlockDevOps scsi_cd_block_ops = {
.is_medium_locked = scsi_cd_is_medium_locked,
};
+static void scsi_disk_unit_attention_reported(SCSIDevice *dev)
+{
+ SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, dev);
+ if (s->media_changed) {
+ s->media_changed = false;
+ s->qdev.unit_attention = SENSE_CODE(MEDIUM_CHANGED);
+ }
+}
+
static int scsi_initfn(SCSIDevice *dev, uint8_t scsi_type)
{
SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, dev);
@@ -1329,6 +1353,7 @@ static SCSIDeviceInfo scsi_disk_info[] = {
.init = scsi_hd_initfn,
.destroy = scsi_destroy,
.alloc_req = scsi_new_request,
+ .unit_attention_reported = scsi_disk_unit_attention_reported,
.qdev.props = (Property[]) {
DEFINE_SCSI_DISK_PROPERTIES(),
DEFINE_PROP_BIT("removable", SCSIDiskState, removable, 0, false),
@@ -1343,6 +1368,7 @@ static SCSIDeviceInfo scsi_disk_info[] = {
.init = scsi_cd_initfn,
.destroy = scsi_destroy,
.alloc_req = scsi_new_request,
+ .unit_attention_reported = scsi_disk_unit_attention_reported,
.qdev.props = (Property[]) {
DEFINE_SCSI_DISK_PROPERTIES(),
DEFINE_PROP_END_OF_LIST(),
@@ -1356,6 +1382,7 @@ static SCSIDeviceInfo scsi_disk_info[] = {
.init = scsi_disk_initfn,
.destroy = scsi_destroy,
.alloc_req = scsi_new_request,
+ .unit_attention_reported = scsi_disk_unit_attention_reported,
.qdev.props = (Property[]) {
DEFINE_SCSI_DISK_PROPERTIES(),
DEFINE_PROP_BIT("removable", SCSIDiskState, removable, 0, false),
diff --git a/hw/scsi.h b/hw/scsi.h
index 6d40b8e..7004aaa 100644
--- a/hw/scsi.h
+++ b/hw/scsi.h
@@ -161,6 +161,8 @@ extern const struct SCSISense sense_code_IO_ERROR;
extern const struct SCSISense sense_code_I_T_NEXUS_LOSS;
/* Command aborted, Logical Unit failure */
extern const struct SCSISense sense_code_LUN_FAILURE;
+/* LUN not ready, Medium not present */
+extern const struct SCSISense sense_code_UNIT_ATTENTION_NO_MEDIUM;
/* Unit attention, Power on, reset or bus device reset occurred */
extern const struct SCSISense sense_code_RESET;
/* Unit attention, Medium may have changed*/
--
1.7.6.4
^ permalink raw reply related
* RE: [PATCH-RFC] nfs41: handle BLK_LAYOUT CB_RECALL_ANY
From: Myklebust, Trond @ 2011-10-31 13:54 UTC (permalink / raw)
To: Benny Halevy, Peng Tao; +Cc: linux-nfs, Peng Tao
In-Reply-To: <4EAE9B60.9040903@tonian.com>
> -----Original Message-----
> From: Benny Halevy [mailto:bhalevy@tonian.com]
> Sent: Monday, October 31, 2011 8:58 AM
> To: Peng Tao
> Cc: linux-nfs@vger.kernel.org; Myklebust, Trond; Peng Tao
> Subject: Re: [PATCH-RFC] nfs41: handle BLK_LAYOUT CB_RECALL_ANY
>
> On 2011-10-24 05:25, Peng Tao wrote:
> > Hi, Trond and Benny,
> >
> > The patch depends on the pnfs private workqueue for now. So I want
to
> > consult you about where to put the work. Is pnfs private workqueue
> > dropped? If yes, where should I put this kind of work?
>
> I'll defer this to Trond.
> I'm OK with having a workqueue for pnfs.
I've already commented on this: I see no justification whatsoever for a
private pnfs workqueue.
Cheers
Trond
^ permalink raw reply
* Re: [Xenomai-help] configuring user-space xenomai 2.6
From: Gilles Chanteperdrix @ 2011-10-31 13:54 UTC (permalink / raw)
To: Łukasz Sacha; +Cc: xenomai
In-Reply-To: <CAAeYjMmsda-t14LQ47HBu0Pv6rLKpp=1m3c2+3unKJfQdF9HMg@domain.hid>
On 10/31/2011 02:48 PM, Łukasz Sacha wrote:
> quote from README.INSTALL: "Finally, Xenomai build system also allows
> building a Xenomai patchedkernel as part of the user space support
> compilation process. Section1.4 documents this possibility."
>
> There is no section 1.4 :(
That is because this option was removed in xenomai 2.6, it was not very
useful anyway, as compiling a kernel is not complicated anyway. Will
remove the sentence, thanks.
To start using xenomai, you simply have to run make install, then copy
the installed file to the embedded root filesystem.
I already gave you URLs for documents giving a bit more details on how
to use the native and posix skins.
Also, could you avoid top-posting?
--
Gilles.
^ permalink raw reply
* [PATCH 3/3] Kill(): Remove redundant check and dead code
From: Jes.Sorensen @ 2011-10-31 13:53 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dledford
In-Reply-To: <1320069234-13112-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
No need to check for (force && rv >=2) since we just set rv = 0 in
that case.
In addition remove dead code path that checks rv != 0 inside code that
is only run for rv == 0.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
Kill.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/Kill.c b/Kill.c
index b841a5b..01d884f 100644
--- a/Kill.c
+++ b/Kill.c
@@ -63,7 +63,7 @@ int Kill(char *dev, struct supertype *st, int force, int quiet, int noexcl)
rv = st->ss->load_super(st, fd, dev);
if (force && rv >= 2)
rv = 0; /* ignore bad data in superblock */
- if (rv== 0 || (force && rv >= 2)) {
+ if (rv == 0) {
st->ss->free_super(st);
st->ss->init_super(st, NULL, 0, "", NULL, NULL);
if (st->ss->store_super(st, fd)) {
@@ -71,10 +71,6 @@ int Kill(char *dev, struct supertype *st, int force, int quiet, int noexcl)
fprintf(stderr, Name ": Could not zero superblock on %s\n",
dev);
rv = 1;
- } else if (rv) {
- if (!quiet)
- fprintf(stderr, Name ": superblock zeroed anyway\n");
- rv = 0;
}
}
close(fd);
--
1.7.6.4
^ permalink raw reply related
* [PATCH 2/3] conf_watch(): More dead code removal
From: Jes.Sorensen @ 2011-10-31 13:53 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dledford
In-Reply-To: <1320069234-13112-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
verbose is always zero, hence anything checking for verbose > 0 will
always fail.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
config.c | 26 --------------------------
1 files changed, 0 insertions(+), 26 deletions(-)
diff --git a/config.c b/config.c
index b57ba50..4e6165e 100644
--- a/config.c
+++ b/config.c
@@ -1022,57 +1022,31 @@ int conf_name_is_free(char *name)
struct mddev_ident *conf_match(struct mdinfo *info, struct supertype *st)
{
struct mddev_ident *array_list, *match;
- int verbose = 0;
array_list = conf_get_ident(NULL);
match = NULL;
for (; array_list; array_list = array_list->next) {
if (array_list->uuid_set &&
same_uuid(array_list->uuid, info->uuid, st->ss->swapuuid)
== 0) {
- if (verbose >= 2 && array_list->devname)
- fprintf(stderr, Name
- ": UUID differs from %s.\n",
- array_list->devname);
continue;
}
if (array_list->name[0] &&
strcasecmp(array_list->name, info->name) != 0) {
- if (verbose >= 2 && array_list->devname)
- fprintf(stderr, Name
- ": Name differs from %s.\n",
- array_list->devname);
continue;
}
if (array_list->super_minor != UnSet &&
array_list->super_minor != info->array.md_minor) {
- if (verbose >= 2 && array_list->devname)
- fprintf(stderr, Name
- ": Different super-minor to %s.\n",
- array_list->devname);
continue;
}
if (!array_list->uuid_set &&
!array_list->name[0] &&
!array_list->devices &&
array_list->super_minor == UnSet) {
- if (verbose >= 2 && array_list->devname)
- fprintf(stderr, Name
- ": %s doesn't have any identifying information.\n",
- array_list->devname);
continue;
}
/* FIXME, should I check raid_disks and level too?? */
if (match) {
- if (verbose >= 0) {
- if (match->devname && array_list->devname)
- fprintf(stderr, Name
- ": we match both %s and %s - cannot decide which to use.\n",
- match->devname, array_list->devname);
- else
- fprintf(stderr, Name
- ": multiple lines in mdadm.conf match\n");
- }
return NULL;
}
match = array_list;
--
1.7.6.4
^ permalink raw reply related
* [PATCH 1/3] conf_match(): Remove dead code
From: Jes.Sorensen @ 2011-10-31 13:53 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dledford
In-Reply-To: <1320069234-13112-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
devname is always NULL, hence if () statement will always fail.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
config.c | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/config.c b/config.c
index c0a6baa..b57ba50 100644
--- a/config.c
+++ b/config.c
@@ -1023,7 +1023,6 @@ struct mddev_ident *conf_match(struct mdinfo *info, struct supertype *st)
{
struct mddev_ident *array_list, *match;
int verbose = 0;
- char *devname = NULL;
array_list = conf_get_ident(NULL);
match = NULL;
for (; array_list; array_list = array_list->next) {
@@ -1044,14 +1043,6 @@ struct mddev_ident *conf_match(struct mdinfo *info, struct supertype *st)
array_list->devname);
continue;
}
- if (array_list->devices && devname &&
- !match_oneof(array_list->devices, devname)) {
- if (verbose >= 2 && array_list->devname)
- fprintf(stderr, Name
- ": Not a listed device for %s.\n",
- array_list->devname);
- continue;
- }
if (array_list->super_minor != UnSet &&
array_list->super_minor != info->array.md_minor) {
if (verbose >= 2 && array_list->devname)
--
1.7.6.4
^ permalink raw reply related
* [PATCH 0/3] Remove dead code
From: Jes.Sorensen @ 2011-10-31 13:53 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dledford
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Hi,
These three patches remove a couple of chunks of dead code. They were
pointed out by running Coverity.
The dead code isn't a big issue in itself, but removing it will remove
noise when looking through the audit logs.
Cheers,
Jes
Jes Sorensen (3):
conf_match(): Remove dead code
conf_watch(): More dead code removal
Kill(): Remove redundant check and dead code
Kill.c | 6 +-----
config.c | 35 -----------------------------------
2 files changed, 1 insertions(+), 40 deletions(-)
--
1.7.6.4
^ permalink raw reply
* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Will Deacon @ 2011-10-31 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111031120603.GJ19187@n2100.arm.linux.org.uk>
On Mon, Oct 31, 2011 at 12:06:03PM +0000, Russell King - ARM Linux wrote:
> On Sat, Oct 29, 2011 at 02:56:53PM +0100, Will Deacon wrote:
> > Hi Russell,
> >
> > On Sat, Oct 29, 2011 at 11:21:08AM +0100, Russell King - ARM Linux wrote:
> > > This would then allow everyone to hook into the restart via the same
> > > method irrespective of what they want, and if they want the old
> > > 'arch_reset' way, call setup_restart() themselves.
> >
> > Yup, it's a fantastic idea because it allows us to put all of the identity
> > mapping bits into setup_restart as well. So then platforms make the choice
> > about the mapping they want, rather than being told via the reboot mode.
>
> I've now committed my patch, so if you'd like to give it an acked by,
> and preferably a tested-by, I'll publish it out in a stable branch.
I gave it a spin on my Versatile Express and it reboots as expected.
Acked-and-tested-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* Re: [patch] Move nodesize/leafsize/sectorsize to fs_info
From: David Sterba @ 2011-10-31 13:51 UTC (permalink / raw)
To: Peeters Simon; +Cc: linux-btrfs
In-Reply-To: <CAKyAS7s1Xm3L_1QwptAKs61e0bc4s4z7k8jWo4SiujQFMSss0g@mail.gmail.com>
Hi Simon,
On Sun, Aug 07, 2011 at 11:54:31PM +0200, Peeters Simon wrote:
> moved nodesize, leafsize and sectorsize from btrfs_root to
> btrfs_fs_info as mentioned in [1] and updated everything accordingly.
> patch against the "for-linus" tree
> builds and loads, no further testing done.
Please add a "btrfs:" prefix to the subject line of the patch and add
your "Signed-off-by:" line, and also revise the changelog, so it
describes what the patch does and why, no need to reference the wiki
there (you can add such information after a '---' marker following the
changelog).
Please rebase your patch on top of Josef's for-chris branch, the sources
have evolved since your first posting (though the fixup is trivial, but
the process still needs your S-O-B line).
thanks,
david
^ permalink raw reply
* [Qemu-devel] 打印成本每張港幣0.03 (A4紙計算)
From: inkPort自動充墨寶 @ 2011-10-31 13:50 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 30 bytes --]
如看不到內容,請按此
[-- Attachment #2: Type: text/html, Size: 3118 bytes --]
^ permalink raw reply
* Re: [lm-sensors] [RFC][PATCH] hwmon: add support for MCP3204/3208
From: Paul Fertser @ 2011-10-31 13:49 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <201110311247.p9VClrVx017871@home.pavel.comp>
On Mon, Oct 31, 2011 at 02:11:23PM +0100, Jean Delvare wrote:
> 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.
Sure, will rework the driver accordingly. Thanks for the fast
response!
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: [Xenomai-help] configuring user-space xenomai 2.6
From: Łukasz Sacha @ 2011-10-31 13:48 UTC (permalink / raw)
To: xenomai
In-Reply-To: <CAAeYjMkjq2yEqd+QeeU5R9N9m3HYWtsib+x7te0hPcd7Kw9SaA@mail.gmail.com>
quote from README.INSTALL: "Finally, Xenomai build system also allows
building a Xenomai patchedkernel as part of the user space support
compilation process. Section1.4 documents this possibility."
There is no section 1.4 :(
regards,--
Łukasz Dragilla Sacha
On Mon, Oct 31, 2011 at 14:45, Łukasz Sacha <dragilla@domain.hid> wrote:
> The README.INSTALL ends with compilation of the user-space. What next?
> How to install a skin?
>
> regards,
> --
> Łukasz Dragilla Sacha
>
>
>
> On Mon, Oct 31, 2011 at 14:29, Łukasz Sacha <dragilla@domain.hid> wrote:
>> Yes you were right! That helped - thank you.
>> --
>> Łukasz Dragilla Sacha
>>
>>
>>
>> On Mon, Oct 31, 2011 at 14:20, Patrice Kadionik
>> <kadionik@domain.hid> wrote:
>>> 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 +
>>> +----------------------------------------------------------------------+
>>>
>>>
>>> _______________________________________________
>>> Xenomai-help mailing list
>>> Xenomai-help@domain.hid
>>> https://mail.gna.org/listinfo/xenomai-help
>>>
>>
>
^ permalink raw reply
* [Buildroot] [Bug 4327] I use the i686-linux-gcc-4.6.1 compiled grub-0.97 does not work
From: bugzilla at busybox.net @ 2011-10-31 13:47 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-4327-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=4327
--- Comment #1 from Thomas Petazzoni <thomas.petazzoni@free-electrons.com> 2011-10-31 13:47:34 UTC ---
We have a grub package in Buildroot. Please use it to build grub.
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* Re: [Xenomai-help] configuring user-space xenomai 2.6
From: Łukasz Sacha @ 2011-10-31 13:45 UTC (permalink / raw)
To: Patrice Kadionik; +Cc: xenomai
In-Reply-To: <CAAeYjMkAwLgMMw9EG7b7CuywNe3OjFPiBkPQQvDOhyhf-coMnw@domain.hid>
The README.INSTALL ends with compilation of the user-space. What next?
How to install a skin?
regards,
--
Łukasz Dragilla Sacha
On Mon, Oct 31, 2011 at 14:29, Łukasz Sacha <dragilla@domain.hid> wrote:
> Yes you were right! That helped - thank you.
> --
> Łukasz Dragilla Sacha
>
>
>
> On Mon, Oct 31, 2011 at 14:20, Patrice Kadionik
> <kadionik@domain.hid> wrote:
>> 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 +
>> +----------------------------------------------------------------------+
>>
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>>
>
^ permalink raw reply
* [U-Boot] Failed to load to memory using fatload.
From: sadashiva reddy @ 2011-10-31 13:45 UTC (permalink / raw)
To: u-boot
*Hi Sir,*
**
* I am not able to load to memory using fatload command in u-boot
from USB. *
*Example:*
=> fatload usb 0:1 400000 vxWorks.img
reading vxWorks.img
Device NOT ready
Request Sense returned 00 00 00
458887 bytes read
Machine Check Exception.
Caused by (from msr): regs 07b693e8 Data machine check.
NIP: 00000000 XER: 20000000 LR: 07FA1D60 REGS: 07b693e8 TRAP: 0200 DEAR:
00000000
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
GPR00: CFE04F98 07B694D8 07B69724 07FB64EC 07FB64F5 07B69518 07FFB72C
00000010
GPR08: FFFFFFFF 00264000 00000020 00000011 42022082 00000000 00000000
00000000
GPR16: 07FC6664 00000000 00000000 07FB3AF8 07FB3AF8 00000000 00000000
0DF16868
GPR24: 0129735E 0129735E 07FFB72C 07B69518 00000000 07FB64ED 07FCAABC
00000000
Call backtrace:
00000000 07F7B9E0 07F7BE0C 07F7308C 07F8567C 07F84BB0 07F84DBC
07F89534 07F6EFFC 07F6C5F4
machine check
U-Boot 2011.03 (Oct 28 2011 - 15:52:40)
MIP405, released
CPU: AMCC PowerPC 405GPr Rev. B at 396 MHz (PLB=132 OPB=66 EBC=33)
Internal PCI arbiter enabled, PCI sync clock at 33 MHz
16 kB I-Cache 16 kB D-Cache
Board: ### No HW ID - assuming MIP405-8 Rev A Boot Config: 0x80
I2C: ready
DRAM: REFRESH, Need to revisit128 MiB
Boot: FLASH
Flash: 8 MiB
### pci_pip405_fixup_irq entered
### pci_pip405_fixup_irq entered
### pci_pip405_fixup_irq entered
### pci_pip405_fixup_irq entered
Net: ppc_4xx_eth0
IDE: Bus 0: not available
Rev: MIP405-8 Rev A PLD 1 Vers 1
Can't overwrite "ethaddr"
INFO: old environment ajusted, use saveenv
Hit any key to stop autoboot: 5 \b\b\b 0
*If I run the above command its able to read the data from USB device and
show the read file size but it crashes and restarts the board as like above.
*
**
*But it is able to do all other USB related operations such as.*
**
> usb reset
(Re)start USB...
USB: scanning bus for devices... 4 USB Device(s) found
scanning bus for storage devices... 1 Storage Device(s) found
=> usb info
1: Hub, USB Revision 1.0
- UHCI Root Hub
- Class: Hub
- PacketSize: 8 Configurations: 1
- Vendor: 0x0000 Product 0x0000 Version 0.0
Configuration: 1
- Interfaces: 1 Self Powered 0mA
Interface: 0
- Alternate Setting 0, Endpoints: 1
- Class Hub
- Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
2: Hub, USB Revision 1.10
- General Purpose USB Hub
- Class: Hub
- PacketSize: 8 Configurations: 1
- Vendor: 0x0451 Product 0x2077 Version 1.0
Configuration: 1
- Interfaces: 1 Self Powered Remote Wakeup 0mA
- String: "General Purpose USB Hub"
Interface: 0
- Alternate Setting 0, Endpoints: 1
- Class Hub
- String: "General Purpose USB Hub"
- Endpoint 1 In Interrupt MaxPacket 1 Interval 255ms
3: Human Interface, USB Revision 1.10
- CHICONY USB Keyboard
- Class: (from Interface) Human Interface
- PacketSize: 8 Configurations: 1
- Vendor: 0x04f2 Product 0x0111 Version 3.0
Configuration: 1
- Interfaces: 2 Bus Powered Remote Wakeup 100mA
Interface: 0
- Alternate Setting 0, Endpoints: 1
- Class Human Interface, Subclass: Boot Keyboard
- Endpoint 1 In Interrupt MaxPacket 8 Interval 10ms
Interface: 1
- Alternate Setting 0, Endpoints: 1
- Class Human Interface, Subclass: None
- Endpoint 2 In Interrupt MaxPacket 8 Interval 10ms
4: Mass Storage, USB Revision 2.0
- USB FLASH DRIVE 079108873AB6
- Class: (from Interface) Mass Storage
- PacketSize: 64 Configurations: 1
- Vendor: 0x1005 Product 0xb113 Version 1.16
Configuration: 1
- Interfaces: 1 Bus Powered 200mA
Interface: 0
- Alternate Setting 0, Endpoints: 2
- Class Mass Storage, Transp. SCSI, Bulk only
- Endpoint 1 In Bulk MaxPacket 64
- Endpoint 2 Out Bulk MaxPacket 64
=> usb stor
Device 0: Vendor: Rev: PMAP Prod: USB FLASH DRIVE
Type: Removable Hard Disk
Capacity: 3820.0 MB = 3.7 GB (7823360 x 512)
=> usb part
Partition Map for USB device 0 -- Partition Type: DOS
Partition Start Sector Num Sectors Type
1 8064 7815296 b
=> fatls usb 0:1
458887 vxworks.img
1 file(s), 0 dir(s)
*But if I format the usb device in linux with Compatible with linux(ext2 )
then if I run below command like.*
=> ext2ls usb 0:1
<DIR> 4096 .
<DIR> 4096 ..
458887 vxWorks.img
=> ext2load usb 0:1 400000 vxWorks.img
Loading file "vxWorks.img" from usb device 0:1 (usbda1)
458887 bytes read
=> bootm
## Booting kernel from Legacy Image at 00400000 ...
Image Name: CairTestAppl
Created: 2011-09-05 11:17:04 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 458823 Bytes = 448.1 KiB
Load Address: 00010000
Entry Point: 00010000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
*With the above format type and command I am able load to memory and boot
from there. But same thing is not able to do in *
*fat32 or fat format and fatload command.*
**
*Can you please help me regarding these issue.*
*Thanks in advance.*
**
*I am using PPC405GPr processor and MIP405 board. U-boot version you cen
see on top debug message.*
Best Regards,
Sadashiv
^ permalink raw reply
* [Buildroot] [Bug 4363] Make sure that copied linux and busybox defconfig are writable before modifying
From: bugzilla at busybox.net @ 2011-10-31 13:45 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-4363-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=4363
--- Comment #4 from Thomas Petazzoni <thomas.petazzoni@free-electrons.com> 2011-10-31 13:45:06 UTC ---
I really don't understand why this would be necessary. Could you detail what
you mean by "If the custom defconfigs are not checked out, then they are
read-only" ?
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* Re: [PATCH 2/2] module: Re-enable dynamic debugging for GPL-compatible OOT modules
From: Ben Hutchings @ 2011-10-31 13:44 UTC (permalink / raw)
To: Rusty Russell, Jason Baron
Cc: Nick Bowler, Greg KH, Dave Jones, Randy Dunlap, LKML,
Debian kernel maintainers, Mathieu Desnoyers
In-Reply-To: <87obwxq5tz.fsf@rustcorp.com.au>
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
On Mon, 2011-10-31 at 12:29 +1030, Rusty Russell wrote:
> On Fri, 28 Oct 2011 04:38:14 +0100, Ben Hutchings <ben@decadent.org.uk> wrote:
> > Dynamic debugging was enabled for GPL-compatible out-of-tree modules
> > until my addition of TAINT_OOT_MODULE. It should continue to be
> > enabled now.
>
> Please just remove the test entirely.
>
> AFAICT there's nothing unique to dynamic debug which means it should
> avoid taint. If it oopses, we'll learn all about tainting in the oops
> message.
It looks like the dynamic debug facility is not meant to be available to
proprietary modules.
Ben.
> > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> > ---
> > kernel/module.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/module.c b/kernel/module.c
> > index dab585e..448fd77 100644
> > --- a/kernel/module.c
> > +++ b/kernel/module.c
> > @@ -2881,7 +2881,7 @@ static struct module *load_module(void __user *umod,
> > }
> >
> > /* This has to be done once we're sure module name is unique. */
> > - if (!mod->taints || mod->taints == (1U<<TAINT_CRAP))
> > + if (!(mod->taints & ~(1U << TAINT_CRAP | 1U << TAINT_OOT_MODULE)))
> > dynamic_debug_setup(info.debug, info.num_debug);
> >
> > /* Find duplicate symbols */
> > @@ -2918,7 +2918,7 @@ static struct module *load_module(void __user *umod,
> > module_bug_cleanup(mod);
> >
> > ddebug:
> > - if (!mod->taints || mod->taints == (1U<<TAINT_CRAP))
> > + if (!(mod->taints & ~(1U << TAINT_CRAP | 1U << TAINT_OOT_MODULE)))
> > dynamic_debug_remove(info.debug);
> > unlock:
> > mutex_unlock(&module_mutex);
> > --
> > 1.7.7
> >
> >
>
--
Ben Hutchings
Computers are not intelligent. They only think they are.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH 1/2] uio: allow drivers to override the pgprot for mmap
From: Kumar Gala @ 2011-10-31 13:44 UTC (permalink / raw)
To: Greg KH; +Cc: Hans J. Koch, linuxppc-dev, linux-kernel
In-Reply-To: <20111029063809.GC2280@kroah.com>
On Oct 29, 2011, at 1:38 AM, Greg KH wrote:
> On Fri, Oct 28, 2011 at 11:48:12PM +0200, Hans J. Koch wrote:
>> On Fri, Oct 28, 2011 at 10:50:29AM -0500, Kumar Gala wrote:
>>> For some devices, the default behavior of pgprot_noncached() is not
>>> appropriate for all of its mappable regions. This provides a means for
>>> the kernel side of the UIO driver to override the flags without having
>>> to implement its own full mmap callback.
>>
>> Thanks for also providing an example driver showing the use of this.
>> You should also post this driver in a mainline-ready version, I'm a bit
>> uncomfortable with adding a new function pointer without having any users.
>
> I'm more than "uncomfortable", I'll refuse to take any such patch unless
> there is a in-kernel user, otherwise it makes no sense to add the
> pointer at all.
>
> thanks,
>
> greg k-h
I'm in agreement with this view. I wanted to post this to make sure the direction we took was ok so when the upstream driver is posted this patch / change isn't a concern.
- k
^ permalink raw reply
* Re: [RFC][PATCH 1/2] uio: allow drivers to override the pgprot for mmap
From: Kumar Gala @ 2011-10-31 13:44 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, Hans J. Koch, linux-kernel
In-Reply-To: <20111029063809.GC2280@kroah.com>
On Oct 29, 2011, at 1:38 AM, Greg KH wrote:
> On Fri, Oct 28, 2011 at 11:48:12PM +0200, Hans J. Koch wrote:
>> On Fri, Oct 28, 2011 at 10:50:29AM -0500, Kumar Gala wrote:
>>> For some devices, the default behavior of pgprot_noncached() is not
>>> appropriate for all of its mappable regions. This provides a means =
for
>>> the kernel side of the UIO driver to override the flags without =
having
>>> to implement its own full mmap callback.
>>=20
>> Thanks for also providing an example driver showing the use of this.
>> You should also post this driver in a mainline-ready version, I'm a =
bit
>> uncomfortable with adding a new function pointer without having any =
users.
>=20
> I'm more than "uncomfortable", I'll refuse to take any such patch =
unless
> there is a in-kernel user, otherwise it makes no sense to add the
> pointer at all.
>=20
> thanks,
>=20
> greg k-h
I'm in agreement with this view. I wanted to post this to make sure the =
direction we took was ok so when the upstream driver is posted this =
patch / change isn't a concern.
- k=
^ permalink raw reply
* Would it be possible to turn off RFC822TABS in vger's zmailer config?
From: Michael Alan Dorman @ 2011-10-31 13:34 UTC (permalink / raw)
To: postmaster; +Cc: linux-kernel
Hi, Dave, Matti,
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6429 has the
details regarding the investigation in the SpamAssassin dev community
that suggests that vger may be the only legitimate source of email that
uses tabs in its headers---it is otherwise a very likely sign of a spam
email.
Although as you can see from the bug report's resolution, a modification
has been done to the rule that matches to try and work around this---and
thereby not unduly penalize mailing lists hosted on vger---it seems an
even better solution would be if you were to actually change the zmailer
configuration to not modify the headers of the emails passing through
it.
I don't know much about zmailer or your majordomo setup, but it seems
like this would be a simple change that could make it easier for the
many people on vger's lists who probably use SpamAssassin to keep their
inboxes clean without undue false positives.
Thanks for your time,
Mike.
<Not really a representative of the SA devs>
^ permalink raw reply
* [Buildroot] [Bug 4387] Make sure that dest dir exists before installing mtd files
From: bugzilla at busybox.net @ 2011-10-31 13:43 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-4387-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=4387
--- Comment #1 from Thomas Petazzoni <thomas.petazzoni@free-electrons.com> 2011-10-31 13:43:08 UTC ---
Instead, the patch should change the call to install to use the -D option.
Could you submit a proper patch to the Buildroot mailing list?
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* Re: [PATCH] echo: fix octal escaping with \1...\7
From: Paul Gilmartin @ 2011-10-31 13:35 UTC (permalink / raw)
To: Eric Blake; +Cc: dash
In-Reply-To: <4EAE9ECB.4040607@redhat.com>
On Oct 31, 2011, at 07:12, Eric Blake wrote:
> [adding bug-libtool]
>
[removing, because I'm not registered.]
> 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?
>
Yes, there's value in coding defensively. However:
I used to know a statement in POSIX that builtins should behave
identically to the executables in /bin (or perhaps /usr/bin)
except for performance. So, testing with dash on Ubuntu:
\! $ echo "\1"
\x01
\! $ /bin/echo "\1"
\1
\! $
I recognize that following this precept would make the behavior
of the builtin "echo" platform-dependent. But that could be
managed in autoconf.
-- gil
^ permalink raw reply
* [Buildroot] [Bug 4429] buildroot 2011.08 does not build on Ubuntu 11.10
From: bugzilla at busybox.net @ 2011-10-31 13:41 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-4429-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=4429
--- Comment #2 from Thomas Petazzoni <thomas.petazzoni@free-electrons.com> 2011-10-31 13:41:28 UTC ---
Do you run the bash shell inside byubo or screen ?
This sounds really strange, I use Buildroot regularly within screen (but not on
Ubuntu 11.10 specifically).
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* Re: [GIT PULL] Queue free fix (was Re: [PATCH] block: Free queue resources at blk_release_queue())
From: Heiko Carstens @ 2011-10-31 13:40 UTC (permalink / raw)
To: Mike Snitzer
Cc: James Bottomley, Jun'ichi Nomura, Steffen Maier,
linux-scsi@vger.kernel.org, Jens Axboe, Hannes Reinecke,
Linux Kernel, Alan Stern, Thadeu Lima de Souza Cascardo,
Taraka R. Bodireddy, Seshagiri N. Ippili,
Manvanthara B. Puttashankar, Jeff Moyer, Shaohua Li, gmuelas
In-Reply-To: <20111031132158.GB14393@redhat.com>
On Mon, Oct 31, 2011 at 09:21:58AM -0400, Mike Snitzer wrote:
> > > It _looks_ like we do not hit the BUG_ON() that. This time we get this instead:
> > >
> > > [ 4024.937870] Unable to handle kernel pointer dereference at virtual kernel address 000003e004d41000
> > > [ 4024.937886] Oops: 0011 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> > > [ 4024.937899] Modules linked in: dm_round_robin sunrpc ipv6 qeth_l2 binfmt_misc dm_multipath scsi_dh dm_mod qeth ccwgroup [las
> > > t unloaded: scsi_wait_scan]
> > > [ 4024.937925] CPU: 1 Not tainted 3.0.7-50.x.20111021-s390xdefault #1
> > > [ 4024.937930] Process ksoftirqd/1 (pid: 1942, task: 0000000079c6c750, ksp: 0000000073adfc50)
> > > [ 4024.937936] Krnl PSW : 0704000180000000 000003e00126263a (dm_softirq_done+0x72/0x140 [dm_mod])
> > > [ 4024.937959] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:0 PM:0 EA:3
> > > [ 4024.937966] Krnl GPRS: 000000007b9156b0 000003e004d41100 000000000e14b600 000000000000006d
> > > [ 4024.937971] 00000000715332b0 000000000c140ce8 000000000090d2ef 0000000000000005
> > > [ 4024.937977] 0000000000000001 0000000000000101 000000000c140d00 0000000000000000
> > > [ 4024.937983] 000003e001260000 000003e00126f098 0000000073adfd08 0000000073adfcb8
> > > [ 4024.938001] Krnl Code: 000003e00126262a: f0a0000407f1 srp 4(11,%r0),2033,0
> > > [ 4024.938009] 000003e001262630: e31050080004 lg %r1,8(%r5)
> > > [ 4024.938017] 000003e001262636: 58b05180 l %r11,384(%r5)
> > > [ 4024.938024] >000003e00126263a: e31010080004 lg %r1,8(%r1)
> > > [ 4024.938031] 000003e001262640: e31010500004 lg %r1,80(%r1)
> > > [ 4024.938038] 000003e001262646: b9020011 ltgr %r1,%r1
> > > [ 4024.938045] 000003e00126264a: a784ffdf brc 8,3e001262608
> > > [ 4024.938053] 000003e00126264e: e32050080004 lg %r2,8(%r5)
> > > [ 4024.938060] Call Trace:
> > > [ 4024.938063] ([<070000000040716c>] 0x70000000040716c)
> > > [ 4024.938069] [<000000000040d29c>] blk_done_softirq+0xd4/0xf0
> > > [ 4024.938080] [<00000000001587c2>] __do_softirq+0xda/0x398
> > > [ 4024.938088] [<0000000000158ba0>] run_ksoftirqd+0x120/0x23c
> > > [ 4024.938095] [<000000000017c2aa>] kthread+0xa6/0xb0
> > > [ 4024.938102] [<000000000061970e>] kernel_thread_starter+0x6/0xc
> > > [ 4024.938112] [<0000000000619708>] kernel_thread_starter+0x0/0xc
> > > [ 4024.938118] INFO: lockdep is turned off.
> > > [ 4024.938121] Last Breaking-Event-Address:
> > > [ 4024.938124] [<000003e001262600>] dm_softirq_done+0x38/0x140 [dm_mod]
> > > [ 4024.938135]
> > > [ 4024.938139] Kernel panic - not syncing: Fatal exception in interrupt
> > > [ 4024.938144] CPU: 1 Tainted: G D 3.0.7-50.x.20111021-s390xdefault #1
> > > [ 4024.938150] Process ksoftirqd/1 (pid: 1942, task: 0000000079c6c750, ksp: 0000000073adfc50)
> > > [ 4024.938155] 0000000073adf958 0000000073adf8d8 0000000000000002 0000000000000000
> > > [ 4024.938164] 0000000073adf978 0000000073adf8f0 0000000073adf8f0 000000000061386a
> > > [ 4024.938174] 0000000000000000 0000000000000000 0000000000000005 0000000000100ec6
> > > [ 4024.938184] 000000000000000d 000000000000000c 0000000073adf940 0000000000000000
> > > [ 4024.938194] 0000000000000000 0000000000100a18 0000000073adf8d8 0000000073adf918
> > > [ 4024.938205] Call Trace:
> > > [ 4024.938208] ([<0000000000100926>] show_trace+0xee/0x144)
> > > [ 4024.938216] [<0000000000613694>] panic+0xb0/0x234
> > > [ 4024.938224] [<0000000000100ec6>] die+0x15a/0x168
> > > [ 4024.938230] [<000000000011fb9e>] do_no_context+0xba/0xf8
> > > [ 4024.938306] [<000000000061c074>] do_dat_exception+0x378/0x3e4
> > > [ 4024.938314] [<0000000000619e02>] pgm_exit+0x0/0x4
> > > [ 4024.938319] [<000003e00126263a>] dm_softirq_done+0x72/0x140 [dm_mod]
> > > [ 4024.938329] ([<070000000040716c>] 0x70000000040716c)
> > > [ 4024.938334] [<000000000040d29c>] blk_done_softirq+0xd4/0xf0
> > > [ 4024.938341] [<00000000001587c2>] __do_softirq+0xda/0x398
> > > [ 4024.938347] [<0000000000158ba0>] run_ksoftirqd+0x120/0x23c
> > > [ 4024.938354] [<000000000017c2aa>] kthread+0xa6/0xb0
> > > [ 4024.938360] [<000000000061970e>] kernel_thread_starter+0x6/0xc
> > > [ 4024.938366] [<0000000000619708>] kernel_thread_starter+0x0/0xc
> > > [ 4024.938373] INFO: lockdep is turned off.
> > >
> > > So we thought we might as well upgrade to 3.1 but immediately got a
> > >
> > > kernel BUG at block/blk-flush.c:323!
> > >
> > > which was handled here https://lkml.org/lkml/2011/10/4/105 and
> > > here https://lkml.org/lkml/2011/10/12/408 .
> > >
> > > But no patches for that one went upstream AFAICS.
> >
> > Well, all I can say is "hm". You put only a BUG_ON() in the code, which
> > wasn't triggered, but now we get a completely different oops. However,
> > I think it does point to the dm barrier handling code. Can you turn off
> > barriers and see if all oopses go away?
>
> There are two 3.1-stable fixes from Jeff Moyer that Jens staged for
> Linus to pick up (but seems Jens hasn't sent his 3.2 pull to Linus yet):
>
> http://git.kernel.dk/?p=linux-block.git;a=commit;h=8f02b3a09b1b7d2a4d24b8cd7008f2a441f19a14
> http://git.kernel.dk/?p=linux-block.git;a=commit;h=f26d8f0562da76731cb049943a0e9d9fa81d946a
Those two fixes would only address the "kernel BUG at block/blk-flush.c:323!" but not the
crash report above, right?
Since looking at the changelog they refer to a patch that went in with 3.1-rc1 while the
crash report above is with 3.0.7. Oh well...
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 0/3] TLS abstraction layer for thread-local cpu_single_env on Linux
From: Peter Maydell @ 2011-10-31 13:40 UTC (permalink / raw)
To: qemu-devel
Cc: Anthony Liguori, Dr. David Alan Gilbert, patches, Jan Kiszka,
Paolo Bonzini, Andreas Färber
In-Reply-To: <1319795562-18091-1-git-send-email-peter.maydell@linaro.org>
An early ping since I have no idea who counts as the submaintainer
for this patchset and it definitely needs to go in for 1.0...
thanks
-- PMM
On 28 October 2011 10:52, Peter Maydell <peter.maydell@linaro.org> wrote:
> These patches add enough of the TLS abstraction layer to allow us
> to make cpu_single_env thread-local on Linux systems. This fixes
> the regression described in bug 823902 for the 1.0 release; we
> can add the Win32 and POSIX implementations later.
>
> I haven't included Paolo's "Prepare Windows port for thread-local
> cpu_single_env" patch -- it would be safe to do so but it isn't
> necessary until we actually implement TLS for Win32.
>
> Changes v1->v2:
> * fix Paolo's email address
> * split the darwin-user change out into a separate patch
> * drop the 'tls_' prefix from the cpu_single_env tls var name
> Changes v2->v3:
> * minor rearrangement of copyright notice in comment
> * added a missing Signed-off-by
> * fixed the name of the multiple-include-guard #define
>
> Paolo Bonzini (2):
> darwin-user/main.c: Drop unused cpu_single_env definition
> Make cpu_single_env thread-local
>
> Peter Maydell (1):
> qemu-tls.h: Add abstraction layer for TLS variables
>
> cpu-all.h | 4 +++-
> darwin-user/main.c | 2 --
> exec.c | 2 +-
> qemu-tls.h | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 56 insertions(+), 4 deletions(-)
> create mode 100644 qemu-tls.h
^ 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.