udev zombies

udev zombies

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 am using bk as of 30.June.
Kernel is 2.6.7-rc2-bk1.
udev compile flags: USE_LOG˙lse DEBUG˙lse USE_KLIBC=true
Any idea?

Please CC me, as I'm not subscribed.

- --
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAvLljFGK1OIvVOP4RAu8OAJ9NofGlZ/6g+iPuyVYJiObibijQHQCgkOAa
+kwzPVswKxrmEfTI39IHq24=SNsw
-----END PGP SIGNATURE-----


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_idÅ66&op=click
_______________________________________________
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

Re: udev zombies

[Greg KH]

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

Re: udev zombies

[Michael Buesch]

-----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

Re: udev zombies

[Harald Hoyer]

[-- 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 --]

Re: udev zombies

[Harald Hoyer]

[-- 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 --]

Re: udev zombies

[jnf]

-----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

Re: udev zombies

[jnf]

-----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

Re: udev zombies

[Kay Sievers]

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

Re: udev zombies

[jnf]

-----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

Re: udev zombies

[jnf]

-----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

Re: udev zombies

[Kay Sievers]

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

Re: udev zombies

[jnf]

-----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

Re: udev zombies

[Michael Buesch]

-----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

Re: udev zombies

[Kay Sievers]

[-- 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)}')
 

Re: udev zombies

[Michael Buesch]

-----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

Re: udev zombies

[Kay Sievers]

[-- 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) {

Re: udev zombies

[Michael Buesch]

[-- 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];

Re: udev zombies

[Kay Sievers]

[-- 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;
 	}
 	

Re: udev zombies

[Greg KH]

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