* Re: [PATCH] Export ACPI _DSM provided firmware instance number and
From: Jesse Barnes @ 2011-01-10 19:13 UTC (permalink / raw)
To: Narendra_K
Cc: Matt_Domsch, linux-pci, linux-hotplug, netdev, Jordan_Hargrave,
Charles_Rose, Vijay_Nijhawan
In-Reply-To: <E31FB011129F30488D5861F3839049151D10F8EF9D@BLRX7MCDC201.AMER.DELL.COM>
On Mon, 10 Jan 2011 10:48:26 -0800
<Narendra_K@Dell.com> wrote:
> > > > 'label' is fine for either case, with ACPI taking priority over
> > > > SMBIOS if both happen to be present.
> > > >
> >
> > Applied, thanks.
>
> Jesse,
>
> Thank you.
Not sure if you saw it yet, but the patch caused a build breakage. Can
you send me a replacement patch with a fix asap?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* RE: [PATCH] Export ACPI _DSM provided firmware instance number and
From: Narendra_K @ 2011-01-10 18:48 UTC (permalink / raw)
To: jbarnes
Cc: Matt_Domsch, linux-pci, linux-hotplug, netdev, Jordan_Hargrave,
Charles_Rose, Vijay_Nijhawan
In-Reply-To: <20110107142750.21ea39f0@jbarnes-desktop>
> -----Original Message-----
> From: Jesse Barnes [mailto:jbarnes@virtuousgeek.org]
> Sent: Saturday, January 08, 2011 3:58 AM
> To: K, Narendra
> Cc: Domsch, Matt; linux-pci@vger.kernel.org; linux-
> hotplug@vger.kernel.org; netdev@vger.kernel.org; Hargrave, Jordan;
> Rose, Charles; Nijhawan, Vijay
> Subject: Re: [PATCH] Export ACPI _DSM provided firmware instance number
> and string name to sysfs
>
> On Thu, 23 Dec 2010 11:24:36 -0800
> <Narendra_K@Dell.com> wrote:
>
> > On Thu, Dec 23, 2010 at 08:02:03PM +0530, Domsch, Matt wrote:
> > > On Wed, Dec 22, 2010 at 08:42:39AM -0800, Narendra_K@Dell.com
> wrote:
> > > > Hello,
> > > >
> > > > This patch exports ACPI _DSM provided firmware instance number
> and
> > > > string name to sysfs.
> > > >
> > > > Please review -
> > >
> > > There are now two different meanings for the 'index' file:
> > >
> > > 1) SMBIOS-provided "type instance" value, which I've only seen in
> > > range [1..N] for N devices, monotonically stepwise increasing.
> > >
> > > 2) ACPI-provided "index" value, which per spec only needs to be a
> > > "sort key", not starting at 0 or 1, and while monotonically
> > > increasing, not necessarily stepwise. It's perfectly valid for
> the
> > > values to be (12, 16, 27, 29) if that's convenient for BIOS to
> > > generate.
> > >
> > > Therefore, a consumer of this value (such as biosdevname) must know
> > > which of the two it's dealing with, and either accept the value as-
> is,
> > > or sort the value list. While I suppose it could sort the value
> list
> > > in either case, I'd prefer the ACPI value to be exposed in its own
> > > file, perhaps 'acpi_index', to make this explicit rather than
> > > implicit.
> > >
> > > 'label' is fine for either case, with ACPI taking priority over
> > > SMBIOS if both happen to be present.
> > >
>
> Applied, thanks.
Jesse,
Thank you.
With regards,
Narendra K
^ permalink raw reply
* Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c
From: Ozan Çağlayan @ 2011-01-10 11:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D263BF6.6050305@verizon.net>
Pazartesi 10 Ocak 2011 günü (saat 10:10:12) Hannes Reinecke şunları yazmıştı:
> On 01/07/2011 03:13 AM, Robby Workman wrote:
> > On Thu, 6 Jan 2011 14:29:27 -0800
> > Greg KH <greg@kroah.com> wrote:
> >
> >> On Thu, Jan 06, 2011 at 05:02:30PM -0500, John Stanley wrote:
> >>> Hello,
> >>> There is a problem in udev-165/extras/ata_id/ata_id.c resulting in
> >>> random early boot kernel panics. As it stands, udev-165 is not
> >>> usable because the boot panics occur to frequently. The systems are
> >>> GNU/Linux i686 with linux-2.6.36.2 and linux-2.6.37, gcc-4.5.1, and
> >>> glibc-2.12.1.
> >>
> >> What is the kernel oops message? That should be fixed first, no
> >> userspace code should be able to crash the kernel.
> >
> >
> > Hi Greg,
> >
> > First, sorry for not posting something about this sooner - I'd
> > pinged Kay on IRC about it, and I *promise* I had planned to
> > forward it to the scsi/ati guys, but work has been hell this
> > week. Anyway, here's the initial report we got about it, along
> > with a lot of debugging by other folks (including the OP, who
> > I think is 'resonance' in that thread):
> > http://www.linuxquestions.org/questions/slackware-14/current-randomly-timed-kernel-oops-on-bootup-of-two-test-boxen-852843/
> >
> It's all Tejun's fault.
> kernel crashing in ata_sff_data_xfer / ioread32 ...
> Looks like we're trying a read to a page which wasn't
> mapped/allocated properly.
I've just had another report about random crashes (udev-165 on 2.6.37) which
crash in ioread16_rep:
http://img5.imagebanana.com/img/1ub7ghcy/DSCF5552.JPG
---
Ozan Çağlayan
TUBITAK/UEKAE - Pardus Linux
http://www.pardus.org.tr/eng
^ permalink raw reply
* Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c
From: Hannes Reinecke @ 2011-01-10 8:10 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D263BF6.6050305@verizon.net>
On 01/07/2011 03:13 AM, Robby Workman wrote:
> On Thu, 6 Jan 2011 14:29:27 -0800
> Greg KH <greg@kroah.com> wrote:
>
>> On Thu, Jan 06, 2011 at 05:02:30PM -0500, John Stanley wrote:
>>> Hello,
>>> There is a problem in udev-165/extras/ata_id/ata_id.c resulting in
>>> random early boot kernel panics. As it stands, udev-165 is not
>>> usable because the boot panics occur to frequently. The systems are
>>> GNU/Linux i686 with linux-2.6.36.2 and linux-2.6.37, gcc-4.5.1, and
>>> glibc-2.12.1.
>>
>> What is the kernel oops message? That should be fixed first, no
>> userspace code should be able to crash the kernel.
>
>
> Hi Greg,
>
> First, sorry for not posting something about this sooner - I'd
> pinged Kay on IRC about it, and I *promise* I had planned to
> forward it to the scsi/ati guys, but work has been hell this
> week. Anyway, here's the initial report we got about it, along
> with a lot of debugging by other folks (including the OP, who
> I think is 'resonance' in that thread):
> http://www.linuxquestions.org/questions/slackware-14/current-randomly-timed-kernel-oops-on-bootup-of-two-test-boxen-852843/
>
It's all Tejun's fault.
kernel crashing in ata_sff_data_xfer / ioread32 ...
Looks like we're trying a read to a page which wasn't
mapped/allocated properly.
And yes, it definitely should be fixed in the kernel first.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
^ permalink raw reply
* Re: About volume/disk blocks/size properties
From: Kay Sievers @ 2011-01-10 0:44 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=zsM5nY+J9X7-Soe_5Ajn1Qek6TEhWgpWj-ra2@mail.gmail.com>
2011/1/10 José Félix Ontañón <felixonta@gmail.com>:
> El día 8 de enero de 2011 18:26, Kay Sievers <kay.sievers@vrfy.org> escribió:
> It seems the size file give us the number of sectors, isn't?
Yeah.
> In order to get the bytes of the disk/partition ... is it right to
> multiply /sys/block/<disk>/queue/logical_block_size times
> /sys/block/<disk>/size ??
Internal kernel size value is always 512 bytes.
Kay
^ permalink raw reply
* Re: About volume/disk blocks/size properties
From: José Félix Ontañón @ 2011-01-09 23:07 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=zsM5nY+J9X7-Soe_5Ajn1Qek6TEhWgpWj-ra2@mail.gmail.com>
El día 8 de enero de 2011 18:26, Kay Sievers <kay.sievers@vrfy.org> escribió:
> 2011/1/8 José Félix Ontañón <felixonta@gmail.com>:
>> I wonder... are there any reasons for not being convenient to export
>> some properties refering the volume size of a disk device?
>> Although I'm concerned about the
>> don't-turning-udev-into-a-hal-like-system, I still perceiving the
>> volume.size or volume.block_size properties as very useful for user
>> space apps.
>>
>> On the one hand, it could be easy for user space apps to get the
>> size/blocks for partition devices,
>
> $ grep . /sys/class/block/*/size
> /sys/class/block/sda1/size:41943040
> /sys/class/block/sda2/size:41943040
> /sys/class/block/sda3/size:115343360
> /sys/class/block/sda4/size:50835456
> /sys/class/block/sda/size:250069680
> /sys/class/block/sr0/size:2097151
>
>> but on the other hand you need root
>> privs to get this info for disk devices, am i wrong?
>
> Everybody can do that.
>
> Kay
>
Oh! Much better! Sorry for messing up.
It seems the size file give us the number of sectors, isn't?
In order to get the bytes of the disk/partition ... is it right to
multiply /sys/block/<disk>/queue/logical_block_size times
/sys/block/<disk>/size ??
Thanks!
--
http://fontanon.org
^ permalink raw reply
* Re: About volume/disk blocks/size properties
From: Kay Sievers @ 2011-01-08 17:26 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=zsM5nY+J9X7-Soe_5Ajn1Qek6TEhWgpWj-ra2@mail.gmail.com>
2011/1/8 José Félix Ontañón <felixonta@gmail.com>:
> I wonder... are there any reasons for not being convenient to export
> some properties refering the volume size of a disk device?
> Although I'm concerned about the
> don't-turning-udev-into-a-hal-like-system, I still perceiving the
> volume.size or volume.block_size properties as very useful for user
> space apps.
>
> On the one hand, it could be easy for user space apps to get the
> size/blocks for partition devices,
$ grep . /sys/class/block/*/size
/sys/class/block/sda1/size:41943040
/sys/class/block/sda2/size:41943040
/sys/class/block/sda3/size:115343360
/sys/class/block/sda4/size:50835456
/sys/class/block/sda/size:250069680
/sys/class/block/sr0/size:2097151
> but on the other hand you need root
> privs to get this info for disk devices, am i wrong?
Everybody can do that.
Kay
^ permalink raw reply
* About volume/disk blocks/size properties
From: José Félix Ontañón @ 2011-01-08 12:53 UTC (permalink / raw)
To: linux-hotplug
Hello everybody,
I wonder... are there any reasons for not being convenient to export
some properties refering the volume size of a disk device?
Although I'm concerned about the
don't-turning-udev-into-a-hal-like-system, I still perceiving the
volume.size or volume.block_size properties as very useful for user
space apps.
On the one hand, it could be easy for user space apps to get the
size/blocks for partition devices, but on the other hand you need root
privs to get this info for disk devices, am i wrong? I think udev
should, at least, export this properties making them available for
user space apps.
I've been looking for similar questions on the mail-list archives but
couldn't found anything related, so i'll be very glad if someone could
clarify. Thanks in advance.
--
http://fontanon.org
^ permalink raw reply
* Re: [PATCH] Export ACPI _DSM provided firmware instance number and
From: Jesse Barnes @ 2011-01-07 22:27 UTC (permalink / raw)
To: Narendra_K
Cc: Matt_Domsch, linux-pci, linux-hotplug, netdev, Jordan_Hargrave,
Charles_Rose, Vijay_Nijhawan
In-Reply-To: <20101223194927.GA2717@fedora14-r610.oslab.blr.amer.dell.com>
On Thu, 23 Dec 2010 11:24:36 -0800
<Narendra_K@Dell.com> wrote:
> On Thu, Dec 23, 2010 at 08:02:03PM +0530, Domsch, Matt wrote:
> > On Wed, Dec 22, 2010 at 08:42:39AM -0800, Narendra_K@Dell.com wrote:
> > > Hello,
> > >
> > > This patch exports ACPI _DSM provided firmware instance number and
> > > string name to sysfs.
> > >
> > > Please review -
> >
> > There are now two different meanings for the 'index' file:
> >
> > 1) SMBIOS-provided "type instance" value, which I've only seen in
> > range [1..N] for N devices, monotonically stepwise increasing.
> >
> > 2) ACPI-provided "index" value, which per spec only needs to be a
> > "sort key", not starting at 0 or 1, and while monotonically
> > increasing, not necessarily stepwise. It's perfectly valid for the
> > values to be (12, 16, 27, 29) if that's convenient for BIOS to
> > generate.
> >
> > Therefore, a consumer of this value (such as biosdevname) must know
> > which of the two it's dealing with, and either accept the value as-is,
> > or sort the value list. While I suppose it could sort the value list
> > in either case, I'd prefer the ACPI value to be exposed in its own
> > file, perhaps 'acpi_index', to make this explicit rather than
> > implicit.
> >
> > 'label' is fine for either case, with ACPI taking priority over
> > SMBIOS if both happen to be present.
> >
Applied, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH] tracing, perf : add cpu hotplug trace events
From: Vincent Guittot @ 2011-01-07 18:25 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: linux-kernel, linux-hotplug, Steven Rostedt, Ingo Molnar,
Rusty Russell, Amit Kucheria
In-Reply-To: <20110107151200.GB1736@nowhere>
On 7 January 2011 16:12, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Tue, Jan 04, 2011 at 10:50:36AM +0100, Vincent Guittot wrote:
>> Please find below a proposal for adding new trace events for cpu
>> hotplug.The goal is to measure the latency of each part (kernel,
>> architecture and platform) and also to trace the cpu hotplug activity
>> with other power events. I have tested these traces events on an arm
>> platform
>>
>> Comments are welcome.
>>
>> Date: Wed, 15 Dec 2010 11:22:21 +0100
>> Subject: [PATCH] hotplug tracepoint
>>
>> this patch adds new events for cpu hotplug tracing
>> * plug/unplug sequence
>> * architecture and machine latency measurements
>>
>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>> ---
>> include/trace/events/hotplug.h | 71 ++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 71 insertions(+), 0 deletions(-)
>> create mode 100644 include/trace/events/hotplug.h
>>
>> diff --git a/include/trace/events/hotplug.h b/include/trace/events/hotplug.h
>> new file mode 100644
>> index 0000000..51c86ab
>> --- /dev/null
>> +++ b/include/trace/events/hotplug.h
>> @@ -0,0 +1,71 @@
>> +#undef TRACE_SYSTEM
>> +#define TRACE_SYSTEM hotplug
>> +
>> +#if !defined(_TRACE_HOTPLUG_H) || defined(TRACE_HEADER_MULTI_READ)
>> +#define _TRACE_HOTPLUG_H
>> +
>> +#include <linux/ktime.h>
>> +#include <linux/tracepoint.h>
>> +
>> +#ifndef _TRACE_HOTPLUG_ENUM_
>> +#define _TRACE_HOTPLUG_ENUM_
>> +enum hotplug_type {
>> + HOTPLUG_UNPLUG = 0,
>> + HOTPLUG_PLUG = 1
>> +};
>> +
>> +enum hotplug_step {
>> + HOTPLUG_KERNEL = 0,
>> + HOTPLUG_ARCH = 1,
>> + HOTPLUG_MACH = 2
>> +};
>> +#endif
>> +
>> +TRACE_EVENT(hotplug_start,
>
> hotplug is way too generic.
>
> cpu_hotplug may be?
>
that's fine for me
>> +
>> + TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid),
>
> I feel a bit uncomfortable with these opaque type and step.
>
> What about splitting the events:
>
> cpu_down_start
> cpu_down_end
>
> cpu_up_start
> cpu_up_end
>
> This ways they are much more self-explanatory.
>
> I also feel uncomfortable about exposing arch step details in core
> tracepoints.
>
> But if we consider the following sequence:
>
> cpu_down() {
> __cpu_disable() {
> platform_cpu_disable();
> }
> }
>
> Then exposing start/end of cpu_disable() makes sense, by way of:
>
> cpu_arch_disable_start
> cpu_arch_disable_end
>
> cpu_arch_enable_start
> cpu_arch_enable_end
>
>
> cpu_arch_die_start
> cpu_arch_die_end
>
> cpu_arch_die_start
> cpu_arch_die_end
>
> Because they are arch events that you can retrieve everywhere, the tracepoints
> are still called from the code code.
>
> Now for the machine part, it's very highly arch specific, most notably for arm
> so I wonder if it would make more sense to keep that seperate into arch
> tracepoints.
>
May be we could find some event names that matches for all system and
that can be kept in the same file ?
> How does that all look? I hope I'm not overengineering.
>
that's could be ok for me, I can find almost the same kind of
information with this solution. I just wonder what traces are the
easiest to treat for extracting some latency measurement or to treat
with other event like the power event.
> Creating such series of similar tracepoints is quite easy and quick using
> DECLARE_EVENT_CLASS and DEFINE_EVENT.
>
ok
>> +
>> + TP_ARGS(type, step, cpuid),
>> +
>> + TP_STRUCT__entry(
>> + __field(u32, type)
>> + __field(u32, step)
>> + __field(u32, cpuid)
>> + ),
>
> And please use a proper indentation for trace_events.
> You can have a look at the examples in include/trace/events/
>
ok, i will take example from include/trace/events/
^ permalink raw reply
* Re: [PATCH] tracing, perf : add cpu hotplug trace events
From: Steven Rostedt @ 2011-01-07 15:52 UTC (permalink / raw)
To: Amit Kucheria; +Cc: Vincent Guittot, linux-kernel, linux-hotplug, fweisbec
In-Reply-To: <AANLkTik0i5xeNG_+tgdfWRjC1cQAbm+-0fDNGih5KfRx@mail.gmail.com>
On Fri, 2011-01-07 at 14:51 +0530, Amit Kucheria wrote:
> > +
> > +TRACE_EVENT(hotplug_start,
> > +
> > + TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid),
> > +
> > + TP_ARGS(type, step, cpuid),
> > +
> > + TP_STRUCT__entry(
> > + __field(u32, type)
> > + __field(u32, step)
> > + __field(u32, cpuid)
> > + ),
> > +
> > + TP_fast_assign(
> > + __entry->type = type;
> > + __entry->step = step;
> > + __entry->cpuid = cpuid;
> > + ),
> > +
> > + TP_printk("type=%lu step=%lu cpuid=%lu", (unsigned long)__entry->type,
> > + (unsigned long)__entry->step, (unsigned long)__entry->cpuid)
> > +);
> > +
> > +TRACE_EVENT(hotplug_end,
> > +
> > + TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid),
> > +
> > + TP_ARGS(type, step, cpuid),
> > +
> > + TP_STRUCT__entry(
> > + __field(u32, type)
> > + __field(u32, step)
> > + __field(u32, cpuid)
> > + ),
> > +
> > + TP_fast_assign(
> > + __entry->type = type;
> > + __entry->step = step;
> > + __entry->cpuid = cpuid;
> > + ),
> > +
> > + TP_printk("type=%lu step=%lu cpuid=%lu", (unsigned long)__entry->type,
> > + (unsigned long)__entry->step, (unsigned long)__entry->cpuid)
> > +);
> > +
> >
Please use classes when having tracepoints that have the same fields.
This will save a bit of kernel memory. Something like:
DECLARE_EVENT_CLASS(hotplug_template,
TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid),
TP_ARGS(type, step, cpuid),
TP_STRUCT__entry(
__field(u32, type)
__field(u32, step)
__field(u32, cpuid)
),
TP_fast_assign(
__entry->type = type;
__entry->step = step;
__entry->cpuid = cpuid;
),
TP_printk("type=%lu step=%lu cpuid=%lu", (unsigned long)__entry->type,
(unsigned long)__entry->step, (unsigned long)__entry->cpuid)
);
DEFINE_EVENT(hotplug_template, hotplug_start,
TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid),
TP_ARGS(type, step, cpuid);
DEFINE_EVENT(hotplug_template, hotplug_end,
TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid),
TP_ARGS(type, step, cpuid);
-- Steve
^ permalink raw reply
* Re: [PATCH] tracing, perf : add cpu hotplug trace events
From: Frederic Weisbecker @ 2011-01-07 15:12 UTC (permalink / raw)
To: Vincent Guittot
Cc: linux-kernel, linux-hotplug, Steven Rostedt, Ingo Molnar,
Rusty Russell, Amit Kucheria
In-Reply-To: <AANLkTimsR3=BKSF8EyASu4_T_vTznw4yEqmxPS8gOQCy@mail.gmail.com>
On Tue, Jan 04, 2011 at 10:50:36AM +0100, Vincent Guittot wrote:
> Please find below a proposal for adding new trace events for cpu
> hotplug.The goal is to measure the latency of each part (kernel,
> architecture and platform) and also to trace the cpu hotplug activity
> with other power events. I have tested these traces events on an arm
> platform
>
> Comments are welcome.
>
> Date: Wed, 15 Dec 2010 11:22:21 +0100
> Subject: [PATCH] hotplug tracepoint
>
> this patch adds new events for cpu hotplug tracing
> * plug/unplug sequence
> * architecture and machine latency measurements
>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> include/trace/events/hotplug.h | 71 ++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 71 insertions(+), 0 deletions(-)
> create mode 100644 include/trace/events/hotplug.h
>
> diff --git a/include/trace/events/hotplug.h b/include/trace/events/hotplug.h
> new file mode 100644
> index 0000000..51c86ab
> --- /dev/null
> +++ b/include/trace/events/hotplug.h
> @@ -0,0 +1,71 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM hotplug
> +
> +#if !defined(_TRACE_HOTPLUG_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_HOTPLUG_H
> +
> +#include <linux/ktime.h>
> +#include <linux/tracepoint.h>
> +
> +#ifndef _TRACE_HOTPLUG_ENUM_
> +#define _TRACE_HOTPLUG_ENUM_
> +enum hotplug_type {
> + HOTPLUG_UNPLUG = 0,
> + HOTPLUG_PLUG = 1
> +};
> +
> +enum hotplug_step {
> + HOTPLUG_KERNEL = 0,
> + HOTPLUG_ARCH = 1,
> + HOTPLUG_MACH = 2
> +};
> +#endif
> +
> +TRACE_EVENT(hotplug_start,
hotplug is way too generic.
cpu_hotplug may be?
> +
> + TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid),
I feel a bit uncomfortable with these opaque type and step.
What about splitting the events:
cpu_down_start
cpu_down_end
cpu_up_start
cpu_up_end
This ways they are much more self-explanatory.
I also feel uncomfortable about exposing arch step details in core
tracepoints.
But if we consider the following sequence:
cpu_down() {
__cpu_disable() {
platform_cpu_disable();
}
}
Then exposing start/end of cpu_disable() makes sense, by way of:
cpu_arch_disable_start
cpu_arch_disable_end
cpu_arch_enable_start
cpu_arch_enable_end
cpu_arch_die_start
cpu_arch_die_end
cpu_arch_die_start
cpu_arch_die_end
Because they are arch events that you can retrieve everywhere, the tracepoints
are still called from the code code.
Now for the machine part, it's very highly arch specific, most notably for arm
so I wonder if it would make more sense to keep that seperate into arch
tracepoints.
How does that all look? I hope I'm not overengineering.
Creating such series of similar tracepoints is quite easy and quick using
DECLARE_EVENT_CLASS and DEFINE_EVENT.
> +
> + TP_ARGS(type, step, cpuid),
> +
> + TP_STRUCT__entry(
> + __field(u32, type)
> + __field(u32, step)
> + __field(u32, cpuid)
> + ),
And please use a proper indentation for trace_events.
You can have a look at the examples in include/trace/events/
^ permalink raw reply
* Re: [PATCH] tracing, perf : add cpu hotplug trace events
From: Vincent Guittot @ 2011-01-07 12:07 UTC (permalink / raw)
To: Amit Kucheria; +Cc: linux-kernel, linux-hotplug, rostedt, fweisbec
In-Reply-To: <AANLkTik0i5xeNG_+tgdfWRjC1cQAbm+-0fDNGih5KfRx@mail.gmail.com>
On 7 January 2011 10:21, Amit Kucheria <amit.kucheria@linaro.org> wrote:
> Vincent,
>
> Adding Steve Rostedt and Frederic Weisbecker to CC list as maintainers
> of the trace subsystem
>
> Also, a sample patch against your SoC on how you plan to use this
> might be useful. You can mark the patch as RFC for now.
>
I'm going to prepare a sample patch based on my SoC.
The trace output with current proposal looks like below on my SoC . I
have added some comments :
# tracer: nop
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
bash-3603 [000] 133.012161: hotplug_start: type=1 step=0
cpuid=1 Start to plug cpu1
bash-3603 [000] 133.032270: hotplug_start: type=1 step=1
cpuid=1 boot_secondary
<idle>-0 [001] 133.032372: hotplug_end: type=1 step=2
cpuid=1 cpu1 is up
bash-3603 [000] 133.032448: hotplug_end: type=1 step=1
cpuid=1 cpu1 is online
bash-3603 [000] 133.074754: hotplug_end: type=1 step=0
cpuid=1 End of the plug sequence
> More comments below.
>
> On Tue, Jan 4, 2011 at 3:20 PM, Vincent Guittot
> <vincent.guittot@linaro.org> wrote:
>> Please find below a proposal for adding new trace events for cpu
>> hotplug.The goal is to measure the latency of each part (kernel,
>> architecture and platform) and also to trace the cpu hotplug activity
>> with other power events. I have tested these traces events on an arm
>> platform
>>
>> Comments are welcome.
>>
>> Date: Wed, 15 Dec 2010 11:22:21 +0100
>> Subject: [PATCH] hotplug tracepoint
>>
>> this patch adds new events for cpu hotplug tracing
>> * plug/unplug sequence
>> * architecture and machine latency measurements
>>
>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>> ---
>> include/trace/events/hotplug.h | 71 ++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 71 insertions(+), 0 deletions(-)
>> create mode 100644 include/trace/events/hotplug.h
>>
>> diff --git a/include/trace/events/hotplug.h b/include/trace/events/hotplug.h
>> new file mode 100644
>> index 0000000..51c86ab
>> --- /dev/null
>> +++ b/include/trace/events/hotplug.h
>> @@ -0,0 +1,71 @@
>> +#undef TRACE_SYSTEM
>> +#define TRACE_SYSTEM hotplug
>> +
>> +#if !defined(_TRACE_HOTPLUG_H) || defined(TRACE_HEADER_MULTI_READ)
>> +#define _TRACE_HOTPLUG_H
>> +
>> +#include <linux/ktime.h>
>> +#include <linux/tracepoint.h>
>> +
>> +#ifndef _TRACE_HOTPLUG_ENUM_
>> +#define _TRACE_HOTPLUG_ENUM_
>> +enum hotplug_type {
>> + HOTPLUG_UNPLUG = 0,
>> + HOTPLUG_PLUG = 1
>> +};
>> +
>> +enum hotplug_step {
>> + HOTPLUG_KERNEL = 0,
>> + HOTPLUG_ARCH = 1,
>> + HOTPLUG_MACH = 2
>> +};
>> +#endif
>
> s/HOTPLUG_KERNEL/HOTPLUG_CORE/ ?
>
ok, I'm going to change for HOTPLUG_CORE
> Comments regarding what these mean would be nice. ARM has core, arch
> and machine level configuration, but x86, for example might not use
> machine at all.
>
ok, I'm going to add comments
The hotplug_step are used to define which kind of code is running.
-The HOTPLUG_CORE refers to code that is used whatever the system is.
-The HOTPLUG_ARCH refers to code that is dedicated to an architecture.
Typically, the 3 functions:
__cpu_up(), __cpu_disable() and __cpu_die().
-The HOTPLUG_MACH is used by architectures which have some dedicated
SW for shutting down the cpu like on Arm SoC. For the Arm
architecture, the machine step is linked to the platform_cpu_die
function.
>> +
>> +TRACE_EVENT(hotplug_start,
>> +
>> + TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid),
>> +
>> + TP_ARGS(type, step, cpuid),
>> +
>> + TP_STRUCT__entry(
>> + __field(u32, type)
>> + __field(u32, step)
>> + __field(u32, cpuid)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->type = type;
>> + __entry->step = step;
>> + __entry->cpuid = cpuid;
>> + ),
>> +
>> + TP_printk("type=%lu step=%lu cpuid=%lu", (unsigned long)__entry->type,
>> + (unsigned long)__entry->step, (unsigned long)__entry->cpuid)
>> +);
>> +
>> +TRACE_EVENT(hotplug_end,
>> +
>> + TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid),
>> +
>> + TP_ARGS(type, step, cpuid),
>> +
>> + TP_STRUCT__entry(
>> + __field(u32, type)
>> + __field(u32, step)
>> + __field(u32, cpuid)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->type = type;
>> + __entry->step = step;
>> + __entry->cpuid = cpuid;
>> + ),
>> +
>> + TP_printk("type=%lu step=%lu cpuid=%lu", (unsigned long)__entry->type,
>> + (unsigned long)__entry->step, (unsigned long)__entry->cpuid)
>> +);
>> +
>> +#endif /* _TRACE_HOTPLUG_H */
>> +
>> +/* This part must be outside protection */
>> +#include <trace/define_trace.h>
>> --
>> 1.7.0.4
>
^ permalink raw reply
* Re: [PATCH] tracing, perf : add cpu hotplug trace events
From: Amit Kucheria @ 2011-01-07 9:33 UTC (permalink / raw)
To: Vincent Guittot; +Cc: linux-kernel, linux-hotplug, rostedt, fweisbec
In-Reply-To: <AANLkTimsR3=BKSF8EyASu4_T_vTznw4yEqmxPS8gOQCy@mail.gmail.com>
Vincent,
Adding Steve Rostedt and Frederic Weisbecker to CC list as maintainers
of the trace subsystem
Also, a sample patch against your SoC on how you plan to use this
might be useful. You can mark the patch as RFC for now.
More comments below.
On Tue, Jan 4, 2011 at 3:20 PM, Vincent Guittot
<vincent.guittot@linaro.org> wrote:
> Please find below a proposal for adding new trace events for cpu
> hotplug.The goal is to measure the latency of each part (kernel,
> architecture and platform) and also to trace the cpu hotplug activity
> with other power events. I have tested these traces events on an arm
> platform
>
> Comments are welcome.
>
> Date: Wed, 15 Dec 2010 11:22:21 +0100
> Subject: [PATCH] hotplug tracepoint
>
> this patch adds new events for cpu hotplug tracing
> * plug/unplug sequence
> * architecture and machine latency measurements
>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> include/trace/events/hotplug.h | 71 ++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 71 insertions(+), 0 deletions(-)
> create mode 100644 include/trace/events/hotplug.h
>
> diff --git a/include/trace/events/hotplug.h b/include/trace/events/hotplug.h
> new file mode 100644
> index 0000000..51c86ab
> --- /dev/null
> +++ b/include/trace/events/hotplug.h
> @@ -0,0 +1,71 @@
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM hotplug
> +
> +#if !defined(_TRACE_HOTPLUG_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_HOTPLUG_H
> +
> +#include <linux/ktime.h>
> +#include <linux/tracepoint.h>
> +
> +#ifndef _TRACE_HOTPLUG_ENUM_
> +#define _TRACE_HOTPLUG_ENUM_
> +enum hotplug_type {
> + HOTPLUG_UNPLUG = 0,
> + HOTPLUG_PLUG = 1
> +};
> +
> +enum hotplug_step {
> + HOTPLUG_KERNEL = 0,
> + HOTPLUG_ARCH = 1,
> + HOTPLUG_MACH = 2
> +};
> +#endif
s/HOTPLUG_KERNEL/HOTPLUG_CORE/ ?
Comments regarding what these mean would be nice. ARM has core, arch
and machine level configuration, but x86, for example might not use
machine at all.
> +
> +TRACE_EVENT(hotplug_start,
> +
> + TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid),
> +
> + TP_ARGS(type, step, cpuid),
> +
> + TP_STRUCT__entry(
> + __field(u32, type)
> + __field(u32, step)
> + __field(u32, cpuid)
> + ),
> +
> + TP_fast_assign(
> + __entry->type = type;
> + __entry->step = step;
> + __entry->cpuid = cpuid;
> + ),
> +
> + TP_printk("type=%lu step=%lu cpuid=%lu", (unsigned long)__entry->type,
> + (unsigned long)__entry->step, (unsigned long)__entry->cpuid)
> +);
> +
> +TRACE_EVENT(hotplug_end,
> +
> + TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid),
> +
> + TP_ARGS(type, step, cpuid),
> +
> + TP_STRUCT__entry(
> + __field(u32, type)
> + __field(u32, step)
> + __field(u32, cpuid)
> + ),
> +
> + TP_fast_assign(
> + __entry->type = type;
> + __entry->step = step;
> + __entry->cpuid = cpuid;
> + ),
> +
> + TP_printk("type=%lu step=%lu cpuid=%lu", (unsigned long)__entry->type,
> + (unsigned long)__entry->step, (unsigned long)__entry->cpuid)
> +);
> +
> +#endif /* _TRACE_HOTPLUG_H */
> +
> +/* This part must be outside protection */
> +#include <trace/define_trace.h>
> --
> 1.7.0.4
^ permalink raw reply
* Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c
From: Ozan Çağlayan @ 2011-01-07 8:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D263BF6.6050305@verizon.net>
Cuma 07 Ocak 2011 günü (saat 00:29:27) Greg KH şunları yazmıştı:
> On Thu, Jan 06, 2011 at 05:02:30PM -0500, John Stanley wrote:
> > Hello,
> > There is a problem in udev-165/extras/ata_id/ata_id.c resulting in
> > random early boot kernel panics. As it stands, udev-165 is not
> > usable because the boot panics occur to frequently. The systems are
> > GNU/Linux i686 with linux-2.6.36.2 and linux-2.6.37, gcc-4.5.1, and
> > glibc-2.12.1.
>
> What is the kernel oops message? That should be fixed first, no
> userspace code should be able to crash the kernel.
http://www.edgrochowski.com/photos-lq/kernel-panic-12-28-10.png
I never thought that it was related to udev but one of our users posted that exact
oops screenshot to our bugzilla too.
Udev is 165 on this installation. I'll ask him if he can consistently repeat the problem.
He thought that the oops happens when the installer scans the disks.
---
Ozan Çağlayan
TUBITAK/UEKAE - Pardus Linux
http://www.pardus.org.tr/eng
^ permalink raw reply
* Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c
From: Robby Workman @ 2011-01-07 2:13 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D263BF6.6050305@verizon.net>
On Thu, 6 Jan 2011 14:29:27 -0800
Greg KH <greg@kroah.com> wrote:
> On Thu, Jan 06, 2011 at 05:02:30PM -0500, John Stanley wrote:
> > Hello,
> > There is a problem in udev-165/extras/ata_id/ata_id.c resulting in
> > random early boot kernel panics. As it stands, udev-165 is not
> > usable because the boot panics occur to frequently. The systems are
> > GNU/Linux i686 with linux-2.6.36.2 and linux-2.6.37, gcc-4.5.1, and
> > glibc-2.12.1.
>
> What is the kernel oops message? That should be fixed first, no
> userspace code should be able to crash the kernel.
Hi Greg,
First, sorry for not posting something about this sooner - I'd
pinged Kay on IRC about it, and I *promise* I had planned to
forward it to the scsi/ati guys, but work has been hell this
week. Anyway, here's the initial report we got about it, along
with a lot of debugging by other folks (including the OP, who
I think is 'resonance' in that thread):
http://www.linuxquestions.org/questions/slackware-14/current-randomly-timed-kernel-oops-on-bootup-of-two-test-boxen-852843/
-RW
^ permalink raw reply
* Re: Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c
From: Greg KH @ 2011-01-06 22:29 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4D263BF6.6050305@verizon.net>
On Thu, Jan 06, 2011 at 05:02:30PM -0500, John Stanley wrote:
> Hello,
> There is a problem in udev-165/extras/ata_id/ata_id.c resulting in
> random early boot kernel panics. As it stands, udev-165 is not
> usable because the boot panics occur to frequently. The systems are
> GNU/Linux i686 with linux-2.6.36.2 and linux-2.6.37, gcc-4.5.1, and
> glibc-2.12.1.
What is the kernel oops message? That should be fixed first, no
userspace code should be able to crash the kernel.
thanks,
greg k-h
^ permalink raw reply
* Early-boot kernel panics from udev-165/extras/ata_id/ata_id.c
From: John Stanley @ 2011-01-06 22:02 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 2584 bytes --]
Hello,
There is a problem in udev-165/extras/ata_id/ata_id.c resulting in
random early boot kernel panics. As it stands, udev-165 is not usable
because the boot panics occur to frequently. The systems are GNU/Linux
i686 with linux-2.6.36.2 and linux-2.6.37, gcc-4.5.1, and glibc-2.12.1.
By "random," I mean that the panics don't occur on every boot, or on
every pc I've tried. The panics do not occur for udev-164. The problem
code in udev-165 is in the "disk_identify_packet_device_command"
function (see line 270) where an sg3 'ATA Pass-Through' command is
issued to a cd/dvd device:
253 ret = ioctl(fd, SG_IO, &io_v4);
254 if (ret != 0) {
255 /* could be that the driver doesn't do version 4,
try version 3 */
256 if (errno == EINVAL) {
257 struct sg_io_hdr io_hdr;
258
259 memset(&io_hdr, 0, sizeof(struct sg_io_hdr));
260 io_hdr.interface_id = 'S';
261 io_hdr.cmdp = (unsigned char*) cdb;
262 io_hdr.cmd_len = sizeof (cdb);
263 io_hdr.dxferp = buf;
264 io_hdr.dxfer_len = buf_len;
265 io_hdr.sbp = sense;
266 io_hdr.mx_sb_len = sizeof (sense);
267 io_hdr.dxfer_direction = SG_DXFER_FROM_DEV;
268 io_hdr.timeout = COMMAND_TIMEOUT_MSEC;
269
270 ret = ioctl(fd, SG_IO, &io_hdr); <-- random
kernel panics result from this call ***
271 if (ret != 0)
272 goto out;
273 } else {
274 goto out;
275 }
276 }
277
278 if (!(sense[0] == 0x72 && desc[0] == 0x9 && desc[1] == 0x0c)) {
279 errno = EIO;
280 ret = -1;
281 goto out;
282 }
283
284 out:
285 return ret;
286 }
While by no means a fix of course, simply commenting out line 270 above
appears to side-step the issue. Also, suspecting a buffer alignment
issue, I built udev-165 with the attached patch, and thus far, no kernel
panics have occurred.
I realize that allocating the sense and response buffers in this manner
shouldn't be necessary or even a good idea; my hope is that it might
shed some light on the cause of the panics. I suspect that this issue is
likely a kernel problem (not a udev problem), but do you have any
thoughts/ideas on how to track down the problem?
John
[-- Attachment #2: 02-udev-165-ata-pass-through-memalign.patch --]
[-- Type: text/plain, Size: 1378 bytes --]
--- udev-165.old/extras/ata_id/ata_id.c 2010-11-09 19:30:53.000000000 -0500
+++ udev-165.new/extras/ata_id/ata_id.c 2011-01-05 03:11:06.629999372 -0500
@@ -208,7 +208,9 @@
{
struct sg_io_v4 io_v4;
uint8_t cdb[16];
- uint8_t sense[32];
+ // Allocate page-aligned memory, rather than using an array (uint8_t sense[32]); jps
+ uint8_t* sense;
+ posix_memalign((void**)&sense, sysconf(_SC_PAGESIZE), 32);
uint8_t *desc = sense+8;
int ret;
@@ -251,7 +253,7 @@
io_v4.timeout = COMMAND_TIMEOUT_MSEC;
ret = ioctl(fd, SG_IO, &io_v4);
- if (ret != 0) {
+ if (ret < 0) {
/* could be that the driver doesn't do version 4, try version 3 */
if (errno == EINVAL) {
struct sg_io_hdr io_hdr;
@@ -268,7 +270,7 @@
io_hdr.timeout = COMMAND_TIMEOUT_MSEC;
ret = ioctl(fd, SG_IO, &io_hdr);
- if (ret != 0)
+ if (ret < 0)
goto out;
} else {
goto out;
@@ -282,6 +284,7 @@
}
out:
+ free(sense);
return ret;
}
@@ -447,7 +450,9 @@
{
struct udev *udev;
struct hd_driveid id;
- uint8_t identify[512];
+ // Allocate page-aligned memory, rather than using an array (uint8_t identify[512]); jps
+ uint8_t* identify;
+ posix_memalign((void**)&identify, sysconf(_SC_PAGESIZE), 512);
char model[41];
char model_enc[256];
char serial[21];
@@ -709,5 +714,6 @@
exit:
udev_unref(udev);
udev_log_close();
+ free(identify);
return rc;
}
^ permalink raw reply
* Re: [PATCH] Export ACPI _DSM provided firmware instance number and
From: Jesse Barnes @ 2011-01-05 22:46 UTC (permalink / raw)
To: Matt Domsch
Cc: Narendra_K, linux-pci, linux-hotplug, netdev, Jordan_Hargrave,
Charles_Rose, Vijay_Nijhawan
In-Reply-To: <20110105224404.GB4647@auslistsprd01.us.dell.com>
On Wed, 5 Jan 2011 16:44:04 -0600
Matt Domsch <Matt_Domsch@Dell.com> wrote:
> On Thu, Dec 23, 2010 at 11:24:36AM -0800, Narendra_K@Dell.com wrote:
> > Please find the version 2 of the patch.
> >
> > V1 -> V2:
> >
> > The attribute 'index' is changed to 'acpi_index' as the semantics of
> > SMBIOS provided device type instance and ACPI _DSM provided instance
> > number are different.
> >
> > From: Narendra K <narendra_k@dell.com>
> > Subject: [PATCH V2] Export ACPI _DSM provided firmware instance number and string to sysfs
> >
> > This patch exports ACPI _DSM (Device Specific Method) provided firmware
> > instance number and string name of PCI devices as defined by
> > 'PCI Firmware Specification Revision 3.1' section 4.6.7.( DSM for Naming
> > a PCI or PCI Express Device Under Operating Systems) to sysfs.
>
> Thanks Narendra and Jordan.
>
> Jesse, how does this look for -next please?
I think it's fine; I'll check it out again and apply this week.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH] Export ACPI _DSM provided firmware instance number and string name to sysfs
From: Matt Domsch @ 2011-01-05 22:44 UTC (permalink / raw)
To: Narendra_K, Jesse Barnes
Cc: linux-pci, linux-hotplug, netdev, Jordan_Hargrave, Charles_Rose,
Vijay_Nijhawan
In-Reply-To: <20101223194927.GA2717@fedora14-r610.oslab.blr.amer.dell.com>
On Thu, Dec 23, 2010 at 11:24:36AM -0800, Narendra_K@Dell.com wrote:
> Please find the version 2 of the patch.
>
> V1 -> V2:
>
> The attribute 'index' is changed to 'acpi_index' as the semantics of
> SMBIOS provided device type instance and ACPI _DSM provided instance
> number are different.
>
> From: Narendra K <narendra_k@dell.com>
> Subject: [PATCH V2] Export ACPI _DSM provided firmware instance number and string to sysfs
>
> This patch exports ACPI _DSM (Device Specific Method) provided firmware
> instance number and string name of PCI devices as defined by
> 'PCI Firmware Specification Revision 3.1' section 4.6.7.( DSM for Naming
> a PCI or PCI Express Device Under Operating Systems) to sysfs.
Thanks Narendra and Jordan.
Jesse, how does this look for -next please?
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Udev GPT GUID support
From: KESHAV P.R. @ 2011-01-05 19:25 UTC (permalink / raw)
To: linux-hotplug
Hi all,
I am not a programmer, just a user. I use Archlinux x86_64
and I was thinking about using Unique GUID of a GPT partition to
identify root partition from the bootloader's (syslinux and grub2 in
my case) kernel parameter line. Right now I use
root=/dev/disk/by-uuid/xxxxxxxxxxxxx (FS-UUID) and want to try
PART-UUID. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;hµaf921ec02333e943efb59aca4f56b78fc0e100
does not work in my case (x86_64 kernel 2.6.37-rc8). How about
creating /dev/disk/by-part-uuid/xxxxxxx symlinks and renaming the
previous dir to /dev/disk/by-fs-uuid/xxxxxxxxxx (for clarity). The
Unique GUID can be obtained using GPT fdisk
http://rodsbooks.com/gdisk/ (I do not know whether util-linux-ng can
be used here). Thanks in advance.
Regards.
Keshav
^ permalink raw reply
* VFS issue with hardware-encrypted usb devices
From: Guillaume Rousse @ 2011-01-05 13:27 UTC (permalink / raw)
To: linux-hotplug
(This is a repost of a message I originally sent to lkml, which seems a
better fit there).
Hello.
I'm currently playing with hardware-encrypted Imation defender USB
devices, which are USB keys/drives, using password and/or fingerprint
sensors for unlocking content:
http://www.imation.com/en-us/Imation-Products/
The main issue is that they are automatically mounted under gnome (and I
guess all other modern desktop) before being unlocked, and the VFS
doesn't likes the behind-the-scene changes very much.
Here the syslog trace when plugging (the normal partition is seen as a
CD-ROM, the encrypted one as a standard removal drive):
Jan 3 15:14:07 beria kernel: : usb 2-1: new high speed USB device using
ehci_hcd and address 8
Jan 3 15:14:08 beria kernel: : usb 2-1: New USB device found,
idVendor\a18, idProduct\x0682
Jan 3 15:14:08 beria kernel: : usb 2-1: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
Jan 3 15:14:08 beria kernel: : usb 2-1: Product: Defender F200
Jan 3 15:14:08 beria kernel: : usb 2-1: Manufacturer: Imation
Jan 3 15:14:08 beria kernel: : usb 2-1: SerialNumber: F5121031F003008E
Jan 3 15:14:08 beria kernel: : scsi10 : usb-storage 2-1:1.0
Jan 3 15:14:09 beria kernel: : scsi 10:0:0:0: CD-ROM
Defender F200 Application 0001 PQ: 0 ANSI: 2
Jan 3 15:14:09 beria kernel: : sr0: scsi-1 drive
Jan 3 15:14:09 beria kernel: : sr 10:0:0:0: Attached scsi generic sg1
type 5
Jan 3 15:14:09 beria kernel: : scsi 10:0:0:1: Direct-Access
Defender F200 Private 0001 PQ: 0 ANSI: 2
Jan 3 15:14:09 beria kernel: : sd 10:0:0:1: Attached scsi generic sg2
type 0
Jan 3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] 18434 512-byte
logical blocks: (9.43 MB/9.00 MiB)
Jan 3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] Write Protect is off
Jan 3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] Assuming drive cache:
write through
Jan 3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] Assuming drive cache:
write through
Jan 3 15:14:09 beria kernel: : sdb:
Jan 3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] Assuming drive cache:
write through
Jan 3 15:14:09 beria kernel: : sd 10:0:0:1: [sdb] Attached SCSI
removable disk
Then unlocking is performed, by sweeping fingerprint sensor, and the
hardware change, triggering issues:
Jan 3 15:14:21 beria kernel: : VFS: busy inodes on changed media or
resized disk sdb
Jan 3 15:14:21 beria kernel: : sd 10:0:0:1: [sdb] 3393536 512-byte
logical blocks: (1.73 GB/1.61 GiB)
Jan 3 15:14:21 beria kernel: : sd 10:0:0:1: [sdb] Assuming drive cache:
write through
Jan 3 15:14:40 beria kernel: : FAT: Filesystem error (dev sdb)
Jan 3 15:14:40 beria kernel: : fat_get_cluster: invalid cluster chain
(i_pos 262)
Jan 3 15:14:40 beria kernel: : FAT: Filesystem has been set read-only
Jan 3 15:14:40 beria kernel: : FAT: Filesystem error (dev sdb)
If I'm quick enough at jumping on sensor to unlock at mount time,
everything works fine, meaning the real issue is changing partition
status when already mounted.
I don't know how this issue should be properly handled. Should the VFS
be aware than some kind of exotic hardware are able to perform this kind
of tricks ? Should the automounter be able to manage those kind of
device by not mouting them automatically, at least until they reach
proper state ?
--
BOFH excuse #31:
cellular telephone interference
^ permalink raw reply
* [PATCH] tracing, perf : add cpu hotplug trace events
From: Vincent Guittot @ 2011-01-04 9:50 UTC (permalink / raw)
To: linux-kernel, linux-hotplug
Please find below a proposal for adding new trace events for cpu
hotplug.The goal is to measure the latency of each part (kernel,
architecture and platform) and also to trace the cpu hotplug activity
with other power events. I have tested these traces events on an arm
platform
Comments are welcome.
Date: Wed, 15 Dec 2010 11:22:21 +0100
Subject: [PATCH] hotplug tracepoint
this patch adds new events for cpu hotplug tracing
* plug/unplug sequence
* architecture and machine latency measurements
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
include/trace/events/hotplug.h | 71 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 71 insertions(+), 0 deletions(-)
create mode 100644 include/trace/events/hotplug.h
diff --git a/include/trace/events/hotplug.h b/include/trace/events/hotplug.h
new file mode 100644
index 0000000..51c86ab
--- /dev/null
+++ b/include/trace/events/hotplug.h
@@ -0,0 +1,71 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM hotplug
+
+#if !defined(_TRACE_HOTPLUG_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_HOTPLUG_H
+
+#include <linux/ktime.h>
+#include <linux/tracepoint.h>
+
+#ifndef _TRACE_HOTPLUG_ENUM_
+#define _TRACE_HOTPLUG_ENUM_
+enum hotplug_type {
+ HOTPLUG_UNPLUG = 0,
+ HOTPLUG_PLUG = 1
+};
+
+enum hotplug_step {
+ HOTPLUG_KERNEL = 0,
+ HOTPLUG_ARCH = 1,
+ HOTPLUG_MACH = 2
+};
+#endif
+
+TRACE_EVENT(hotplug_start,
+
+ TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid),
+
+ TP_ARGS(type, step, cpuid),
+
+ TP_STRUCT__entry(
+ __field(u32, type)
+ __field(u32, step)
+ __field(u32, cpuid)
+ ),
+
+ TP_fast_assign(
+ __entry->type = type;
+ __entry->step = step;
+ __entry->cpuid = cpuid;
+ ),
+
+ TP_printk("type=%lu step=%lu cpuid=%lu", (unsigned long)__entry->type,
+ (unsigned long)__entry->step, (unsigned long)__entry->cpuid)
+);
+
+TRACE_EVENT(hotplug_end,
+
+ TP_PROTO(unsigned int type, unsigned int step, unsigned int cpuid),
+
+ TP_ARGS(type, step, cpuid),
+
+ TP_STRUCT__entry(
+ __field(u32, type)
+ __field(u32, step)
+ __field(u32, cpuid)
+ ),
+
+ TP_fast_assign(
+ __entry->type = type;
+ __entry->step = step;
+ __entry->cpuid = cpuid;
+ ),
+
+ TP_printk("type=%lu step=%lu cpuid=%lu", (unsigned long)__entry->type,
+ (unsigned long)__entry->step, (unsigned long)__entry->cpuid)
+);
+
+#endif /* _TRACE_HOTPLUG_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
1.7.0.4
^ permalink raw reply related
* Re: Failure to build ata_id
From: Kay Sievers @ 2011-01-03 23:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201101032329.45198.thomas@koeller.dyndns.org>
On Mon, Jan 3, 2011 at 23:29, Thomas Koeller <thomas@koeller.dyndns.org> wrote:
> since kernel release v2.6.35-rc1 (commit 7407e5bba2cc821950344fd1391d9ad1b7e0b397),
> scsi/scsi.h is no longer part of the exported kernel headers. Since then, it has
> not been possible to do a full build of udev anymore, because extras/ata_id/ata_id.c
> wants to include this header.
>
> I suppose new udev releases are tested with a current kernel? Am I missing something?
It's not a kernel header, it's from glibc. You need a matching glibc
for these new kernel headers.
$ rpm -qf /usr/include/scsi/scsi.h
glibc-devel-2.11.3-4.1.x86_64
Kay
^ permalink raw reply
* Failure to build ata_id
From: Thomas Koeller @ 2011-01-03 22:29 UTC (permalink / raw)
To: linux-hotplug
Hi,
since kernel release v2.6.35-rc1 (commit 7407e5bba2cc821950344fd1391d9ad1b7e0b397),
scsi/scsi.h is no longer part of the exported kernel headers. Since then, it has
not been possible to do a full build of udev anymore, because extras/ata_id/ata_id.c
wants to include this header.
I suppose new udev releases are tested with a current kernel? Am I missing something?
Thomas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox