* Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the current
From: David Henningsson @ 2011-06-17 6:17 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4DFA0F40.7000204@canonical.com>
On 2011-06-16 16:48, Takashi Iwai wrote:
> At Thu, 16 Jun 2011 16:28:08 +0200,
> Kay Sievers wrote:
>>
>> On Thu, Jun 16, 2011 at 16:12, David Henningsson
>> <david.henningsson@canonical.com> wrote:
>>> One missing piece for userspace (PulseAudio etc) to actually be able to use
>>> the jack input devices that ALSA create, is that these devices are
>>> accessible by root only. This patch makes the input device nodes accessible
>>> by the same users that can access the sound card: the current logged in
>>> user, as well as users in the audio group.
>>>
>>> One thing I was thinking about, was that the udev-acl rule actually grants
>>> read-write access to the input device node, where probably only read access
>>> is needed. Is this dangerous?
>>
>> Takashi, wasn't there already something else to use from ALSA than the
>> artificial input devices?
>
> These input devices are just notification from the sound driver at
> jack plugging, so basically it's read-only indeed, and setting the
> file permission RO would make sense.
>
> I can't judge more since I haven't seen the patch.
It was posted to alsa-devel (for comments) two days ago, see:
http://mailman.alsa-project.org/pipermail/alsa-devel/2011-June/040916.html
and
http://mailman.alsa-project.org/pipermail/alsa-devel/2011-June/040917.html
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
^ permalink raw reply
* Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the current user
From: Takashi Iwai @ 2011-06-16 15:02 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4DFA0F40.7000204@canonical.com>
At Thu, 16 Jun 2011 16:55:39 +0200,
Kay Sievers wrote:
>
> On Thu, Jun 16, 2011 at 16:48, Takashi Iwai <tiwai@suse.de> wrote:
> > At Thu, 16 Jun 2011 16:28:08 +0200,
> > Kay Sievers wrote:
> >>
> >> On Thu, Jun 16, 2011 at 16:12, David Henningsson
> >> <david.henningsson@canonical.com> wrote:
> >> > One missing piece for userspace (PulseAudio etc) to actually be able to use
> >> > the jack input devices that ALSA create, is that these devices are
> >> > accessible by root only. This patch makes the input device nodes accessible
> >> > by the same users that can access the sound card: the current logged in
> >> > user, as well as users in the audio group.
> >> >
> >> > One thing I was thinking about, was that the udev-acl rule actually grants
> >> > read-write access to the input device node, where probably only read access
> >> > is needed. Is this dangerous?
> >>
> >> Takashi, wasn't there already something else to use from ALSA than the
> >> artificial input devices?
> >
> > These input devices are just notification from the sound driver at
> > jack plugging, so basically it's read-only indeed, and setting the
> > file permission RO would make sense.
>
> Na, I mean, I remember you talking about some other channel of
> notifications about jack changes.
Ah, yeah, it's still possible to implement via ALSA control API, too.
Just add a new control element for jack notification, and the apps can
listen to it via normal ALSA API like the mixer elements.
> Didn't the input devices get replaced by something on the control
> device? Or was that just a plan?
I had some patches for it years ago, but never got merged.
If apps prefer it, I can revisit it. Meanwhile, the jack-input stuff
is already present, so it might not be worth for it.
Takashi
^ permalink raw reply
* Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the
From: Kay Sievers @ 2011-06-16 14:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4DFA0F40.7000204@canonical.com>
On Thu, Jun 16, 2011 at 16:48, Takashi Iwai <tiwai@suse.de> wrote:
> At Thu, 16 Jun 2011 16:28:08 +0200,
> Kay Sievers wrote:
>>
>> On Thu, Jun 16, 2011 at 16:12, David Henningsson
>> <david.henningsson@canonical.com> wrote:
>> > One missing piece for userspace (PulseAudio etc) to actually be able to use
>> > the jack input devices that ALSA create, is that these devices are
>> > accessible by root only. This patch makes the input device nodes accessible
>> > by the same users that can access the sound card: the current logged in
>> > user, as well as users in the audio group.
>> >
>> > One thing I was thinking about, was that the udev-acl rule actually grants
>> > read-write access to the input device node, where probably only read access
>> > is needed. Is this dangerous?
>>
>> Takashi, wasn't there already something else to use from ALSA than the
>> artificial input devices?
>
> These input devices are just notification from the sound driver at
> jack plugging, so basically it's read-only indeed, and setting the
> file permission RO would make sense.
Na, I mean, I remember you talking about some other channel of
notifications about jack changes.
Didn't the input devices get replaced by something on the control
device? Or was that just a plan?
Kay
^ permalink raw reply
* Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the current user
From: Takashi Iwai @ 2011-06-16 14:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4DFA0F40.7000204@canonical.com>
At Thu, 16 Jun 2011 16:28:08 +0200,
Kay Sievers wrote:
>
> On Thu, Jun 16, 2011 at 16:12, David Henningsson
> <david.henningsson@canonical.com> wrote:
> > One missing piece for userspace (PulseAudio etc) to actually be able to use
> > the jack input devices that ALSA create, is that these devices are
> > accessible by root only. This patch makes the input device nodes accessible
> > by the same users that can access the sound card: the current logged in
> > user, as well as users in the audio group.
> >
> > One thing I was thinking about, was that the udev-acl rule actually grants
> > read-write access to the input device node, where probably only read access
> > is needed. Is this dangerous?
>
> Takashi, wasn't there already something else to use from ALSA than the
> artificial input devices?
These input devices are just notification from the sound driver at
jack plugging, so basically it's read-only indeed, and setting the
file permission RO would make sense.
I can't judge more since I haven't seen the patch.
thanks,
Takashi
^ permalink raw reply
* Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the
From: Kay Sievers @ 2011-06-16 14:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4DFA0F40.7000204@canonical.com>
On Thu, Jun 16, 2011 at 16:12, David Henningsson
<david.henningsson@canonical.com> wrote:
> One missing piece for userspace (PulseAudio etc) to actually be able to use
> the jack input devices that ALSA create, is that these devices are
> accessible by root only. This patch makes the input device nodes accessible
> by the same users that can access the sound card: the current logged in
> user, as well as users in the audio group.
>
> One thing I was thinking about, was that the udev-acl rule actually grants
> read-write access to the input device node, where probably only read access
> is needed. Is this dangerous?
Takashi, wasn't there already something else to use from ALSA than the
artificial input devices?
Thanks,
Kay
^ permalink raw reply
* [PATCH] udev: Allow ALSA input jacks to be accessed by the current
From: David Henningsson @ 2011-06-16 14:12 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
One missing piece for userspace (PulseAudio etc) to actually be able to
use the jack input devices that ALSA create, is that these devices are
accessible by root only. This patch makes the input device nodes
accessible by the same users that can access the sound card: the current
logged in user, as well as users in the audio group.
One thing I was thinking about, was that the udev-acl rule actually
grants read-write access to the input device node, where probably only
read access is needed. Is this dangerous?
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
[-- Attachment #2: 0001-udev-Allow-ALSA-input-jacks-to-be-accessed-by-the-cu.patch --]
[-- Type: text/x-patch, Size: 3768 bytes --]
From a45276437c8c3fe62fc001f43d715bfe931dd438 Mon Sep 17 00:00:00 2001
From: David Henningsson <david.henningsson@canonical.com>
Date: Wed, 15 Jun 2011 20:36:16 +0200
Subject: [PATCH] udev: Allow ALSA input jacks to be accessed by the current user
One missing piece for userspace (PulseAudio etc) to actually be able
to use the jack input devices that ALSA create, is that these devices
are accessible by root only. This patch makes the input device nodes
accessible by the same users that can access the sound card: the current
logged in user, as well as users in the audio group.
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
---
| 23 +++++++++++++++++++++++
| 1 +
rules/rules.d/60-persistent-input.rules | 1 +
3 files changed, 25 insertions(+), 0 deletions(-)
--git a/extras/input_id/input_id.c b/extras/input_id/input_id.c
index ba53df0..814ce8e 100644
--- a/extras/input_id/input_id.c
+++ b/extras/input_id/input_id.c
@@ -189,6 +189,25 @@ static void test_key (struct udev *udev,
puts("ID_INPUT_KEYBOARD=1");
}
+static void test_sound (struct udev_device *dev,
+ const unsigned long* bitmask_sw)
+{
+
+ struct udev_device *snd_dev;
+
+ /* Ensure parent is sound card */
+ snd_dev = udev_device_get_parent_with_subsystem_devtype(dev, "sound", NULL);
+ if (!snd_dev)
+ return;
+
+ /* Check that there is at least one relevant switch type */
+ if (test_bit(SW_HEADPHONE_INSERT, bitmask_sw) ||
+ test_bit(SW_MICROPHONE_INSERT, bitmask_sw) ||
+ test_bit(SW_LINEOUT_INSERT, bitmask_sw) ||
+ test_bit(SW_VIDEOOUT_INSERT, bitmask_sw))
+ puts("ID_INPUT_SNDJACK=1");
+}
+
static void help(void)
{
printf("Usage: input_id [options] <device path>\n"
@@ -212,6 +231,7 @@ int main (int argc, char** argv)
unsigned long bitmask_abs[NBITS(ABS_MAX)];
unsigned long bitmask_key[NBITS(KEY_MAX)];
unsigned long bitmask_rel[NBITS(REL_MAX)];
+ unsigned long bitmask_sw[NBITS(SW_MAX)];
udev = udev_new();
if (udev == NULL)
@@ -272,10 +292,13 @@ int main (int argc, char** argv)
get_cap_mask (dev, "capabilities/abs", bitmask_abs, sizeof (bitmask_abs));
get_cap_mask (dev, "capabilities/rel", bitmask_rel, sizeof (bitmask_rel));
get_cap_mask (dev, "capabilities/key", bitmask_key, sizeof (bitmask_key));
+ get_cap_mask (dev, "capabilities/sw", bitmask_sw, sizeof (bitmask_sw));
test_pointers(bitmask_ev, bitmask_abs, bitmask_key, bitmask_rel);
test_key(udev, bitmask_ev, bitmask_key);
+ test_sound(dev, bitmask_sw);
+
return 0;
}
--git a/extras/udev-acl/70-acl.rules b/extras/udev-acl/70-acl.rules
index 037349d..a6f54d9 100644
--- a/extras/udev-acl/70-acl.rules
+++ b/extras/udev-acl/70-acl.rules
@@ -25,6 +25,7 @@ SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="4|5", TAG+="udev-ac
# sound devices
SUBSYSTEM=="sound", TAG+="udev-acl"
+SUBSYSTEM=="input", ENV{ID_INPUT_SNDJACK}=="1", TAG+="udev-acl"
# ffado is an userspace driver for firewire sound cards
SUBSYSTEM=="firewire", ENV{ID_FFADO}=="1", TAG+="udev-acl"
diff --git a/rules/rules.d/60-persistent-input.rules b/rules/rules.d/60-persistent-input.rules
index cd1de4e..d04c09e 100644
--- a/rules/rules.d/60-persistent-input.rules
+++ b/rules/rules.d/60-persistent-input.rules
@@ -12,6 +12,7 @@ ENV{ID_INPUT_MOUSE}=="?*", ENV{.INPUT_CLASS}="mouse"
ENV{ID_INPUT_TOUCHPAD}=="?*", ENV{.INPUT_CLASS}="mouse"
ENV{ID_INPUT_TABLET}=="?*", ENV{.INPUT_CLASS}="mouse"
ENV{ID_INPUT_JOYSTICK}=="?*", ENV{.INPUT_CLASS}="joystick"
+ENV{ID_INPUT_SNDJACK}=="?*", ENV{.INPUT_CLASS}="sndjack", GROUP="audio"
DRIVERS=="pcspkr", ENV{.INPUT_CLASS}="spkr"
ATTRS{name}=="*dvb*|*DVB*|* IR *", ENV{.INPUT_CLASS}="ir"
--
1.7.4.1
^ permalink raw reply related
* Re: udev queue error
From: Tejun Heo @ 2011-06-15 9:40 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTim9kJEroUeqpqNoE-tCRvxa5=nghw@mail.gmail.com>
Hello,
On Wed, Jun 15, 2011 at 11:34:23AM +0200, Kay Sievers wrote:
> Any idea why with the first check GET_EVENT seems, but TUR seems to
> indicate no change?
That's probably because probing logic already consumed UA. Reset
during probe also causes UA so detection logic consumes them
afterwards. I don't think driver can tell apart different UAs at that
point. If the device determines to report media change after reset
via GET_EVENT, you get a mismatch. So, it's more or less expected.
Thanks.
--
tejun
^ permalink raw reply
* Re: udev queue error
From: Kay Sievers @ 2011-06-15 9:34 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTim9kJEroUeqpqNoE-tCRvxa5=nghw@mail.gmail.com>
On Wed, Jun 15, 2011 at 09:13, Tejun Heo <htejun@gmail.com> wrote:
> Looks good to me. Just some nitpicks.
>
> On Tue, Jun 14, 2011 at 10:24:16PM +0200, Kay Sievers wrote:
>> - if (last_present != cd->media_present)
>> + if (last_present != cd->media_present) {
>> events |= DISK_EVENT_MEDIA_CHANGE;
>> + } else if (events & DISK_EVENT_MEDIA_CHANGE) {
>> + cd->tur_mismatch++;
>> + printk("sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, "
>> + "last_present %i <-> cd->media_present %i, count %i\n", last_present, cd->media_present, cd->tur_mismatch);
>
> I suppose the above printk is for debugging and will be removed when
> posting for inclusion?
>
>> + if (cd->tur_mismatch > 8) {
>> + printk("sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, "
>> + "ignoring all future GET_EVENT_STATUS_NOTIFICATION\n");
>> + cd->ignore_get_event = true;
>
> sdev_printk(KERN_WARNING, ...) would probably be a better fit.
>
>> + }
>> + } else if (cd->tur_mismatch) {
>> + printk("sr: GET_EVENT_STATUS_NOTIFICATION = TUR, "
>> + "clear mismatch count %i\n", cd->tur_mismatch);
>> + cd->tur_mismatch = 0;
>
> Ditto, we probably don't want the above in the final version.
Sure not, it's nothing to merge, I just wanted to see if we are on the
right track and how it behaves.
Any idea why with the first check GET_EVENT seems, but TUR seems to
indicate no change?
Kay
^ permalink raw reply
* Re: udev queue error
From: Tejun Heo @ 2011-06-15 7:13 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTim9kJEroUeqpqNoE-tCRvxa5=nghw@mail.gmail.com>
Hello, Kay.
Looks good to me. Just some nitpicks.
On Tue, Jun 14, 2011 at 10:24:16PM +0200, Kay Sievers wrote:
> - if (last_present != cd->media_present)
> + if (last_present != cd->media_present) {
> events |= DISK_EVENT_MEDIA_CHANGE;
> + } else if (events & DISK_EVENT_MEDIA_CHANGE) {
> + cd->tur_mismatch++;
> + printk("sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, "
> + "last_present %i <-> cd->media_present %i, count %i\n", last_present, cd->media_present, cd->tur_mismatch);
I suppose the above printk is for debugging and will be removed when
posting for inclusion?
> + if (cd->tur_mismatch > 8) {
> + printk("sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, "
> + "ignoring all future GET_EVENT_STATUS_NOTIFICATION\n");
> + cd->ignore_get_event = true;
sdev_printk(KERN_WARNING, ...) would probably be a better fit.
> + }
> + } else if (cd->tur_mismatch) {
> + printk("sr: GET_EVENT_STATUS_NOTIFICATION = TUR, "
> + "clear mismatch count %i\n", cd->tur_mismatch);
> + cd->tur_mismatch = 0;
Ditto, we probably don't want the above in the final version.
Thank you.
--
tejun
^ permalink raw reply
* Re: udev queue error
From: Kay Sievers @ 2011-06-14 20:24 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTim9kJEroUeqpqNoE-tCRvxa5=nghw@mail.gmail.com>
On Mon, 2011-06-13 at 21:02 +0200, Kay Sievers wrote:
> We follow GET_EVENT_STATUS_NOTIFICATION now. Can't we always force TUR
> when we open() the device from userland? That's what we did in the
> past, didn't we? The in-kernel polling would still not need to do
> that, and the periodic usespace polling is about to die pretty soon.
After the long discussion today between Tejun and me, something like
this *could* work. A patch with printk() debug output is below.
Every open() from userland does: GET_EVENT_STATUS_NOTIFICATION and TUR.
If the both results disagree 8 times in a row, we will only look at the
TUR results in the future.
With this I get in dmesg:
scsi 8:0:0:1: CD-ROM SanDisk U3 Cruzer Micro 8.02 PQ: 0 ANSI: 0
sr1: scsi3-mmc drive: 48x/48x tray
sr 8:0:0:1: Attached scsi CD-ROM sr1
sr 8:0:0:1: Attached scsi generic sg3 type 5
sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, last_present 1 <-> cd->media_present 1, count 1
sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, last_present 1 <-> cd->media_present 1, count 2
sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, last_present 1 <-> cd->media_present 1, count 3
sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, last_present 1 <-> cd->media_present 1, count 4
sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, last_present 1 <-> cd->media_present 1, count 5
sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, last_present 1 <-> cd->media_present 1, count 6
sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, last_present 1 <-> cd->media_present 1, count 7
sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, last_present 1 <-> cd->media_present 1, count 8
sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, last_present 1 <-> cd->media_present 1, count 9
sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, ignoring all future GET_EVENT_STATUS_NOTIFICATION
The in-kernel polling will still create a media change event every poll
interval. The rest seems to work as expected.
The other properly working devices I tried fail with the very first TUR
<-> GET_EVENT check for some reason:
scsi 7:0:0:0: CD-ROM TSSTcorp CDDVDW SE-S084B TS01 PQ: 0 ANSI: 0
sr2: scsi3-mmc drive: 8x/24x writer dvd-ram cd/rw xa/form2 cdda tray
sr 7:0:0:0: Attached scsi CD-ROM sr2
sr 7:0:0:0: Attached scsi generic sg4 type 5
sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, last_present 1 <-> cd->media_present 1, count 1
sr: GET_EVENT_STATUS_NOTIFICATION = TUR, clear mismatch count 1
Everything thing else seems to work fine.
Kay
---
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 4778e27..9023e1d 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -229,6 +229,15 @@ static unsigned int sr_check_events(struct cdrom_device_info *cdi,
if (!(clearing & DISK_EVENT_MEDIA_CHANGE))
goto skip_tur;
+ /*
+ * earlier GET_EVENT_STATUS_NOTIFICATION and TUR did not agree
+ * for a couple of times in a row, we rely on TUR only for this
+ * likely broken device, to prevent generating incorrect media
+ * changed events for every open()
+ */
+ if (cd->ignore_get_event)
+ events = 0;
+
/* let's see whether the media is there with TUR */
last_present = cd->media_present;
ret = scsi_test_unit_ready(cd->device, SR_TIMEOUT, MAX_RETRIES, &sshdr);
@@ -241,8 +250,22 @@ static unsigned int sr_check_events(struct cdrom_device_info *cdi,
cd->media_present = scsi_status_is_good(ret) ||
(scsi_sense_valid(&sshdr) && sshdr.asc != 0x3a);
- if (last_present != cd->media_present)
+ if (last_present != cd->media_present) {
events |= DISK_EVENT_MEDIA_CHANGE;
+ } else if (events & DISK_EVENT_MEDIA_CHANGE) {
+ cd->tur_mismatch++;
+ printk("sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, "
+ "last_present %i <-> cd->media_present %i, count %i\n", last_present, cd->media_present, cd->tur_mismatch);
+ if (cd->tur_mismatch > 8) {
+ printk("sr: GET_EVENT_STATUS_NOTIFICATION but TUR unchanged, "
+ "ignoring all future GET_EVENT_STATUS_NOTIFICATION\n");
+ cd->ignore_get_event = true;
+ }
+ } else if (cd->tur_mismatch) {
+ printk("sr: GET_EVENT_STATUS_NOTIFICATION = TUR, "
+ "clear mismatch count %i\n", cd->tur_mismatch);
+ cd->tur_mismatch = 0;
+ }
skip_tur:
if (cd->device->changed) {
events |= DISK_EVENT_MEDIA_CHANGE;
diff --git a/drivers/scsi/sr.h b/drivers/scsi/sr.h
index e036f1d..94a3215 100644
--- a/drivers/scsi/sr.h
+++ b/drivers/scsi/sr.h
@@ -41,6 +41,8 @@ typedef struct scsi_cd {
unsigned readcd_known:1; /* drive supports READ_CD (0xbe) */
unsigned readcd_cdda:1; /* reading audio data using READ_CD */
unsigned media_present:1; /* media is present */
+ unsigned ignore_get_event:1; /* get_event is unreliable, use TUR */
+ int tur_mismatch; /* nr of get_event TUR mismatches */
struct cdrom_device_info cdi;
/* We hold gendisk and scsi_device references on probe and use
* the refs on this kref to decide when to release them */
^ permalink raw reply related
* Re: pci hotplug problem
From: shivprashant @ 2011-06-14 5:32 UTC (permalink / raw)
To: linux-hotplug
Hi Kenji,
I too presumed that. The board (based on MPC8315erdb from Freescale) has
two PCIe controllers to which two slots are connected. The controllers
are compatible with PCI Express Base Specification Revision 1.0a and the
PCI Interface is compatible with PCI Local Bus Specification Rev. 2.3.
The driver makes use of PCI Hotplug controller core to
register/deregister hotplug slots.
Did I answer your question?
Regards,
Shivaprashanth
On Tuesday 14 June 2011 07:42 AM, Kenji Kaneshige wrote:
> Shivaprashanth,
>
> Sorry for my delayed responding.
> (I'm on vacation this week)
>
> I could not find any hotplug capable slot defined by PCIe spec in your
> lspci output. It should be the reason why pciehp detects no slot on
> your system. What kind of hotplug controller does your hotplug driver
> handle?
>
> Regards,
> Kenji Kaneshige
>
>
> (2011/06/09 18:30), shivprashant wrote:
>> below is the dmesg log after loading pciehp.ko with debug enabled
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>> -sh-2.05b# insmod /pciehp.ko pciehp_debug=1
>> pciehp: PCI Express Hot Plug Controller Driver version: 0.4
>> -sh-2.05b# dmesg
>> Using MPC831x RDB machine description
>> Linux version 2.6.36.1 (root@shiva-desktop) (gcc version 4.1.2) #5 Thu
>> Jun 9 14:40:17 IST 2011
>> Found legacy serial port 0 for /immr@e0000000/serial@4500
>> memà004500, taddrà004500, irq=0, clk\x133333333, speed=0
>> Found legacy serial port 1 for /immr@e0000000/serial@4600
>> memà004600, taddrà004600, irq=0, clk\x133333333, speed=0
>> Found FSL PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->0
>> PCI host bridge /pci@e0008500 (primary) ranges:
>> MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000090000000
>> MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000 Prefetch
>> IO 0x00000000e0300000..0x00000000e03fffff -> 0x0000000000000000
>> Found FSL PCI host bridge at 0x00000000e0009000. Firmware bus number: 0->255
>> PCI host bridge /pcie@e0009000 ranges:
>> MEM 0x0000000040000000..0x000000004fffffff -> 0x0000000040000000
>> IO 0x0000000051000000..0x00000000517fffff -> 0x0000000000000000
>> Found FSL PCI host bridge at 0x00000000e000a000. Firmware bus number: 0->255
>> PCI host bridge /pcie@e000a000 ranges:
>> MEM 0x0000000060000000..0x000000006fffffff -> 0x0000000060000000
>> IO 0x0000000071000000..0x00000000717fffff -> 0x0000000000000000
>> Top of RAM: 0x10000000, Total RAM: 0x10000000
>> Memory hole size: 0MB
>> Zone PFN ranges:
>> DMA 0x00000000 -> 0x00010000
>> Normal empty
>> Movable zone start PFN for each node
>> early_node_map[1] active PFN ranges
>> 0: 0x00000000 -> 0x00010000
>> On node 0 totalpages: 65536
>> free_area_init_node: node 0, pgdat c03fde3c, node_mem_map c0441000
>> DMA zone: 512 pages used for memmap
>> DMA zone: 0 pages reserved
>> DMA zone: 65024 pages, LIFO batch:15
>> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
>> Kernel command line: console=ttyS0,115200 root=/dev/nfs rw
>> nfsroot\x172.16.9.85:/home/shiva/Projects/AJA/pciehp-v2/aja-ltib/ro
>> otfs ip\x172.16.9.100:172.16.9.85:172.16.9.1:255.255.255.0::eth0:off
>> PID hash table entries: 1024 (order: 0, 4096 bytes)
>> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
>> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
>> Memory: 255496k/262144k available (3972k kernel code, 6648k reserved,
>> 144k data, 204k bss, 176k init)
>> Kernel virtual memory layout:
>> * 0xfffdf000..0xfffff000 : fixmap
>> * 0xfcef8000..0xfe000000 : early ioremap
>> * 0xd1000000..0xfcef8000 : vmalloc& ioremap
>> Hierarchical RCU implementation.
>> RCU-based detection of stalled CPUs is disabled.
>> Verbose stalled-CPUs detection is disabled.
>> NR_IRQS:512 nr_irqs:512
>> IPIC (128 IRQ sources) at d1000700
>> time_init: decrementer frequency = 33.333334 MHz
>> time_init: processor frequency = 400.000008 MHz
>> clocksource: timebase mult[77ffffd] shift[22] registered
>> clockevent: decrementer mult[888888b] shift[32] cpu[0]
>> Console: colour dummy device 80x25
>> pid_max: default: 32768 minimum: 301
>> Mount-cache hash table entries: 512
>> NET: Registered protocol family 16
>> alloc irq_desc for 38 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 38 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 38
>> PCI: Probing PCI hardware
>> pci 0000:00:00.0: reg 10: [mem 0x00000000-0x000fffff]
>> pci 0000:00:00.0: reg 18: [mem 0x00000000-0x0fffffff 64bit pref]
>> pci 0000:00:00.0: supports D1 D2
>> pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot
>> pci 0000:00:00.0: PME# disabled
>> pci 0000:00:10.0: reg 10: [mem 0x90000000-0x900007ff]
>> pci 0000:00:10.0: reg 14: [mem 0x90004000-0x90007fff]
>> pci 0000:00:10.0: supports D1 D2
>> pci 0000:00:10.0: PME# supported from D0 D1 D2 D3hot
>> pci 0000:00:10.0: PME# disabled
>> alloc irq_desc for 48 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 48 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 48
>> pci_bus 0000:00: resource 0 [io 0x0000-0xfffff]
>> pci_bus 0000:00: resource 1 [mem 0x90000000-0x9fffffff]
>> pci_bus 0000:00: resource 2 [mem 0x80000000-0x8fffffff pref]
>> pci_bus 0001:01: resource 0 [io 0xff7fe000-0xffffdfff]
>> pci_bus 0001:01: resource 1 [mem 0x40000000-0x4fffffff]
>> pci_bus 0002:02: resource 0 [io 0xfeffc000-0xff7fbfff]
>> pci_bus 0002:02: resource 1 [mem 0x60000000-0x6fffffff]
>> Registering ipic with sysfs...
>> bio: create slab<bio-0> at 0
>> vgaarb: loaded
>> SCSI subsystem initialized
>> libata version 3.00 loaded.
>> Freescale Elo / Elo Plus DMA driver
>> Switching to clocksource timebase
>> NET: Registered protocol family 2
>> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
>> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
>> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
>> TCP: Hash tables configured (established 8192 bind 8192)
>> TCP reno registered
>> UDP hash table entries: 256 (order: 0, 4096 bytes)
>> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
>> NET: Registered protocol family 1
>> RPC: Registered udp transport module.
>> RPC: Registered tcp transport module.
>> RPC: Registered tcp NFSv4.1 backchannel transport module.
>> PCI: CLS 32 bytes, default 32
>> alloc irq_desc for 16 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 9 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 16
>> alloc irq_desc for 17 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 10 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 17
>> alloc irq_desc for 77 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 77 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 77
>> alloc irq_desc for 18 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 16 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 18
>> alloc irq_desc for 71 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 71 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 71
>> of:fsl-elo-dma e00082a8.dma: #0 (fsl,elo-dma-channel), irq 71
>> of:fsl-elo-dma e00082a8.dma: #1 (fsl,elo-dma-channel), irq 71
>> of:fsl-elo-dma e00082a8.dma: #2 (fsl,elo-dma-channel), irq 71
>> of:fsl-elo-dma e00082a8.dma: #3 (fsl,elo-dma-channel), irq 71
>> alloc irq_desc for 32 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 32 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 32
>> alloc irq_desc for 33 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 33 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 33
>> alloc irq_desc for 34 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 34 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 34
>> alloc irq_desc for 44 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 44 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 44
>> alloc irq_desc for 45 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 45 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 45
>> alloc irq_desc for 67 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 67 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 67
>> alloc irq_desc for 19 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 4 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 19
>> alloc irq_desc for 81 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 81 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 81
>> alloc irq_desc for 82 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 82 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 82
>> alloc irq_desc for 86 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 86 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 86
>> alloc irq_desc for 87 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 87 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 87
>> alloc irq_desc for 88 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 88 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 88
>> alloc irq_desc for 89 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 89 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 89
>> Setting up Freescale MSI support
>> alloc irq_desc for 80 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 80 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 80
>> alloc irq_desc for 90 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 90 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 90
>> alloc irq_desc for 78 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 78 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 78
>> alloc irq_desc for 84 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 84 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 84
>> alloc irq_desc for 72 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 72 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 72
>> alloc irq_desc for 91 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 91 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 91
>> alloc irq_desc for 79 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 79 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 79
>> alloc irq_desc for 85 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 85 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 85
>> alloc irq_desc for 73 on node 0
>> alloc kstat_irqs on node 0
>> irq: irq 73 on host /immr@e0000000/interrupt-controller@700 mapped to
>> virtual irq 73
>> msgmni has been set to 499
>> io scheduler noop registered
>> io scheduler deadline registered
>> io scheduler cfq registered (default)
>> pci_hotplug: PCI Hot Plug PCI Core version: 0.5
>> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
>> console [ttyS0] enabled
>> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
>> e0004500.serial: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550
>> e0004600.serial: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550
>> brd: module loaded
>> loop: module loaded
>> f8000000.flash: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer
>> ID 0x000001 Chip ID 0x002301
>> f8000000.flash: Found 1 x16 devices at 0x4000000 in 16-bit bank
>> Amd/Fujitsu Extended Query Table at 0x0040
>> Amd/Fujitsu Extended Query version 1.3.
>> number of CFI chips: 2
>> RedBoot partition parsing not available
>> Creating 8 MTD partitions on "f8000000.flash":
>> 0x000000000000-0x000002000000 : "AppA"
>> 0x000002000000-0x000004000000 : "AppB"
>> 0x000004000000-0x000006000000 : "SafeBoot"
>> 0x000007ea0000-0x000007ec0000 : "ConfigB"
>> 0x000007f60000-0x000007f80000 : "UserRegsA"
>> 0x000007f80000-0x000007fa0000 : "UserRegsB"
>> 0x000007fa0000-0x000007fc0000 : "ConfigA"
>> 0x000006400000-0x000006420000 : "UBootShared"
>> of:mpc8xxx_spi e0007000.spi: at 0xd103c000 (irq = 18), CPU mode
>> Fixed MDIO Bus: probed
>> eth0: Gianfar Ethernet Controller Version 1.2, 00:0c:17:88:02:35
>> eth0: Running with NAPI enabled
>> eth0: RX BD ring size for Q[0]: 256
>> eth0: TX BD ring size for Q[0]: 256
>> Freescale PowerQUICC MII Bus: probed
>> i2c /dev entries driver
>> of:mpc-i2c e0003000.i2c: timeout 1000000 us
>> rtc-ds1307 0-0068: rtc core: registered ds1339 as rtc0
>> TCP cubic registered
>> NET: Registered protocol family 17
>> rtc-ds1307 0-0068: setting system clock to 2011-06-09 02:04:50 UTC
>> (1307585090)
>> IP-Config: Complete:
>> device=eth0, addr\x172.16.9.100, mask%5.255.255.0, gw\x172.16.9.1,
>> host\x172.16.9.100, domain=, nis-domain=(none),
>> bootserver\x172.16.9.85, rootserver\x172.16.9.85, rootpath>> Looking up port of RPC 100003/2 on 172.16.9.85
>> PHY: mdio@e0024520:01 - Link is Up - 100/Full
>> Looking up port of RPC 100005/1 on 172.16.9.85
>> VFS: Mounted root (nfs filesystem) on device 0:12.
>> Freeing unused kernel memory: 176k init
>> pciehp: pcie_port_service_register = 0
>> pciehp: PCI Express Hot Plug Controller Driver version: 0.4
>> -sh-2.05b#
>> -sh-2.05b#
>> -sh-2.05b# lspci -vv
>> 00:00.0 Power PC: Freescale Semiconductor Inc Unknown device 00b5 (rev 12)
>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR+ FastB2B-
>> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSELúst>TAbort-<TAbort-
>> <MAbort+>SERR-<PERR-
>> Latency: 128, Cache Line Size: 32 bytes
>> Interrupt: pin A routed to IRQ 0
>> Region 2: Memory at<unassigned> (64-bit, prefetchable)
>> Region 4: Memory at<unassigned> (64-bit, non-prefetchable)
>> Capabilities: [48] #06 [0000]
>> Capabilities: [80] Power Management version 3
>> Flags: PMEClk+ DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>>
>> 00:10.0 FireWire (IEEE 1394): Texas Instruments TSB82AA2 IEEE-1394b Link
>> Layer Controller (rev 02) (prog-if 10 [OHCI])
>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B-
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium>TAbort-
>> <TAbort-<MAbort->SERR-<PERR-
>> Latency: 128 (500ns min, 1000ns max), Cache Line Size: 32 bytes
>> Interrupt: pin A routed to IRQ 48
>> Region 0: Memory at 90000000 (32-bit, non-prefetchable) [size=2K]
>> Region 1: Memory at 90004000 (32-bit, non-prefetchable) [size\x16K]
>> Capabilities: [44] Power Management version 2
>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
>> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>> On Thursday 09 June 2011 02:01 PM, Kenji Kaneshige wrote:
>>> (2011/06/09 16:54), shivprashant wrote:
>>>> i built pciehp statically. the driver gets loaded but probe is not
>>>> called. do i need to modify anything in pciehp driver to make it work
>>>> with my platform?
>>>>
>>> I have no idea so far.
>>>
>>> Can you send me the following information?
>>>
>>> - dmesg output after loading pciehp with pciehp_debug module option
>>> (if you built pciehp as builtin driver, please add pciehp.pciehp_debug
>>> to kernel parameter and boot)
>>>
>>> - "lspci -vv" output (as root user).
>>>
>>> Regards,
>>> Kenji Kaneshige
>>>
>>>
>>>
>>>> On Thursday 09 June 2011 01:09 PM, Kenji Kaneshige wrote:
>>>>> Why not use pciehp?
>>>>>
>>>>> Thanks,
>>>>> Kenji Kaneshige
>>>>>
>>>>>
>>>>> (2011/06/09 14:31), shivprashant wrote:
>>>>>> hi,
>>>>>> i am writing pci express hotplug driver for mpc8315erdb(powerpc). the driver uses PCI hotplug subsystem not pcie port bus driver. i am able to do insertion and removal of pci express cards and confirm using 'lspci' command. driver is working with SATA and PATA memory cards with some minor modifications in the kernel. the problem i am facing now is when i try to repeatedly insert and remove the kernel is crashing, although non-fatal. normal insertion/removal works fine but repeated insertion/removal fails. pls guide me where am i wrong or what changes i should make to recover from pci errors.
>>>>>>
>>>>>> Following is the crash log when repeatedly inserting and removing the PATA cards (i am using delkin 32GB cards),
>>>>>> scsi20 : pata_jmicron
>>>>>> scsi21 : pata_jmicron
>>>>>> ata21: PATA max UDMA/100 cmd 0xff7fa010 ctl 0xff7fa020 bmdma 0xff7fa000 irq 21
>>>>>> ata22: PATA max UDMA/100 cmd 0xff7fa018 ctl 0xff7fa024 bmdma 0xff7fa008 irq 21
>>>>>> PCIE Card Removed from Slot 0
>>>>>> Oops: Machine check, sig: 7 [#1]
>>>>>> MPC831x RDB
>>>>>> last sysfs file: /sys/devices/pci0002:02/0002:02:00.0/0002:03:00.0/class
>>>>>> Modules linked in:
>>>>>> NIP: c00124c4 LR: c00124b0 CTR: c0017998
>>>>>> REGS: cfad3cb0 TRAP: 0200 Not tainted (2.6.36.1)
>>>>>> MSR: 00049030<EE,ME,IR,DR> CR: 22204084 XER: 20000000
>>>>>> TASK = cfa9c030[1282] 'scsi_eh_20' THREAD: cfad2000
>>>>>> GPR00: 00000000 cfad3d60 cfa9c030 00000000 cfad3d08 00e00000 a91e4fb9 00000001
>>>>>> GPR08: c03fd688 fdef7000 fd6f7000 c042a0e0 00005a07 00020d78 c02fbd0c ffffffff
>>>>>> GPR16: 00000000 00000000 00000000 00000004 c01ff498 00000001 cfac94c8 cfac8000
>>>>>> GPR24: c01fa87c 00000003 ffff2a2d cfac801c 00000001 00000000 cfac9430 fd6f8012
>>>>>> NIP [c00124c4] ioread8+0x2c/0x328
>>>>>> LR [c00124b0] ioread8+0x18/0x328
>>>>>> Call Trace:
>>>>>> [cfad3d60] [c002bccc] msleep+0x1c/0x34 (unreliable)
>>>>>> [cfad3d70] [c01fa77c] ata_sff_wait_after_reset+0x6c/0x16c
>>>>>> [cfad3da0] [c01fa934] ata_sff_softreset+0xb8/0x204
>>>>>> [cfad3de0] [c01f2604] ata_do_reset+0xa0/0xb4
>>>>>> [cfad3e00] [c01f33ac] ata_eh_reset+0x3e4/0xcf4
>>>>>> [cfad3e80] [c01f59e8] ata_eh_recover+0x284/0x10e0
>>>>>> [cfad3f00] [c01f6a0c] ata_do_eh+0x4c/0xb0
>>>>>> [cfad3f20] [c01f926c] ata_sff_error_handler+0x110/0x140
>>>>>> [cfad3f40] [c01f7680] ata_scsi_error+0x2ec/0x4e0
>>>>>> [cfad3f70] [c01d2664] scsi_error_handler+0xc4/0x39c
>>>>>> [cfad3fb0] [c0039d4c] kthread+0x7c/0x80
>>>>>> [cfad3ff0] [c000f200] kernel_thread+0x4c/0x68
>>>>>> Instruction dump:
>>>>>> 4e800020 9421fff0 7c0802a6 93e1000c 7c7f1b78 90010014 481835f5 2f830000
>>>>>> 38600000 419e0018 7c0004ac 881f0000<0c000000> 4c00012c 5403063e 80010014
>>>>>> ---[ end trace fb9766f858e66ef2 ]---
>>>>>>
>>>>>>
>>>>>>
>>
>
--
With Regards,
Shivaprashanth H
^ permalink raw reply
* Re: udev queue error
From: Kay Sievers @ 2011-06-13 19:02 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTim9kJEroUeqpqNoE-tCRvxa5=nghw@mail.gmail.com>
On Sun, Jun 12, 2011 at 14:28, Tejun Heo <htejun@gmail.com> wrote:
> I've been playing with the device a bit and this thing really is an
> abomination and reports new media whenever asked. :(
Yeah, it looks pretty broken.
> I've been trying to come up with a way to work around the problem.
> The only thing we can do from kernel is somehow suppressing event
> generation on open (or mark it to be ignored) - be it timing or opener
> based; however, there's no way to acheive that in a race-free way.
Right, and both are not easy to manage. An open flag is hard to decide
when to use it, especially for tools shared by udev and possibly other
callers. The timer based solution is kinda weird inside the kernel.
And unfortunately, we still have userspace polling, which currently
triggers this behaviour once a second.
> * Kernel must check whether media is changed upon open.
Sure.
We follow GET_EVENT_STATUS_NOTIFICATION now. Can't we always force TUR
when we open() the device from userland? That's what we did in the
past, didn't we? The in-kernel polling would still not need to do
that, and the periodic usespace polling is about to die pretty soon.
> * If at least one MEDIA_CHANGE event is not generated after device
> indicated the event, we risk losing events. ie. Media change can
> race against open() and userland may end up with stale information.
> The race window is quite short compared to usual tray actions tho.
That would be pretty hard to debug, I guess. :)
> I think it would be better to avoid penalizing sane devices and let
> timer-based throttling take care of crazy ones. I don't know how udev
> handles it from userland but does it need to keep track of all the
> separate events? Can't it just track the pending states (ie. one bit
> for each event) and throttle propagation accordingly?
It's just a queue of events. Every event currently generates 3 new
ones in the kernel from the open() in the event event handler. We
would need to ratelimit that and discard all already queued events
when we decide that it's a loop.
We can not generally coalesce events in udev, as they might carry
different properties added from subsystems we need to read.
This loop would be triggered from new once a second with the current tools.
> Also, another thing is that as userland is now in charge of tray
> locking, maybe it's safe to ignore MEDIA_CHANGE while the device is
> known to be locked from userland? But, then again, I would be
> surprised if there isn't a device which is crazy enough to avoid such
> safe guard and still trigger weird behavior. :(
Guess we need to make it work with current stuff too, and not rely on
the door lock.
Kay
^ permalink raw reply
* Re: udev queue error
From: Tejun Heo @ 2011-06-12 12:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTim9kJEroUeqpqNoE-tCRvxa5=nghw@mail.gmail.com>
Hello, Kay.
On Thu, Jun 09, 2011 at 02:36:54PM +0200, Kay Sievers wrote:
> On Thu, Jun 9, 2011 at 13:54, Tejun Heo <htejun@gmail.com> wrote:
> > Maybe we can tag events which were generated during open(2) with the
> > pid of the opener so that udev can reliably filter them? I think it
> > would be nice if we can somehow make it uni-directional (ie. no extra
> > information from userland to kernel during open
>
> It's a cool idea.
>
> But I fear in reality it gets messy pretty fast. We would need to
> track and remember all pids from tools executed by udev rules.
>
> With the fully async/queued nature of these events, we might not even
> have read the events from the kernel after the event and the called
> tools have long finished their work.
>
> We could use the session id or process group, but that sounds like
> asking for trouble.
I've been playing with the device a bit and this thing really is an
abomination and reports new media whenever asked. :(
I've been trying to come up with a way to work around the problem.
The only thing we can do from kernel is somehow suppressing event
generation on open (or mark it to be ignored) - be it timing or opener
based; however, there's no way to acheive that in a race-free way.
* Kernel must check whether media is changed upon open.
* If at least one MEDIA_CHANGE event is not generated after device
indicated the event, we risk losing events. ie. Media change can
race against open() and userland may end up with stale information.
The race window is quite short compared to usual tray actions tho.
I think it would be better to avoid penalizing sane devices and let
timer-based throttling take care of crazy ones. I don't know how udev
handles it from userland but does it need to keep track of all the
separate events? Can't it just track the pending states (ie. one bit
for each event) and throttle propagation accordingly?
Also, another thing is that as userland is now in charge of tray
locking, maybe it's safe to ignore MEDIA_CHANGE while the device is
known to be locked from userland? But, then again, I would be
surprised if there isn't a device which is crazy enough to avoid such
safe guard and still trigger weird behavior. :(
Thanks.
--
tejun
^ permalink raw reply
* Re: support for Partition UUIDs in 60-persistent-storage.rules
From: KESHAV P.R. @ 2011-06-11 12:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTi=GiQ4VNBeCw=q=WFxKVyegkT6xVw@mail.gmail.com>
On Sat, Jun 11, 2011 at 17:09, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Tue, Jun 7, 2011 at 15:34, KESHAV P.R. <skodabenz@gmail.com> wrote:
>> I thought of using GPT Partition Unique GUIDs to reference
>> partitions instead of FS UUIDs since some filesystems do not support
>> proper UUIDs. Also haing a FS independent way of uniquely referencing
>> partitions has few advantages.
>
> Committed as by-partuuid/by-partlabel to closer match the kernels
> root=PARTUUID= key, and mount's upcoming PARTUUID= support.
>
> Thanks,
> Kay
>
Thank you. I also asked util-linux guys about PARTUUID support in
fstab and mostly it will be available in util-linux ver 2.21 .
Regards.
Keshav
^ permalink raw reply
* Re: support for Partition UUIDs in 60-persistent-storage.rules
From: Kay Sievers @ 2011-06-11 11:39 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTi=GiQ4VNBeCw=q=WFxKVyegkT6xVw@mail.gmail.com>
On Tue, Jun 7, 2011 at 15:34, KESHAV P.R. <skodabenz@gmail.com> wrote:
> I thought of using GPT Partition Unique GUIDs to reference
> partitions instead of FS UUIDs since some filesystems do not support
> proper UUIDs. Also haing a FS independent way of uniquely referencing
> partitions has few advantages.
Committed as by-partuuid/by-partlabel to closer match the kernels
root=PARTUUID= key, and mount's upcoming PARTUUID= support.
Thanks,
Kay
^ permalink raw reply
* Re: [PATCH] Support more MSI notebook by using asterisk on dmi
From: Martin Pitt @ 2011-06-10 8:52 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1307688312-6356-1-git-send-email-jlee@novell.com>
[-- Attachment #1: Type: text/plain, Size: 471 bytes --]
Hello Chun-Yi,
Lee, Chun-Yi [2011-06-10 14:45 +0800]:
> MSI machines have some different vendor name, and the refix on those vendor
> name are "MICRO-STAR" or "Micro-Star". So, merge the original two rules to
> one, and use asterisk on dmi vendor name for support more MSI machines.
Thanks! Applied to git master.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] Support more MSI notebook by using asterisk on dmi vendor name
From: Lee, Chun-Yi @ 2011-06-10 6:45 UTC (permalink / raw)
To: linux-hotplug
MSI machines have some different vendor name, and the refix on those vendor
name are "MICRO-STAR" or "Micro-Star". So, merge the original two rules to
one, and use asterisk on dmi vendor name for support more MSI machines.
Tested on MSI U270 netbook.
Cc: Martin Pitt <martin.pitt@ubuntu.com>
Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
---
| 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
--git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index ee12a87..fcabe85 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -121,8 +121,7 @@ ENV{DMI_VENDOR}="LG*", ATTR{[dmi/id]product_name}="*X110*", RUN+="keymap $name
ENV{DMI_VENDOR}="MEDION*", ATTR{[dmi/id]product_name}="*FID2060*", RUN+="keymap $name medion-fid2060"
ENV{DMI_VENDOR}="MEDIONNB", ATTR{[dmi/id]product_name}="A555*", RUN+="keymap $name medionnb-a555"
-ENV{DMI_VENDOR}="MICRO-STAR*", RUN+="keymap $name micro-star"
-ENV{DMI_VENDOR}="Micro-Star International", RUN+="keymap $name micro-star"
+ENV{DMI_VENDOR}="MICRO-STAR*|Micro-Star*", RUN+="keymap $name micro-star"
# some MSI models generate ACPI/input events on the LNXVIDEO input devices,
# plus some extra synthesized ones on atkbd as an echo of actually changing the
--
1.6.0.2
^ permalink raw reply related
* Re: udev queue error
From: Kay Sievers @ 2011-06-09 12:36 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTim9kJEroUeqpqNoE-tCRvxa5=nghw@mail.gmail.com>
On Thu, Jun 9, 2011 at 13:54, Tejun Heo <htejun@gmail.com> wrote:
> On Wed, Jun 08, 2011 at 01:55:01PM +0200, Kay Sievers wrote:
>> Maybe we can find a clean way to disable the event generation during
>> the time udev runs the event handler? We do a similar thing with
>> inotify watches too, so that udev does not generate events it has
>> caused itself during the event run.
>
> Maybe we can tag events which were generated during open(2) with the
> pid of the opener so that udev can reliably filter them? Â I think it
> would be nice if we can somehow make it uni-directional (ie. no extra
> information from userland to kernel during open
It's a cool idea.
But I fear in reality it gets messy pretty fast. We would need to
track and remember all pids from tools executed by udev rules.
With the fully async/queued nature of these events, we might not even
have read the events from the kernel after the event and the called
tools have long finished their work.
We could use the session id or process group, but that sounds like
asking for trouble.
Kay
^ permalink raw reply
* Re: udev queue error
From: Tejun Heo @ 2011-06-09 11:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTim9kJEroUeqpqNoE-tCRvxa5=nghw@mail.gmail.com>
Hello,
On Wed, Jun 08, 2011 at 01:55:01PM +0200, Kay Sievers wrote:
> Maybe we can find a clean way to disable the event generation during
> the time udev runs the event handler? We do a similar thing with
> inotify watches too, so that udev does not generate events it has
> caused itself during the event run.
Maybe we can tag events which were generated during open(2) with the
pid of the opener so that udev can reliably filter them? I think it
would be nice if we can somehow make it uni-directional (ie. no extra
information from userland to kernel during open).
Thanks.
--
tejun
^ permalink raw reply
* Re: pci express hotplug problem
From: Greg KH @ 2011-06-08 15:15 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4DEF3124.9010100@globaledgesoft.com>
On Wed, Jun 08, 2011 at 01:51:56PM +0530, shivprashant wrote:
> hi,
> i am writing pci express hotplug driver for mpc8315erdb(powerpc).
> the driver uses PCI hotplug subsystem not pcie port bus driver. i am
> able to do insertion and removal of pci express cards and confirm
> using 'lspci' command. driver is working with SATA and PATA memory
> cards with some minor modifications in the kernel. the problem i am
> facing now is when i try to repeatedly insert and remove the kernel
> is crashing, although non-fatal. normal insertion/removal works fine
> but repeated insertion/removal fails. pls guide me where am i wrong
> or what changes i should make to recover from pci errors.
You should post this on the linux-pci@vger.kernel.org list, along with
the errors and crashes you are seeing, and your code that you have
written so that people can help you out with it.
good luck,
greg k-h
^ permalink raw reply
* Re: udev queue error
From: Kay Sievers @ 2011-06-08 11:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTim9kJEroUeqpqNoE-tCRvxa5=nghw@mail.gmail.com>
On Wed, Jun 1, 2011 at 06:42, Tejun Heo <htejun@gmail.com> wrote:
> I _think_ what we really need is a timer based throttling. e.g. one
> token is generated every, say, three seconds and can accumulate upto 5
> and each media changed event checking consumes a token and should wait
> if there's no token left. Dunno how difficult it owuld be to
> implement this tho.
The problem is that currently every udev event run causes three new
kernel events. The whole thing is constantly triggered by the (still
present) userspace polling once a second. Udev will need to forcefully
drop events from the event queue every second to break this loop --
means constant throttling without any real idle time. Sure, such
ratelimit we should probably have, but it does not really solve our
problem properly, I guess. constantly dropping events from udev that
the kernel send us shouldn't be the expected behavior.
Maybe we can find a clean way to disable the event generation during
the time udev runs the event handler? We do a similar thing with
inotify watches too, so that udev does not generate events it has
caused itself during the event run.
Kay
^ permalink raw reply
* pci express hotplug problem
From: shivprashant @ 2011-06-08 8:33 UTC (permalink / raw)
To: linux-hotplug
hi,
i am writing pci express hotplug driver for mpc8315erdb(powerpc). the
driver uses PCI hotplug subsystem not pcie port bus driver. i am able to
do insertion and removal of pci express cards and confirm using 'lspci'
command. driver is working with SATA and PATA memory cards with some
minor modifications in the kernel. the problem i am facing now is when i
try to repeatedly insert and remove the kernel is crashing, although
non-fatal. normal insertion/removal works fine but repeated
insertion/removal fails. pls guide me where am i wrong or what changes i
should make to recover from pci errors.
--
With Regards,
Shivaprashanth H
^ permalink raw reply
* Re: serial port reassignment
From: Kay Sievers @ 2011-06-08 7:42 UTC (permalink / raw)
To: linux-hotplug
On Wed, Jun 8, 2011 at 07:02, Demetrick Nichols <dnichols@tivo.com> wrote:
> I’m trying to figure out how to prevent  serial port  reassignment when using a 8 port  usb to serial hub. Currently the USB hub is assigned to dev usb0 - usb6 and the second hub is usb7-usb15. When the PC reboots, the usb to serial hubs get switched sometimes. The one that was usb0-usb6 is now usb7-usb15. Does anyone know how to make this static so the USB devices don’t move around?
You can't control that.
Newer systems have: /dev/serial/:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h¼4c751802147f1ff21bf52a57a2976754949453
Kay
^ permalink raw reply
* serial port reassignment
From: Demetrick Nichols @ 2011-06-08 5:02 UTC (permalink / raw)
To: linux-hotplug
Hello ,
I’m trying to figure out how to prevent serial port reassignment when using a 8 port usb to serial hub. Currently the USB hub is assigned to dev usb0 - usb6 and the second hub is usb7-usb15. When the PC reboots, the usb to serial hubs get switched sometimes. The one that was usb0-usb6 is now usb7-usb15. Does anyone know how to make this static so the USB devices don’t move around?
System info
Dell Optiplex 780 running Centos 5
Best Regards, Demetrick
This email and any attachments may contain confidential and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments) by others is prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete this email and any attachments. No employee or agent of TiVo Inc. is authorized to conclude any binding agreement on behalf of TiVo Inc. by email. Binding agreements with TiVo Inc. may only be made by a signed written agreement.
^ permalink raw reply
* support for Partition UUIDs in 60-persistent-storage.rules
From: KESHAV P.R. @ 2011-06-07 13:46 UTC (permalink / raw)
To: linux-hotplug
Hi,
I thought of using GPT Partition Unique GUIDs to reference
partitions instead of FS UUIDs since some filesystems do not support
proper UUIDs. Also haing a FS independent way of uniquely referencing
partitions has few advantages. This support requires just adding two
lines to http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob_plain;f=rules/rules.d/60-persistent-storage.rules;hb=HEAD
. These are supported by util-linux's blkid as of version 2.19 .
# by-part-label/by-part-uuid links (partition metadata)
ENV{ID_PART_ENTRY_SCHEME}="gpt", ENV{ID_PART_ENTRY_UUID}="?*",
SYMLINK+="disk/by-part-uuid/$env{ID_PART_ENTRY_UUID}"
ENV{ID_PART_ENTRY_SCHEME}="gpt", ENV{ID_PART_ENTRY_NAME}="?*",
SYMLINK+="disk/by-part-label/$env{ID_PART_ENTRY_NAME}"
Please add these lines to the file. Thanks in advance.
Regards.
Keshav
^ 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