* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
@ 2004-06-02 16:53 ` Greg KH
2004-06-02 18:26 ` Michael Buesch
` (16 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Greg KH @ 2004-06-02 16:53 UTC (permalink / raw)
To: linux-hotplug
On Tue, Jun 01, 2004 at 07:14:11PM +0200, Michael Buesch wrote:
> Hi,
>
> mb@lfs:~> ps aux|grep udev
> root 345 0.0 0.0 80 56 ? S< 08:16 0:00 udevd
> root 1604 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1605 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1606 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1607 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1608 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1609 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1610 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1611 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1612 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1613 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1614 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1632 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1633 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1634 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1635 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1636 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1637 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1638 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1639 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1640 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1641 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1642 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1643 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1644 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
> root 1645 0.0 0.0 0 0 ? Z< 08:16 0:00 [udev] <defunct>
>
> I expect all these zombies shouldn't be there 8-)
I would expect them not to be there too :)
Care to rebuild udev with
make USE_LOG=true DEBUG=true
and let us know what the syslog messages are for those dead udev
instances?
thanks,
greg k-h
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
2004-06-02 16:53 ` Greg KH
@ 2004-06-02 18:26 ` Michael Buesch
2004-06-03 8:24 ` Harald Hoyer
` (15 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Michael Buesch @ 2004-06-02 18:26 UTC (permalink / raw)
To: linux-hotplug
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 02 June 2004 18:53, you wrote:
> I would expect them not to be there too :)
>
> Care to rebuild udev with
> make USE_LOG=true DEBUG=true
> and let us know what the syslog messages are for those dead udev
> instances?
Hm, I found out, that zombies appear only when linked agains klibc.
mb@lfs:~> ps aux|grep udev
root 380 0.0 0.0 84 64 ? S< 20:15 0:00 udevd
root 1636 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1637 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1638 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1639 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1640 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1641 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1642 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1653 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1654 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1655 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1656 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1657 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1658 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1659 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1660 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1661 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1662 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1663 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1664 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1665 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1666 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1667 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1669 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1670 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1671 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1672 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1683 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1684 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1699 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1706 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1726 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1733 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1757 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1762 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1853 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1854 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1855 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1856 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1920 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
root 1927 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
Whoo, there are millions of debugging messages.
I'll pick up a few ones I find useful.
Jun 2 21:16:18 lfs kernel: udev[1636]: sysfs_path_is_link: stat() failed
^(This line is repeated a few times)
Jun 2 21:16:18 lfs kernel: udev[1636]: get_sysfs_device: timed out waiting for device symlink, continuing on anyway...
Jun 2 21:16:18 lfs kernel: udev[1636]: namedev_name_device: class_dev->name = 'vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: namedev_name_device: udev->kernel_name = 'vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: namedev_name_device: kernel_number='1'
Jun 2 21:16:18 lfs kernel: udev[1636]: namedev_name_device: name, 'vcs1' is going to have owner='root', group='root', mode = 0600
Jun 2 21:16:18 lfs kernel: udev[1636]: udev_add_device: name='vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: get_id_by_name: reading '/etc/passwd' as db file
Jun 2 21:16:18 lfs kernel: udev[1636]: get_id_by_name: id for 'root' is '0'
Jun 2 21:16:18 lfs kernel: udev[1636]: get_id_by_name: reading '/etc/group' as db file
Jun 2 21:16:18 lfs kernel: udev[1636]: get_id_by_name: id for 'root' is '0'
Jun 2 21:16:18 lfs kernel: udev[1636]: creating device node '/udev/vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: make_node: preserve file '/udev/vcs1', cause it has correct dev_t
Jun 2 21:16:18 lfs kernel: udev[1636]: make_node: chmod(/udev/vcs1, 020600)
Jun 2 21:16:18 lfs kernel: udev[1636]: udevdb_add_dev: store key '/class/vc/vcs1' for device 'vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: dev_d_send: DEVNAME='/udev/vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: call_foreach_file: open directory '/etc/dev.d/vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: call_foreach_file: unable to open '/etc/dev.d/vcs1'
Jun 2 21:16:18 lfs kernel: udev[1636]: call_foreach_file: open directory '/etc/dev.d/vc'
Jun 2 21:16:18 lfs kernel: udev[1636]: call_foreach_file: unable to open '/etc/dev.d/vc'
Jun 2 21:16:18 lfs kernel: udev[1636]: call_foreach_file: open directory '/etc/dev.d/default'
> thanks,
>
> greg k-h
PS:
and isn't that strange, too?
Jun 2 21:16:18 lfs kernel: udevd[380]: sig_handler: unhandled signal
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAvhvOFGK1OIvVOP4RAqaSAJ9vrmtNeD1yskvrYl9sOKLy625CngCgtgf6
5D+HpFjhRydQ3U0nQcJKlS8=g9yk
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
2004-06-02 16:53 ` Greg KH
2004-06-02 18:26 ` Michael Buesch
@ 2004-06-03 8:24 ` Harald Hoyer
2004-06-03 8:27 ` Harald Hoyer
` (14 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Harald Hoyer @ 2004-06-03 8:24 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 185 bytes --]
Michael Buesch wrote:
> and isn't that strange, too?
> Jun 2 21:16:18 lfs kernel: udevd[380]: sig_handler: unhandled signal
>
Hmm, the whole thing reminds me of unhandled SIGCHLD...
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
` (2 preceding siblings ...)
2004-06-03 8:24 ` Harald Hoyer
@ 2004-06-03 8:27 ` Harald Hoyer
2004-06-03 8:54 ` jnf
` (13 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Harald Hoyer @ 2004-06-03 8:27 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 241 bytes --]
Harald Hoyer wrote:
> Michael Buesch wrote:
>
>> and isn't that strange, too?
>> Jun 2 21:16:18 lfs kernel: udevd[380]: sig_handler: unhandled signal
>>
>
> Hmm, the whole thing reminds me of unhandled SIGCHLD...
and/or forgotten wait()
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
` (3 preceding siblings ...)
2004-06-03 8:27 ` Harald Hoyer
@ 2004-06-03 8:54 ` jnf
2004-06-04 1:45 ` jnf
` (12 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jnf @ 2004-06-03 8:54 UTC (permalink / raw)
To: linux-hotplug
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Agreed, I was going to take a look at it myself tommorrow as I noticied
recently i was having the same problem- that is unless of course someone
else gets a fix for it first.
- --
The cry has been that when war is declared, all opposition should
therefore be hushed. A sentiment more unworthy of a free country could
hardly be propagated. If the doctrine be admitted, rulers have only to
declare war and they are screened at once from scrutiny ... In war,
then, as in peace, assert the freedom of speech and of the press.
Cling to this as the bulwark of all our rights and privileges.
-- William Ellery Channing
On Thu, 3 Jun 2004, Harald Hoyer wrote:
> Harald Hoyer wrote:
> > Michael Buesch wrote:
> >
> >> and isn't that strange, too?
> >> Jun 2 21:16:18 lfs kernel: udevd[380]: sig_handler: unhandled signal
> >>
> >
> > Hmm, the whole thing reminds me of unhandled SIGCHLD...
>
> and/or forgotten wait()
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (OpenBSD)
iD8DBQFAvudPsKAeTAhLiCERAif6AJ0VYEr1EK6DlqRjr5IAtf3WUbvSSQCeIVkl
HNAKFvZ+Cf7OswDzPQprxUE=doCx
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
` (4 preceding siblings ...)
2004-06-03 8:54 ` jnf
@ 2004-06-04 1:45 ` jnf
2004-06-04 8:03 ` Kay Sievers
` (11 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jnf @ 2004-06-04 1:45 UTC (permalink / raw)
To: linux-hotplug
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi,
looking through udevd.c right now at the signal handling routines, I see
that sig_handler is the routine called by all of the custom signal
handlers and it is just a switch statement and tests for SIGINT, SIGTERM
SIGALRM and SIGCHLD, so in theory [obviously nothing works as it should in
theory], we should never see the default statement, which is what we are
seeing- I havent had much of a chance to look at it, but i noticied this
line:
act.sa_andler = sig_handler;
is that a typo, or is there something I'm not understanding? Shouldn't
that be act.sa_handler? I just changed the dbg() statement from unhandled
signal to dbg("unhandled signal number #\n", signum);, so im going to
reboot in a moment and then try to cause it to recieve the signal, also
its my gf's birthday so I won't have much more time tonight to play.
cheers,
j
- --
The cry has been that when war is declared, all opposition should
therefore be hushed. A sentiment more unworthy of a free country could
hardly be propagated. If the doctrine be admitted, rulers have only to
declare war and they are screened at once from scrutiny ... In war,
then, as in peace, assert the freedom of speech and of the press.
Cling to this as the bulwark of all our rights and privileges.
-- William Ellery Channing
On Wed, 2 Jun 2004, Michael Buesch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 02 June 2004 18:53, you wrote:
> > I would expect them not to be there too :)
> >
> > Care to rebuild udev with
> > make USE_LOG=true DEBUG=true
> > and let us know what the syslog messages are for those dead udev
> > instances?
>
> Hm, I found out, that zombies appear only when linked agains klibc.
>
> mb@lfs:~> ps aux|grep udev
> root 380 0.0 0.0 84 64 ? S< 20:15 0:00 udevd
> root 1636 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1637 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1638 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1639 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1640 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1641 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1642 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1653 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1654 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1655 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1656 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1657 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1658 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1659 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1660 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1661 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1662 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1663 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1664 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1665 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1666 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1667 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1669 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1670 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1671 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1672 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1683 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1684 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1699 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1706 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1726 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1733 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1757 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1762 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1853 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1854 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1855 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1856 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1920 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
> root 1927 0.0 0.0 0 0 ? Z< 20:15 0:00 [udev] <defunct>
>
>
> Whoo, there are millions of debugging messages.
> I'll pick up a few ones I find useful.
>
> Jun 2 21:16:18 lfs kernel: udev[1636]: sysfs_path_is_link: stat() failed
> ^(This line is repeated a few times)
> Jun 2 21:16:18 lfs kernel: udev[1636]: get_sysfs_device: timed out waiting for device symlink, continuing on anyway...
> Jun 2 21:16:18 lfs kernel: udev[1636]: namedev_name_device: class_dev->name = 'vcs1'
> Jun 2 21:16:18 lfs kernel: udev[1636]: namedev_name_device: udev->kernel_name = 'vcs1'
> Jun 2 21:16:18 lfs kernel: udev[1636]: namedev_name_device: kernel_number='1'
> Jun 2 21:16:18 lfs kernel: udev[1636]: namedev_name_device: name, 'vcs1' is going to have owner='root', group='root', mode = 0600
> Jun 2 21:16:18 lfs kernel: udev[1636]: udev_add_device: name='vcs1'
> Jun 2 21:16:18 lfs kernel: udev[1636]: get_id_by_name: reading '/etc/passwd' as db file
> Jun 2 21:16:18 lfs kernel: udev[1636]: get_id_by_name: id for 'root' is '0'
> Jun 2 21:16:18 lfs kernel: udev[1636]: get_id_by_name: reading '/etc/group' as db file
> Jun 2 21:16:18 lfs kernel: udev[1636]: get_id_by_name: id for 'root' is '0'
> Jun 2 21:16:18 lfs kernel: udev[1636]: creating device node '/udev/vcs1'
> Jun 2 21:16:18 lfs kernel: udev[1636]: make_node: preserve file '/udev/vcs1', cause it has correct dev_t
> Jun 2 21:16:18 lfs kernel: udev[1636]: make_node: chmod(/udev/vcs1, 020600)
> Jun 2 21:16:18 lfs kernel: udev[1636]: udevdb_add_dev: store key '/class/vc/vcs1' for device 'vcs1'
> Jun 2 21:16:18 lfs kernel: udev[1636]: dev_d_send: DEVNAME='/udev/vcs1'
> Jun 2 21:16:18 lfs kernel: udev[1636]: call_foreach_file: open directory '/etc/dev.d/vcs1'
> Jun 2 21:16:18 lfs kernel: udev[1636]: call_foreach_file: unable to open '/etc/dev.d/vcs1'
> Jun 2 21:16:18 lfs kernel: udev[1636]: call_foreach_file: open directory '/etc/dev.d/vc'
> Jun 2 21:16:18 lfs kernel: udev[1636]: call_foreach_file: unable to open '/etc/dev.d/vc'
> Jun 2 21:16:18 lfs kernel: udev[1636]: call_foreach_file: open directory '/etc/dev.d/default'
>
> > thanks,
> >
> > greg k-h
>
> PS:
> and isn't that strange, too?
> Jun 2 21:16:18 lfs kernel: udevd[380]: sig_handler: unhandled signal
>
> - --
> Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFAvhvOFGK1OIvVOP4RAqaSAJ9vrmtNeD1yskvrYl9sOKLy625CngCgtgf6
> 5D+HpFjhRydQ3U0nQcJKlS8> =g9yk
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> >From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (OpenBSD)
iD8DBQFAv9Q/sKAeTAhLiCERAtisAJ9dREQMIOMgMzda+695upn8aFwACwCfRlEb
5+usz5L18ih7VrNZjxoNaYw=ptN1
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
` (5 preceding siblings ...)
2004-06-04 1:45 ` jnf
@ 2004-06-04 8:03 ` Kay Sievers
2004-06-04 8:36 ` jnf
` (10 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Kay Sievers @ 2004-06-04 8:03 UTC (permalink / raw)
To: linux-hotplug
On Thu, Jun 03, 2004 at 08:45:31PM -0500, jnf wrote:
> looking through udevd.c right now at the signal handling routines, I see
> that sig_handler is the routine called by all of the custom signal
> handlers and it is just a switch statement and tests for SIGINT, SIGTERM
> SIGALRM and SIGCHLD, so in theory [obviously nothing works as it should in
> theory], we should never see the default statement, which is what we are
> seeing- I havent had much of a chance to look at it, but i noticied this
> line:
> act.sa_andler = sig_handler;
>
> is that a typo, or is there something I'm not understanding? Shouldn't
> that be act.sa_handler? I just changed the dbg() statement from unhandled
> signal to dbg("unhandled signal number #\n", signum);, so im going to
> reboot in a moment and then try to cause it to recieve the signal, also
> its my gf's birthday so I won't have much more time tonight to play.
Come on, how can you compile this? I can't find this "typo" in the code.
thanks,
Kay
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
` (6 preceding siblings ...)
2004-06-04 8:03 ` Kay Sievers
@ 2004-06-04 8:36 ` jnf
2004-06-04 8:39 ` jnf
` (9 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jnf @ 2004-06-04 8:36 UTC (permalink / raw)
To: linux-hotplug
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
that waht i was thinking also, but its there, i just dl'd it from
kernel.org, grep for sa_andler.
j
- --
The cry has been that when war is declared, all opposition should
therefore be hushed. A sentiment more unworthy of a free country could
hardly be propagated. If the doctrine be admitted, rulers have only to
declare war and they are screened at once from scrutiny ... In war,
then, as in peace, assert the freedom of speech and of the press.
Cling to this as the bulwark of all our rights and privileges.
-- William Ellery Channing
On Fri, 4 Jun 2004, Kay Sievers wrote:
> On Thu, Jun 03, 2004 at 08:45:31PM -0500, jnf wrote:
> > looking through udevd.c right now at the signal handling routines, I see
> > that sig_handler is the routine called by all of the custom signal
> > handlers and it is just a switch statement and tests for SIGINT, SIGTERM
> > SIGALRM and SIGCHLD, so in theory [obviously nothing works as it should in
> > theory], we should never see the default statement, which is what we are
> > seeing- I havent had much of a chance to look at it, but i noticied this
> > line:
> > act.sa_andler = sig_handler;
> >
> > is that a typo, or is there something I'm not understanding? Shouldn't
> > that be act.sa_handler? I just changed the dbg() statement from unhandled
> > signal to dbg("unhandled signal number #\n", signum);, so im going to
> > reboot in a moment and then try to cause it to recieve the signal, also
> > its my gf's birthday so I won't have much more time tonight to play.
>
> Come on, how can you compile this? I can't find this "typo" in the code.
>
> thanks,
> Kay
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (OpenBSD)
iD8DBQFAwDSvsKAeTAhLiCERAsEfAJ9J3Swd3ywCCeqEXhsNLYz7lW/3NQCeN7q3
JRb3OuEPOjEZSA2GTzx/r5Y=RDDR
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
` (7 preceding siblings ...)
2004-06-04 8:36 ` jnf
@ 2004-06-04 8:39 ` jnf
2004-06-04 9:32 ` Kay Sievers
` (8 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jnf @ 2004-06-04 8:39 UTC (permalink / raw)
To: linux-hotplug
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
the only thing i was thining is despite the fact i should get a 'no such
member' type error, i either dont or it continues and that it gets the
address of the structre and that causes it to be a byte or two off, either
way im going on 7 hours and no zombies. If you doubt the typo exists,
download the 25 source from kernel.org and grep for sa_andler.
j
- --
The cry has been that when war is declared, all opposition should
therefore be hushed. A sentiment more unworthy of a free country could
hardly be propagated. If the doctrine be admitted, rulers have only to
declare war and they are screened at once from scrutiny ... In war,
then, as in peace, assert the freedom of speech and of the press.
Cling to this as the bulwark of all our rights and privileges.
-- William Ellery Channing
On Fri, 4 Jun 2004, Kay Sievers wrote:
> On Thu, Jun 03, 2004 at 08:45:31PM -0500, jnf wrote:
> > looking through udevd.c right now at the signal handling routines, I see
> > that sig_handler is the routine called by all of the custom signal
> > handlers and it is just a switch statement and tests for SIGINT, SIGTERM
> > SIGALRM and SIGCHLD, so in theory [obviously nothing works as it should in
> > theory], we should never see the default statement, which is what we are
> > seeing- I havent had much of a chance to look at it, but i noticied this
> > line:
> > act.sa_andler = sig_handler;
> >
> > is that a typo, or is there something I'm not understanding? Shouldn't
> > that be act.sa_handler? I just changed the dbg() statement from unhandled
> > signal to dbg("unhandled signal number #\n", signum);, so im going to
> > reboot in a moment and then try to cause it to recieve the signal, also
> > its my gf's birthday so I won't have much more time tonight to play.
>
> Come on, how can you compile this? I can't find this "typo" in the code.
>
> thanks,
> Kay
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> >From Windows to Linux, servers to mobile, InstallShield X is the one
> installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (OpenBSD)
iD8DBQFAwDVjsKAeTAhLiCERAvy5AJ950Gf0k4DqU1XC1T/kc6zlfsmLqgCffdX1
bc84at9GwOx/vuVYvFPuEcE=XqwH
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
` (8 preceding siblings ...)
2004-06-04 8:39 ` jnf
@ 2004-06-04 9:32 ` Kay Sievers
2004-06-04 17:23 ` jnf
` (7 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Kay Sievers @ 2004-06-04 9:32 UTC (permalink / raw)
To: linux-hotplug
On Fri, Jun 04, 2004 at 03:39:54AM -0500, jnf wrote:
> the only thing i was thining is despite the fact i should get a 'no such
> member' type error, i either dont or it continues and that it gets the
> address of the structre and that causes it to be a byte or two off, either
> way im going on 7 hours and no zombies. If you doubt the typo exists,
> download the 25 source from kernel.org and grep for sa_andler.
No, sorry. I can't find it.
[kay@pim udev-025]$ grep sa_ *
udev.c: act.sa_handler = sig_handler;
udev.c: sigemptyset (&act.sa_mask);
udev.c: act.sa_flags = SA_RESTART;
udevd.c: act.sa_handler = sig_handler;
udevd.c: sigemptyset(&act.sa_mask);
udevd.c: act.sa_flags = SA_RESTART;
Kay
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
` (9 preceding siblings ...)
2004-06-04 9:32 ` Kay Sievers
@ 2004-06-04 17:23 ` jnf
2004-06-06 10:08 ` Michael Buesch
` (6 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jnf @ 2004-06-04 17:23 UTC (permalink / raw)
To: linux-hotplug
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hrm, I just decompressed the tarball again and rechecked, and it seems you
are correct- i mustve introduced that myself somehow looking through it-
my apologies. I didn't understand how it was compiling either.
Still no zombies though.
again apologies.
j
- --
The cry has been that when war is declared, all opposition should
therefore be hushed. A sentiment more unworthy of a free country could
hardly be propagated. If the doctrine be admitted, rulers have only to
declare war and they are screened at once from scrutiny ... In war,
then, as in peace, assert the freedom of speech and of the press.
Cling to this as the bulwark of all our rights and privileges.
-- William Ellery Channing
On Fri, 4 Jun 2004, Kay Sievers wrote:
> On Fri, Jun 04, 2004 at 03:39:54AM -0500, jnf wrote:
> > the only thing i was thining is despite the fact i should get a 'no such
> > member' type error, i either dont or it continues and that it gets the
> > address of the structre and that causes it to be a byte or two off, either
> > way im going on 7 hours and no zombies. If you doubt the typo exists,
> > download the 25 source from kernel.org and grep for sa_andler.
>
> No, sorry. I can't find it.
>
>
> [kay@pim udev-025]$ grep sa_ *
> udev.c: act.sa_handler = sig_handler;
> udev.c: sigemptyset (&act.sa_mask);
> udev.c: act.sa_flags = SA_RESTART;
> udevd.c: act.sa_handler = sig_handler;
> udevd.c: sigemptyset(&act.sa_mask);
> udevd.c: act.sa_flags = SA_RESTART;
>
>
> Kay
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (OpenBSD)
iD8DBQFAwLAOsKAeTAhLiCERAisJAJ9vQ+EQ6lt2L6tW6bOWuEYXhohnGACfRONL
+gQzI29JbhwX9Bja2OQQNkA=uJeo
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
` (10 preceding siblings ...)
2004-06-04 17:23 ` jnf
@ 2004-06-06 10:08 ` Michael Buesch
2004-06-06 10:52 ` Kay Sievers
` (5 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Michael Buesch @ 2004-06-06 10:08 UTC (permalink / raw)
To: linux-hotplug
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
So I applied this patch to udevd:
- --- udev.official/udevd.c 2004-05-30 10:57:03.000000000 +0200
+++ udev.m/udevd.c 2004-06-05 16:03:31.000000000 +0200
@@ -325,7 +325,7 @@
goto do_write;
break;
default:
- - dbg("unhandled signal");
+ dbg("unhandled signal %d", signum);
return;
}
Result in my syslog is:
Jun 6 11:32:21 lfs kernel: udevd[329]: sig_handler: unhandled signal -4
Heh? Somebody out there who could interpret it?
Some time ago I wrote the sig_handler() myself and I submitted a patch to
Greg. It was absolutely impossible to trigger "default:" IMHO and it still
should be. (There were some changes, but I can't find why it's triggered)
And my zombie problem is still there. :)
And again: I'm using klibc. With glibc everything seems to work fine.
(haven't checked the sig_handler() stuff, but at least there are no
zombies)
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAwu0JFGK1OIvVOP4RAk1EAJ49mgLjv/6oUDUfuLnq/KzV/PnPnACgw1f3
6DgQkumszxW8yCllaiTDTwk=0i/c
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
` (11 preceding siblings ...)
2004-06-06 10:08 ` Michael Buesch
@ 2004-06-06 10:52 ` Kay Sievers
2004-06-06 11:16 ` Michael Buesch
` (4 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Kay Sievers @ 2004-06-06 10:52 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 379 bytes --]
On Sun, Jun 06, 2004 at 12:08:09PM +0200, Michael Buesch wrote:
> And my zombie problem is still there. :)
>
> And again: I'm using klibc. With glibc everything seems to work fine.
> (haven't checked the sig_handler() stuff, but at least there are no
> zombies)
Could you please test this patch. If this fixes the problem on your box,
I will look deeper into it.
thanks,
Kay
[-- Attachment #2: 01-udev-klibc-fix.patch --]
[-- Type: text/plain, Size: 436 bytes --]
===== klibc/klibc/arch/i386/MCONFIG 1.2 vs edited =====
--- 1.2/klibc/klibc/arch/i386/MCONFIG Fri May 21 00:14:07 2004
+++ edited/klibc/klibc/arch/i386/MCONFIG Sun Jun 6 12:42:53 2004
@@ -9,7 +9,7 @@
# Enable this to compile with register parameters; only safe for
# gcc > 3
-REGPARM_OPT := -mregparm=3 -DREGPARM
+#REGPARM_OPT := -mregparm=3 -DREGPARM
gcc_major := $(shell $(CC) -v 2>&1 | awk '/gcc version/{print int($$3)}')
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
` (12 preceding siblings ...)
2004-06-06 10:52 ` Kay Sievers
@ 2004-06-06 11:16 ` Michael Buesch
2004-06-06 13:16 ` Kay Sievers
` (3 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Michael Buesch @ 2004-06-06 11:16 UTC (permalink / raw)
To: linux-hotplug
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 06 June 2004 12:52, you wrote:
> On Sun, Jun 06, 2004 at 12:08:09PM +0200, Michael Buesch wrote:
>
> > And my zombie problem is still there. :)
> >
> > And again: I'm using klibc. With glibc everything seems to work fine.
> > (haven't checked the sig_handler() stuff, but at least there are no
> > zombies)
>
> Could you please test this patch. If this fixes the problem on your box,
> I will look deeper into it.
[SNIP]
Fixes both problems.
> thanks,
> Kay
>
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAwvz7FGK1OIvVOP4RAt1eAJ9twxJoyp54HKA+LlhiMFHBbfIjJACcCJcw
0zcQQBygO9SJvLr7/XL21iQ=EKW1
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
` (13 preceding siblings ...)
2004-06-06 11:16 ` Michael Buesch
@ 2004-06-06 13:16 ` Kay Sievers
2004-06-06 13:38 ` Michael Buesch
` (2 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: Kay Sievers @ 2004-06-06 13:16 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 898 bytes --]
On Sun, Jun 06, 2004 at 01:16:05PM +0200, Michael Buesch wrote:
> On Sunday 06 June 2004 12:52, you wrote:
> > On Sun, Jun 06, 2004 at 12:08:09PM +0200, Michael Buesch wrote:
> >
> > > And my zombie problem is still there. :)
> > >
> > > And again: I'm using klibc. With glibc everything seems to work fine.
> > > (haven't checked the sig_handler() stuff, but at least there are no
> > > zombies)
> >
> > Could you please test this patch. If this fixes the problem on your box,
> > I will look deeper into it.
> [SNIP]
>
> Fixes both problems.
Michael, you were right, it was the signal handler. Good catch.
The problem was caused by using register- instead of the expected stack-
parameters for the signal handling function. Adding a attribute to prevent
the 'optimization', should fix it.
It would be great, if you are able to test it another time with the reenabled
regparms.
thanks,
Kay
[-- Attachment #2: 01-udev-regparm-fix.patch --]
[-- Type: text/plain, Size: 292 bytes --]
===== udevd.c 1.32 vs edited =====
--- 1.32/udevd.c Fri May 21 06:13:45 2004
+++ edited/udevd.c Sun Jun 6 14:18:23 2004
@@ -306,7 +306,7 @@
return;
}
-static void sig_handler(int signum)
+__attribute__ ((regparm(0))) static void sig_handler(int signum)
{
int rc;
switch (signum) {
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
` (14 preceding siblings ...)
2004-06-06 13:16 ` Kay Sievers
@ 2004-06-06 13:38 ` Michael Buesch
2004-06-06 23:37 ` Kay Sievers
2004-06-07 2:20 ` Greg KH
17 siblings, 0 replies; 19+ messages in thread
From: Michael Buesch @ 2004-06-06 13:38 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: Text/Plain, Size: 578 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 06 June 2004 15:16, you wrote:
> It would be great, if you are able to test it another time with the reenabled
> regparms.
The attached patch fixes the whole stuff for me.
I imported some macros from the kernel. Ok, or do
you prefer other macro-names?
> thanks,
> Kay
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAwx5sFGK1OIvVOP4RAmsvAJ44nS0AMWlCi/xWIMacdfB/hsfK2wCg3O87
VksGYDNITbTFdpH1NzF44A0=
=KCFA
-----END PGP SIGNATURE-----
[-- Attachment #2: udev-sighandler.diff --]
[-- Type: text/x-diff, Size: 1300 bytes --]
===== udevd.c 1.32 vs edited =====
--- 1.32/udevd.c 2004-05-21 06:13:45 +02:00
+++ edited/udevd.c 2004-06-06 15:27:05 +02:00
@@ -306,7 +306,7 @@
return;
}
-static void sig_handler(int signum)
+asmlinkage static void sig_handler(int signum)
{
int rc;
switch (signum) {
@@ -325,7 +325,7 @@
goto do_write;
break;
default:
- dbg("unhandled signal");
+ dbg("unhandled signal: %d", signum);
return;
}
===== udev.c 1.56 vs edited =====
--- 1.56/udev.c 2004-03-25 00:21:41 +01:00
+++ edited/udev.c 2004-06-06 15:27:31 +02:00
@@ -55,7 +55,7 @@
}
#endif
-static void sig_handler(int signum)
+asmlinkage static void sig_handler(int signum)
{
switch (signum) {
case SIGINT:
@@ -63,7 +63,7 @@
udevdb_exit();
exit(20 + signum);
default:
- dbg("unhandled signal");
+ dbg("unhandled signal: %d", signum);
}
}
===== udev.h 1.57 vs edited =====
--- 1.57/udev.h 2004-04-01 04:12:12 +02:00
+++ edited/udev.h 2004-06-06 15:26:21 +02:00
@@ -40,6 +40,10 @@
/* length of public data */
#define UDEVICE_LEN (offsetof(struct udevice, bus_id))
+#define asmlinkage __attribute__((regparm(0)))
+#define FASTCALL(x) x __attribute__((regparm(3)))
+#define fastcall __attribute__((regparm(3)))
+
struct udevice {
char name[NAME_SIZE];
char owner[OWNER_SIZE];
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
` (15 preceding siblings ...)
2004-06-06 13:38 ` Michael Buesch
@ 2004-06-06 23:37 ` Kay Sievers
2004-06-07 2:20 ` Greg KH
17 siblings, 0 replies; 19+ messages in thread
From: Kay Sievers @ 2004-06-06 23:37 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
On Sun, Jun 06, 2004 at 03:38:52PM +0200, Michael Buesch wrote:
> On Sunday 06 June 2004 15:16, you wrote:
> > It would be great, if you are able to test it another time with the reenabled
> > regparms.
>
> The attached patch fixes the whole stuff for me.
> I imported some macros from the kernel. Ok, or do
> you prefer other macro-names?
> +#define asmlinkage __attribute__((regparm(0)))
> +#define FASTCALL(x) x __attribute__((regparm(3)))
> +#define fastcall __attribute__((regparm(3)))
Hmm, I prefer no macro at all.
Greg, here is the usual bk text:
===
fix udevd zombies
The recent version of klibc switched to -mregparm=3. This broke the
signal handlers parameter, cause it is called directly from the kernel
with the parameter on the stack not in a register.
===
thanks,
Kay
[-- Attachment #2: 01-udev-regparm-fix.patch --]
[-- Type: text/plain, Size: 1124 bytes --]
===== udev.c 1.56 vs edited =====
--- 1.56/udev.c Thu Mar 25 00:21:41 2004
+++ edited/udev.c Mon Jun 7 00:49:17 2004
@@ -55,7 +55,7 @@
}
#endif
-static void sig_handler(int signum)
+__attribute__((regparm(0))) static void sig_handler(int signum)
{
switch (signum) {
case SIGINT:
@@ -63,7 +63,7 @@
udevdb_exit();
exit(20 + signum);
default:
- dbg("unhandled signal");
+ dbg("unhandled signal %d", signum);
}
}
@@ -128,7 +128,7 @@
goto exit;
}
- /* set up a default signal handler for now */
+ /* set signal handlers */
act.sa_handler = sig_handler;
sigemptyset (&act.sa_mask);
act.sa_flags = SA_RESTART;
===== udevd.c 1.32 vs edited =====
--- 1.32/udevd.c Fri May 21 06:13:45 2004
+++ edited/udevd.c Mon Jun 7 00:50:03 2004
@@ -306,9 +306,10 @@
return;
}
-static void sig_handler(int signum)
+__attribute__((regparm(0))) static void sig_handler(int signum)
{
int rc;
+
switch (signum) {
case SIGINT:
case SIGTERM:
@@ -325,7 +326,7 @@
goto do_write;
break;
default:
- dbg("unhandled signal");
+ dbg("unhandled signal %d", signum);
return;
}
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: udev zombies
2004-06-01 17:14 udev zombies Michael Buesch
` (16 preceding siblings ...)
2004-06-06 23:37 ` Kay Sievers
@ 2004-06-07 2:20 ` Greg KH
17 siblings, 0 replies; 19+ messages in thread
From: Greg KH @ 2004-06-07 2:20 UTC (permalink / raw)
To: linux-hotplug
On Mon, Jun 07, 2004 at 01:37:19AM +0200, Kay Sievers wrote:
> On Sun, Jun 06, 2004 at 03:38:52PM +0200, Michael Buesch wrote:
> > On Sunday 06 June 2004 15:16, you wrote:
> > > It would be great, if you are able to test it another time with the reenabled
> > > regparms.
> >
> > The attached patch fixes the whole stuff for me.
> > I imported some macros from the kernel. Ok, or do
> > you prefer other macro-names?
>
> > +#define asmlinkage __attribute__((regparm(0)))
> > +#define FASTCALL(x) x __attribute__((regparm(3)))
> > +#define fastcall __attribute__((regparm(3)))
>
> Hmm, I prefer no macro at all.
>
> Greg, here is the usual bk text:
> => fix udevd zombies
>
> The recent version of klibc switched to -mregparm=3. This broke the
> signal handlers parameter, cause it is called directly from the kernel
> with the parameter on the stack not in a register.
> =
Applied, thanks.
greg k-h
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 19+ messages in thread