[opensuse] OS 12.3 udev hangs while booting
While booting the system again several times I encountered a strange error message while booting: systemd-udevd[239]: worker [268] /devices/pci0000:00/0000:00:1d.2/usb7/7-0:1.0 timeout; kill it There is the string "usb7" within the message, but I did *not* have any USB devices connected to the system. How can I find out what PCI device thi is? Below is the output of lspci. System is plain openSUSE 12.3 with current updates. Thanx Malte 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07) 00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port (rev 07) 00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) 00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03) 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03) 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) 00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) 00:1d.3 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03) 00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03) 01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce G210M] (rev a2) 01:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1) 02:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5784M Gigabit Ethernet PCIe (rev 10) 03:00.0 Network controller: Intel Corporation Centrino Wireless-N 1000 [Condor Peak] -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 09.06.2013 17:50, schrieb Malte Gell:
While booting the system again several times I encountered a strange error message while booting:
systemd-udevd[239]: worker [268] /devices/pci0000:00/0000:00:1d.2/usb7/7-0:1.0 timeout; kill it
I did some google. Device 0000:00:1d.2 is the USB controller. According to hwinfo: Driver: "uhci_hcd" Driver Modules: "uhci_hcd" But, lsmod does not list this module!? Why does usb works if there is no module uhci loaded? People from other Linuxes suggest to first blacklist the offending kernel module and the load it manually at later stage, e.g. in boot.local. I just want to get the boot process fixed, it hangs at udevd.... Malte -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Sun, 09 Jun 2013 18:17:53 +0200 Malte Gell <malte.gell@gmail.com> пишет:
Am 09.06.2013 17:50, schrieb Malte Gell:
While booting the system again several times I encountered a strange error message while booting:
systemd-udevd[239]: worker [268] /devices/pci0000:00/0000:00:1d.2/usb7/7-0:1.0 timeout; kill it
I did some google. Device 0000:00:1d.2 is the USB controller. According to hwinfo:
Driver: "uhci_hcd" Driver Modules: "uhci_hcd"
But, lsmod does not list this module!? Why does usb works if there is no module uhci loaded?
Because driver is built in kernel?
People from other Linuxes suggest to first blacklist the offending kernel module and the load it manually at later stage, e.g. in boot.local. I just want to get the boot process fixed, it hangs at udevd....
Malte
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Malte Gell wrote:
But, lsmod does not list this module!? Why does usb works if there is no module uhci loaded?
The definitive check for if it is *loaded* in your kernel - check /sys/module/<modulename> Whether the module is compiled in or already loaded, it will appear there. As for debugging the problem... used to be you could boot to single-user and step through your bootup steps to find the problem... But.. how is that done on systemd? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Linda Walsh <suse@tlinx.org> [06-10-13 03:01]:
Malte Gell wrote:
But, lsmod does not list this module!? Why does usb works if there is no module uhci loaded?
The definitive check for if it is *loaded* in your kernel - check
/sys/module/<modulename>
Whether the module is compiled in or already loaded, it will appear there.
As for debugging the problem... used to be you could boot to single-user and step through your bootup steps to find the problem...
But.. how is that done on systemd?
And you cannot try? wtf, Linda. It still works as before, add a 1 or "S" to the init line or go to console and "init S"/"init 1" Although I find "init 1" seem to result in a restart of the graphical system and result in runlevel 5, "init S" leaves me with a root login for "system recovery", ie: runlevel 1. -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-10 15:54, Patrick Shanahan wrote:
* Linda Walsh <suse@tlinx.org> [06-10-13 03:01]:
As for debugging the problem... used to be you could boot to single-user and step through your bootup steps to find the problem...
But.. how is that done on systemd?
And you cannot try?
wtf, Linda.
It still works as before, add a 1 or "S" to the init line or go to console and "init S"/"init 1"
She refers to a different feature. It was a setting, activated I think by creating an empty file of a certain name, or by editing 'rc' and defining: DO_CONFIRM=yes Then the init process would prompt the admin on every single module whether to run or skip. This, AFAIK, is not available with systemd. And it works for any level, even 5, IIRC. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG1/e4ACgkQIvFNjefEBxpMagCgxD6uYADVaP9v0jFMpQhHS0MX uFUAnR/7l75kTr2GfNxDQ4hSUZGxsg7P =TZVo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Mon, 10 Jun 2013 18:25:18 +0200 "Carlos E. R." <robin.listas@telefonica.net> пишет:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-06-10 15:54, Patrick Shanahan wrote:
* Linda Walsh <suse@tlinx.org> [06-10-13 03:01]:
As for debugging the problem... used to be you could boot to single-user and step through your bootup steps to find the problem...
But.. how is that done on systemd?
And you cannot try?
wtf, Linda.
It still works as before, add a 1 or "S" to the init line or go to console and "init S"/"init 1"
She refers to a different feature. It was a setting, activated I think by creating an empty file of a certain name, or by editing 'rc' and defining:
DO_CONFIRM=yes
Then the init process would prompt the admin on every single module whether to run or skip. This, AFAIK, is not available with systemd.
systemd.confirm_spawn= Takes a boolean argument. If true asks for confirmation when spawning processes. Defaults to false. Not that I actually tested it, but it is in documentation. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG2DpwACgkQR6LMutpd94w0gACg0c9U0BiLZhfEGNjZ6KdHTMVt 8LUAoMfTnPAqK/toMWKRM9WU5xz0SxCm =uhJb -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-10 19:36, Andrey Borzenkov wrote:
В Mon, 10 Jun 2013 18:25:18 +0200 "Carlos E. R." <> пишет:
Then the init process would prompt the admin on every single module whether to run or skip. This, AFAIK, is not available with systemd.
systemd.confirm_spawn= Takes a boolean argument. If true asks for confirmation when spawning processes. Defaults to false.
Not that I actually tested it, but it is in documentation.
Nice... But not the same, I'd guess. In systemv it is a system global setting, in systemd I understand it only affects the service file you write it to, isn't? - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG2H5MACgkQIvFNjefEBxrIfgCg1njVKWD8dAEWZmspk/5SSnX+ WCoAniezo9/ngPgp3Op52S9YK8AGt4Lq =s500 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 10/06/13 14:48, Carlos E. R. escribió:
But not the same, I'd guess. In systemv it is a system global setting, in systemd I understand it only affects the service file you write it to, isn't?
Huh ? Andrey pointed you to a boot parameter, not to a unit file directive. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-10 21:00, Cristian Rodríguez wrote:
El 10/06/13 14:48, Carlos E. R. escribió:
But not the same, I'd guess. In systemv it is a system global setting, in systemd I understand it only affects the service file you write it to, isn't?
Huh ? Andrey pointed you to a boot parameter, not to a unit file directive.
How am I to know that? He did not give a link to the docu or man page. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG2JqEACgkQIvFNjefEBxpzBwCeNBZsAJuow+1BxXmXd8cHpXdZ hMwAnjpGxD8rWLQi5Q0PJ2yCx9RZ4Pmr =5niX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-10 21:18, Carlos E. R. wrote:
On 2013-06-10 21:00, Cristian Rodríguez wrote:
El 10/06/13 14:48, Carlos E. R. escribió:
But not the same, I'd guess. In systemv it is a system global setting, in systemd I understand it only affects the service file you write it to, isn't?
Huh ? Andrey pointed you to a boot parameter, not to a unit file directive.
How am I to know that?
He did not give a link to the docu or man page.
Visually, to one not in the know, a word, an equal sign, and another word, is the syntax used on service files. If it is a kernel boot parameter just say so. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG2JzAACgkQIvFNjefEBxqyUwCfeKANa0Ayc50ZczgTnWsV/+9h duMAmwdZfZgFdrhyJVONtgDrooHY647I =XWw/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 10/06/13 15:18, Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-06-10 21:00, Cristian Rodríguez wrote:
El 10/06/13 14:48, Carlos E. R. escribió:
But not the same, I'd guess. In systemv it is a system global setting, in systemd I understand it only affects the service file you write it to, isn't?
Huh ? Andrey pointed you to a boot parameter, not to a unit file directive.
How am I to know that?
fair enough, indeed, you would have to be familiar with naming conventions to infer that it was a boot parameter. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-10 22:06, Cristian Rodríguez wrote:
El 10/06/13 15:18, Carlos E. R. escribió:
How am I to know that?
fair enough, indeed, you would have to be familiar with naming conventions to infer that it was a boot parameter.
Thanks. It is indeed an interesting piece of information, one never knows when it might come handy. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG2eiMACgkQIvFNjefEBxrC6QCfT+ufPGd27uOBKf900zmLf83q iwgAnAs7biP4q3NZvulNStW2EORM1T9L =JyJf -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Mon, 10 Jun 2013 20:48:51 +0200 "Carlos E. R." <robin.listas@telefonica.net> пишет:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-06-10 19:36, Andrey Borzenkov wrote:
В Mon, 10 Jun 2013 18:25:18 +0200 "Carlos E. R." <> пишет:
Then the init process would prompt the admin on every single module whether to run or skip. This, AFAIK, is not available with systemd.
systemd.confirm_spawn= Takes a boolean argument. If true asks for confirmation when spawning processes. Defaults to false.
Not that I actually tested it, but it is in documentation.
Nice...
But not the same, I'd guess. In systemv it is a system global setting, in systemd I understand it only affects the service file you write it to, isn't?
No. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG2IoIACgkQR6LMutpd94wmXQCfSAekdrkJvb9e+PohMbNV8PqN t6sAn3KvYncckxebUiX38oOSvXvLktri =OhCt -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-06-10 15:54, Patrick Shanahan wrote:
* Linda Walsh <suse@tlinx.org> [06-10-13 03:01]:
But.. how is that done on systemd? And you cannot try? wtf, Linda. It still works as before, add a 1 or "S" to the init line or go to console and "init S"/"init 1"
No...
She refers to a different feature. DO_CONFIRM=yes Then the init process would prompt the admin on every single module whether to run or skip. This, AFAIK, is not available with systemd. And it works for any level, even 5, IIRC.
Close.. more basic. I mean I go into level 'S;, and I can go to the boot.d directory and run the scripts by hand, or semi-automated: (in boot.d or rcX.d): for i in S*;do ./"$i" start & read -p "next? [y]/n" -t 4 -n 1 ans [[ $ans == n ]] && break done --- can pause it at any time, or lean on CR to go full bore... As soon as a script fails I can redo it with bash -x SCRIPT... and see exactly what failed. I'll say it again: how is that done on systemd? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-11 03:07, Linda Walsh wrote:
Carlos E. R. wrote:
I'll say it again: how is that done on systemd?
The option Andrey and Cristian point out allows to single step the process, it seems. I understand that service files are calling programs which can be scripts - you can edit these. - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG2eiYACgkQIvFNjefEBxrBgACePFAVtVUkuJGhnKcq7GLaN889 PPQAn2tfJGEYP+3vdbJgagHa6fxyaFVL =6eqb -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-06-11 03:07, Linda Walsh wrote:
Carlos E. R. wrote:
I'll say it again: how is that done on systemd?
The option Andrey and Cristian point out allows to single step the process, it seems. I understand that service files are calling programs which can be scripts - you can edit these.
Single step at what prompt? At a shell prompt? where you can re-do the step with tracing on or run the daemon with different options. Editing when you are in single-user isn't always the easiest task. This presumes your editor and it's libs are all available. Many of the tasks it runs are binaries...so you may not be able to easily tell what it is calling. And then their's the ordering... Seeing the ordering was easy with scripts numbered in the order to be run... It would be like sysV only using 'make' in the /etc/rc.d or /etc/init.d directory and having no 'rcX.d' directories... all of the 'rcX.d' dirs are a visual for humans..... More than once I thought about just running make in /etc/rc.d for the fun of it... (on an appropriate makefile, of course!)... systemd has it's own makefile format but has no human oriented visual order dir like systemV provided. It may be that the numbered start scripts were required for ordering when sysV was created, but it was kept long past the point of necessity for booting -- since something like a make-script would have been more efficient and faster (potentially). Maybe systemd could have a sysV compatibility mode where it reads it's directions out of a numbered script dir for a "given target"... If only some thought had been given to easing this transition...rather than shoving it down people's throats...and telling them they have no choice... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 6/10/2013 9:37 PM, Linda Walsh wrote:
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-06-11 03:07, Linda Walsh wrote:
Carlos E. R. wrote:
I'll say it again: how is that done on systemd?
The option Andrey and Cristian point out allows to single step the process, it seems. I understand that service files are calling programs which can be scripts - you can edit these.
Single step at what prompt?
At a shell prompt? where you can re-do the step with tracing on or run the daemon with different options.
Editing when you are in single-user isn't always the easiest task.
This presumes your editor and it's libs are all available.
Many of the tasks it runs are binaries...so you may not be able to easily tell what it is calling.
And then their's the ordering... Seeing the ordering was easy with scripts numbered in the order to be run...
It would be like sysV only using 'make' in the /etc/rc.d or /etc/init.d directory and having no 'rcX.d' directories... all of the 'rcX.d' dirs are a visual for humans.....
More than once I thought about just running make in /etc/rc.d for the fun of it... (on an appropriate makefile, of course!)...
systemd has it's own makefile format but has no human oriented visual order dir like systemV provided. It may be that the numbered start scripts were required for ordering when sysV was created, but it was kept long past the point of necessity for booting -- since something like a make-script would have been more efficient and faster (potentially).
Maybe systemd could have a sysV compatibility mode where it reads it's directions out of a numbered script dir for a "given target"...
If only some thought had been given to easing this transition...rather than shoving it down people's throats...and telling them they have no choice...
Same thing on kernel, lxc/containers, cgroups, libvirt mail lists. Systemd totally breaks things, but it's going in anyways and maybe if your important enough maybe they'll eventually provide some sort of answer for your use case, not anything like as good as what you already had but something. But you suffer the breakage in the mean time. As smart as Poettering (and heck Rodriguez too) probably are, you know, *real* smart people can figure out how to do new work without alienating people into hating them who might otherwise be on their side, and *real* smart people can figure out how to do new work without catastrophically breaking everything else. *real* smart people don't require "my way or the highway". Otherwise, Linux itself wouldn't be a unix-like system that implements posix (at least as much as anything else does). It'd be it's own completely new and incompatible thing. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 11/06/13 03:00, Brian K. White escribió:
On 6/10/2013 9:37 PM, Linda Walsh wrote:
Maybe systemd could have a sysV compatibility mode where it reads it's directions out of a numbered script dir for a "given target"...
If only some thought had been given to easing this transition...rather than shoving it down people's throats...and telling them they have no choice..
Linda is once again talking non-sense and driving to conclusions based on that non-sense. All that she made is a big argument from ignorance, "I do not know how things work,therefore.."
Same thing on kernel,
What ? if the kernel fails to do something it is not a systemd problem! Amazingly enough, I have heard knowledgeable people making this argument too "systemd is a problem because it makes the kernel crash".. oh well..*facepalm* . -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
2013. június 11. 20:35 napon Cristian Rodríguez <crrodriguez@opensuse.org> írta:
Linda is once again talking non-sense and driving to conclusions based on that non-sense.
All that she made is a big argument from ignorance, "I do not know how things work,therefore.."
Same thing on kernel,
What ? if the kernel fails to do something it is not a systemd problem!
Amazingly enough, I have heard knowledgeable people making this argument too "systemd is a problem because it makes the kernel crash".. oh well..*facepalm*
Christian, I don't understand your argument. Linda says that: QUOTE: I mean I go into level 'S;, and I can go to the boot.d directory and run the scripts by hand, or semi-automated: (in boot.d or rcX.d): for i in S*;do ./"$i" start & read -p "next? [y]/n" -t 4 -n 1 ans [[ $ans == n ]] && break done --- can pause it at any time, or lean on CR to go full bore... As soon as a script fails I can redo it with bash -x SCRIPT... and see exactly what failed. QUOTE END The first question is if this is really doable with sysV. She also says that this type or equivalent booting/debugging is not available with systemd. The second question is if this is true. Which statement of Linda is not true? I am really curious since I never did booting like this in sysV. And I don't know systemd. Thanks, Istvan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-11 21:56, Istvan Gabor wrote:
2013. június 11. 20:35 napon Cristian Rodríguez <crrodriguez@opensuse.org> írta:
Linda is once again talking non-sense and driving to conclusions based on that non-sense.
I have to agree with Cristian this time. ...
Christian, I don't understand your argument. Linda says that:
...
The first question is if this is really doable with sysV.
Yes and no! For one thing, that method bypasses sysV, you are not diagnosing the boot process! It just starts all the scripts in a certain order. sysV does not start all scripts and not necessarily in that order (later days sysV ignored the symlink directory - this is documented). Thus you can not really find the cause of boot failure, which I assume be the reason for such drastic measures. What was said here iss that both systemv and systemd have an option you can type at boot to automatically single step the boot process, so that you can pinpoint which service fails, or skip one or more steps in order to proceed. This is the feature we talked about. Then Linda comes with a different method, home-grown, that of course only works if systemv is used in that system. A method that I would never dare to use, nor complain if it doesn't work anymore (if it ever worked!), because it is not systemv either! - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG4QW4ACgkQIvFNjefEBxom3gCgx8DYtgceeXqmVljyQbm4KuPY E1oAoLHHNAwoSBC/229IXbXrURc4FTxd =2Cu0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Sun, 09 Jun 2013 17:50:40 +0200 Malte Gell <malte.gell@gmail.com> пишет:
While booting the system again several times I encountered a strange error message while booting:
systemd-udevd[239]: worker [268] /devices/pci0000:00/0000:00:1d.2/usb7/7-0:1.0 timeout; kill it
Please paste full dmesg output to http://susepaste.org/. This single line is not enough to guess.
There is the string "usb7" within the message, but I did *not* have any USB devices connected to the system.
How can I find out what PCI device thi is?
Below is the output of lspci. System is plain openSUSE 12.3 with current updates.
Thanx Malte
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07) 00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port (rev 07) 00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) 00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03) 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03) 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) 00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) 00:1d.3 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03) 00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03) 01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce G210M] (rev a2) 01:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1) 02:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5784M Gigabit Ethernet PCIe (rev 10) 03:00.0 Network controller: Intel Corporation Centrino Wireless-N 1000 [Condor Peak]
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 09.06.2013 19:01, schrieb Andrey Borzenkov:
В Sun, 09 Jun 2013 17:50:40 +0200 Malte Gell <malte.gell@gmail.com> пишет:
While booting the system again several times I encountered a strange error message while booting:
systemd-udevd[239]: worker [268] /devices/pci0000:00/0000:00:1d.2/usb7/7-0:1.0 timeout; kill it
Please paste full dmesg output to http://susepaste.org/. This single line is not enough to guess.
Ok, there is the full output of dmesg after a clean boot. There must be something not fully working, because booting takes too much time, right before the udevd message appears the system hangs for endless seconds. http://susepaste.org/70817478 Thanx for helping debugging. Malte -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 09.06.2013 19:01, schrieb Andrey Borzenkov:
В Sun, 09 Jun 2013 17:50:40 +0200 Malte Gell <malte.gell@gmail.com> пишет:
While booting the system again several times I encountered a strange error message while booting:
systemd-udevd[239]: worker [268] /devices/pci0000:00/0000:00:1d.2/usb7/7-0:1.0 timeout; kill it
Please paste full dmesg output to http://susepaste.org/. This single line is not enough to guess.
And if needed, the output of lspci -v: http://susepaste.org/61977567 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Monday, June 10, 2013 06:15:56 PM Malte Gell wrote:
Am 09.06.2013 19:01, schrieb Andrey Borzenkov:
В Sun, 09 Jun 2013 17:50:40 +0200
Malte Gell <malte.gell@gmail.com> пишет:
While booting the system again several times I encountered a strange error message while booting:
systemd-udevd[239]: worker [268] /devices/pci0000:00/0000:00:1d.2/usb7/7-0:1.0 timeout; kill it
Please paste full dmesg output to http://susepaste.org/. This single line is not enough to guess.
And if needed, the output of lspci -v:
Did you ever connect a Bluetooth device (e.g.: pointer mouse,...) and forget to disconnect it before shutdown? If you did so, go connect it again and disconnect it before shutdown your system. When you start the system again it should be solved. It looks like the system have not flushed or purged that old device connection. My 0.001 cent Best regards, Ricardo Chung Member openSUSE Projects -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 10.06.2013 19:29, schrieb Ricardo Chung:
Did you ever connect a Bluetooth device (e.g.: pointer mouse,...) and forget to disconnect it before shutdown?
The machine has BT, but I have not connected any BT device for many weeks... Malte -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Mon, 10 Jun 2013 18:15:56 +0200 Malte Gell <malte.gell@gmail.com> пишет:
Am 09.06.2013 19:01, schrieb Andrey Borzenkov:
В Sun, 09 Jun 2013 17:50:40 +0200 Malte Gell <malte.gell@gmail.com> пишет:
While booting the system again several times I encountered a strange error message while booting:
systemd-udevd[239]: worker [268] /devices/pci0000:00/0000:00:1d.2/usb7/7-0:1.0 timeout; kill it
Please paste full dmesg output to http://susepaste.org/. This single line is not enough to guess.
And if needed, the output of lspci -v:
Well ... first time you said it was usb5 (0000:00:1d.0), now it is usb7 (0000:00:1d.2). I would guess hardware issue with USB controller. Just recently I had to help my neighbor to fix malfunctioning USB - I had to disable EHCI to make it work. Otherwise nothing was found on this port. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 11.06.2013 17:13, schrieb Andrey Borzenkov:
Well ... first time you said it was usb5 (0000:00:1d.0), now it is usb7 (0000:00:1d.2). I would guess hardware issue with USB controller. Just recently I had to help my neighbor to fix malfunctioning USB - I had to disable EHCI to make it work. Otherwise nothing was found on this port.
Isn´t EHCI is the driver for USB 2.0? If I disable EHCI (which is compiled into the kernel), will I then lose USB 2.0? Malte -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 11/06/13 11:13, Andrey Borzenkov escribió:
В Mon, 10 Jun 2013 18:15:56 +0200 Malte Gell <malte.gell@gmail.com> пишет:
Am 09.06.2013 19:01, schrieb Andrey Borzenkov:
В Sun, 09 Jun 2013 17:50:40 +0200 Malte Gell <malte.gell@gmail.com> пишет:
While booting the system again several times I encountered a strange error message while booting:
systemd-udevd[239]: worker [268] /devices/pci0000:00/0000:00:1d.2/usb7/7-0:1.0 timeout; kill it
Please paste full dmesg output to http://susepaste.org/. This single line is not enough to guess.
And if needed, the output of lspci -v:
Well ... first time you said it was usb5 (0000:00:1d.0), now it is usb7 (0000:00:1d.2). I would guess hardware issue with USB controller. Just recently I had to help my neighbor to fix malfunctioning USB - I had to disable EHCI to make it work. Otherwise nothing was found on this port.
I had a very similar issue to this, in my workstation, suddenly usb ports hanged the whole machine, it was working fine the days and weeks before.. I though there was a bug in this particular version of udev, or while testing other stuff I had created a mess.. nope, upgraded, no luck, booted a live CD, same problem, disabled the motherboard USB controller, that worked but had no early BIOS USB and only 4 remaining USB ports in a separate controller.. Weeks after, I re-enabled the controller in the BIOS and ta-dah! it was working again normally and continues to do so. This does not make any sense unless there is (or was) a problem with the power supply levels or something similar.. :-| -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-11 19:28, Cristian Rodríguez wrote:
This does not make any sense unless there is (or was) a problem with the power supply levels or something similar.. :-|
A teacher of mine would say that it was the undeterministic character of software (often applied to Windows) :-p - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG4QfkACgkQIvFNjefEBxrfsACbBZwI0Ir6U/U7N6I1up2njExV WPAAniVtUJE9XKECSiAQ7ts9BhPmdoLa =Gb0D -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 12/06/13 05:40, Carlos E. R. escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-06-11 19:28, Cristian Rodríguez wrote:
This does not make any sense unless there is (or was) a problem with the power supply levels or something similar.. :-|
A teacher of mine would say that it was the undeterministic character of software (often applied to Windows) :-p
I suspect software was not to blame, I even booted a different openSUSE version than the one I had installed, checked if I changed any relevant package in the installed system..etc.. oh and did I mention it worked fine one reboot before ? the usb controller just spewed errors that "magically" solved :-D -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-06-12 19:11, Cristian Rodríguez wrote:
El 12/06/13 05:40, Carlos E. R. escribió:
A teacher of mine would say that it was the undeterministic character of software (often applied to Windows) :-p
I suspect software was not to blame, I even booted a different openSUSE version than the one I had installed, checked if I changed any relevant package in the installed system..etc.. oh and did I mention it worked fine one reboot before ? the usb controller just spewed errors that "magically" solved :-D
Then the «undeterministic character of computers» :-p - -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlG4wRYACgkQtTMYHG2NR9UCIACfTiJyldf4lk3LFt7snlLYCtc5 70UAn0+2T31NoAfLVumvOw2LHXNF0vII =5/F0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----Original Message----- From: Carlos E. R. <robin.listas@telefonica.net> To: oS-en <opensuse@opensuse.org> Subject: Re: [opensuse] OS 12.3 udev hangs while booting Date: Wed, 12 Jun 2013 20:42:30 +0200 On 2013-06-12 19:11, Cristian Rodríguez wrote:
El 12/06/13 05:40, Carlos E. R. escribió:
A teacher of mine would say that it was the undeterministic character of software (often applied to Windows) :-p
I suspect software was not to blame, I even booted a different openSUSE version than the one I had installed, checked if I changed any relevant package in the installed system..etc.. oh and did I mention it worked fine one reboot before ? the usb controller just spewed errors that "magically" solved :-D
Then the «undeterministic character of computers» :-p -----Original Message----- I presume he meant: "the undeterministic character of developpers" ;-)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I do not know if this is related, but I have a very similar, if not the same problem. Specifically, if I have any of my USB peripherals attached to my laptop, then booting the laptop will likely freeze at the udev. This is a very hard freeze, with no responsiveness of any devices. Removing all usb devices seems to bring the probability of encountering an issue much lower. These does appear to be a probabilistic sort of problem on my end, though, so perhaps this is not the same thing. I do not know how to get the dmesg and system logs from the failed boot though, so if someone has a pointer to that documentation somewhere, I'm happy to post the results of such a boot. -- Aaron W. Hsu | arcfide@sacrideo.us | http://www.sacrideo.us לֵ֤ב חֲכָמִים֙ בְּבֵ֣ית אֵ֔בֶל וְלֵ֥ב כְּסִילִ֖ים בְּבֵ֥ית שִׂמְחָֽה׃
participants (11)
-
Aaron W. Hsu -
Andrey Borzenkov -
Brian K. White -
Carlos E. R. -
Cristian Rodríguez -
Hans Witvliet -
Istvan Gabor -
Linda Walsh -
Malte Gell -
Patrick Shanahan -
Ricardo Chung