Problem with custom udev rule.

prhunt · October 11, 2011, 3:18pm

Hi all.

I am currently using opensuse 11.4 64 bit.

In order to run jack for various audio applications, I require non-root read and write access to /dev/hpet.

In my previous opensuse 11.3 64 bit install, I had a custom udev rule to automatically set permissions for the hpet device.

I created a file /etc/udev/rules.d/20-udev-audio.rules containing the rule:

KERNEL=="hpet", GROUP="audio", MODE="0660"

which changed the group for /dev/hpet to “audio”, and gave “audio” group read and write permissions.

Now, using the same rule in opensuse 11.4, the permissions for /dev/hpet do not change.

As a kludge, I can change the permission from the CLI using:

# chmod 666 /dev/hpet

but I would really like to know why the udev rule is failing. Any ideas?

Paul

hcvv · October 11, 2011, 5:51pm

I am not quite sure if it helps you, nor did I ever handle this, but from reading other threads: shouldn’t you create a separate custom rules file instead of changing the standnard ones (which will possibly be overwritten with a package update)?

Something like 50-customs.rules or maybe a high number?

please_try_again · October 11, 2011, 7:14pm

That would be the first thing I would try too. Try a higher number, like 99.

hcvv · October 11, 2011, 7:26pm

I am glad I am corrected here.

I have *99-iwlwifi-led.rules *in my system, thus to be sure you might even want to use sometyhing like *99-zzzzzzzzzzzzzz.rules *

prhunt · October 11, 2011, 11:56pm

Thanks everyone.

I tried renaming the custom rule file to start with 99. Unfortunately, this did not succeed in changing the device permissions.

@hcvv - The rule I made is a custom rule, placed in /etc/udev/rules.d which is the appropriate location for custom rules. The default rules are located in /lib/udev/rules.d and the udev chapter in the opensuse reference manual states that the custom rules take precedence over the default rules.

My rule did work in 11.3 which makes me suspect either a change in the way the timer devices are set up in 11.4, or perhaps a udev bug.

Unless anyone has further ideas, I’ll just set up a work-around.

Thanks

Paul

prhunt · October 12, 2011, 12:27am

Ok, here is my work-around.

Editted /etc/init.d/boot.local and added the following:

chown root:audio /dev/hpet
chmod 660 /dev/hpet

Now /dev/hpet is accessible after every boot. Jack is happy.

I’m still a little annoyed that udev did not work, though…

Paul

deano_ferrari · October 12, 2011, 1:20am

Silly question Paul, but did you reboot, or restart udev after adding that rule?

udevadm control --reload

prhunt · October 12, 2011, 6:00am

Yes, by reboot.

Maybe some 11.4 x86_64 user who has a functional /dev/hpet could try the custom rule and report back? Post before and after “ls -l /dev/hpet” or something.

As mentioned, I have a satisfactory work-around, but it isn’t quite as satisfying as solving the basic problem!

Paul

deano_ferrari · October 12, 2011, 6:55am

Maybe some 11.4 x86_64 user who has a functional /dev/hpet could try the custom rule and report back? Post before and after “ls -l /dev/hpet” or something.

I had to bring myself up to speet with what a HPET was before proceeding to help.

I discovered my x86_64 laptop (with 11.4) has /dev/hpet present, and so could assist further

Anway, creating /etc/udev/rules.d/90-udev-audio.rules with

KERNEL=="hpet", GROUP="audio", MODE="0660"

then rebooting worked for me

dean@linux-akl:~> ls -l /dev/hpet
crw-rw---- 1 root audio 10, 228 Oct 12 17:43 /dev/hpet

ken_yap · October 12, 2011, 6:59am

But you know, you are not limited to poking udevd when you have changed the config file. You can simulate an event and see what it does.

prhunt · October 12, 2011, 11:13am

@deano_ferrari

deano_ferrari:

Anway, creating /etc/udev/rules.d/90-udev-audio.rules with
KERNEL=="hpet", GROUP="audio", MODE="0660"
then rebooting worked for me
dean@linux-akl:~> ls -l /dev/hpet
crw-rw---- 1 root audio 10, 228 Oct 12 17:43 /dev/hpet

<BooHoo!> My rule works, just not on my computer. I tried deleting the rule, and re-creating it. Still does not work

I am certain that my hpet is working:

$ dmesg | grep -i hpet
    0.000000] ACPI: HPET 00000000cee4e6c0 00038 (v01 ALASKA    A M I 01072009 AMI. 00000004)
    0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
    0.000000] hpet clockevent registered
    0.930034] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
    0.930038] hpet0: 8 comparators, 64-bit 14.318180 MHz counter
    1.608767] rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs

@ken_yap:

But you know, you are not limited to poking udevd when you have changed the config file. You can simulate an event and see what it does.

Could you elaborate in the context of /dev/hpet? Not sure what event one would simulate?

Paul

ken_yap · October 12, 2011, 11:19am

Writing udev rules

prhunt · October 12, 2011, 3:35pm

Thanks for the info Ken. I looked at some of the info that udevadm gave me, but I am no wiser.

I will just use my work-around (hooking into /etc/init.d/boot.local), since I don’t really want to spend more time chasing the udev issue.

Paul

lwfinger · October 12, 2011, 5:17pm

On 10/12/2011 08:36 AM, prhunt wrote:
>
> Thanks for the info Ken. I looked at some of the info that udevadm gave
> me, but I am no wiser.
>
> I will just use my work-around (hooking into /etc/init.d/boot.local),
> since I don’t really want to spend more time chasing the udev issue.

One quick check: What are the permissions and owner of your udev rule?

prhunt · October 13, 2011, 12:06am

$ ls -l /etc/udev/rules.d
total 284
-rw-r--r-- 1 root root    571 Feb 19  2011 51-lirc.rules
-rw-r--r-- 1 root root   1269 Feb 19  2011 52-usx2yaudio.rules
-rw-r--r-- 1 root root  13908 Aug 12 23:10 55-hpmud.rules
-rw-r--r-- 1 root root 161384 Apr  6  2011 55-libsane.rules
-rw-r--r-- 1 root root    692 Aug 12 23:10 56-hpmud_support.rules
-rw-r--r-- 1 root root  46551 Apr  6  2011 56-sane-backends-autoconfig.rules
-rw-r--r-- 1 root root    611 Oct 11 00:01 60-vboxdrv.rules
-rw-r--r-- 1 root root    188 Oct 11 00:00 60-vboxguest.rules
-rw-r--r-- 1 root root   2016 Feb 19  2011 70-kpartx.rules
-rw-r--r-- 1 root root   1340 Aug 31 15:25 70-persistent-cd.rules
-rw-r--r-- 1 root root    726 Sep 19 19:12 70-persistent-net.rules
-rw-r--r-- 1 root root    182 Feb 19  2011 71-multipath.rules
-rw-r--r-- 1 root root   1420 Jul  1 21:34 77-network.rules
-rw-r--r-- 1 root root    643 Jul  1 21:34 81-mount.rules
-rw-r--r-- 1 root root     58 Oct 12 21:55 90-udev-audio.rules
-rw-r--r-- 1 root root     93 Feb 19  2011 99-iwlwifi-led.rules
-rw-r--r-- 1 root root   1300 Oct  3 21:50 kino.rules

Since the rule worked for me in 11.3, and it works now for deano_ferrari in 11.4, I think that there must be some issue with my particular system configuration. Something broken, or my udev rule is getting squashed, somewhere along the line. Why this would be the case eludes me, since I don’t believe that very many apps apart from jack actually use /dev/hpet.

Paul

deano_ferrari · October 13, 2011, 3:42am

I’ve only ever seen this type of behaviour when the group doesn’t exist. Is the ‘audio’ group missing for some reason?

getent group

deano_ferrari · October 13, 2011, 3:46am

Another thought (long shot) I had was to check for any conflicting rules in /lib/udev/rules.d/ as well.

prhunt · October 13, 2011, 10:11am

@ deano_ferrari

Thanks for the suggestions. audio group is present.
a quick check (cat * | grep -i hpet) within /lib/udev/rules.d yielded nothing

Paul

hank_se · October 13, 2011, 2:47pm

You might try to make it persistent, like this:

KERNEL==“hpet”, GROUP:=“audio”, MODE:=“0660”