Hang on triggering udev events- is there a buildup of events?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hang on triggering udev events- is there a buildup of events?
My 1999 microstar + pIII has a history of slow progress after a particular point in the boot process and I am questioning whether there is an "event" that is blocking my system?
Full details of what I believe to be a related problem with this computer on another distro are on http://www.linuxquestions.org/questi...rboard-640144/
All seemed OK until I needed an upgrade to experimental for particular application, then problem returned. I have since changed the power supply, no difference.
I am raising this as a separate issue from the excellent thread quoted above because, firstly, the problem with Debian was a hang beginning with
Code:
waiting for /dev to become fully populated...
which in my layman's thanking looks a bit like the hang I have in slackware, starting with
and secondly, the first second and third boots on my new slackware 12.1 installation were fine. I had a resolution issue (noted on earlier thread, I am thinking on it) and modified field depth on xorg.config from 24 to 16 ( a quick fix that has worked for me before, and did in this case).
Straight after that, I experienced the "triggering udev events: /sbin/udevtrigger" delay and the system has never returned to normal speed.
I don't rule out hardware trouble, but ultimatebootcd says that all is well, and anyway the first few successful boots suggest a software problem.
Is there a list of "udev events" that I can either post here or perhaps clear? I can experiment without risk as all data is on another partition and it isn't my main computer. Thank you.
Having tried change to generic kernel in http://www.linuxquestions.org/questi...d-disk-650281/ problem not solved.
I'm hanging in there because there's never a problem using a live cd or loading a distro, m$ used to work, and the hdd in the comp at present was tried & tested on a reliable old mainboard.
More on udev: I've tried udevadm settle --timeout=10 and udevadm control --stop_events_queue, but that didn't help (& no doubt reverts back on next reboot unless configuration file is changed?) The first delay occurred at "Triggering udev events" straight after a xorg.config change, I'm sure something is happening in udev that keeps my processor permanently busy (when in slack, ksysguard shows cpu>95%)
Recalling that I had this on Debian prior to HDD change, and again recently with the present HDD, have to question whether, hardware fault or not, this mainboard is viable for a modern OS?
Have now loaded using huge.s on a spare partition with ext2 file system, and result is the same as generic kernel+ ext3. Observations:
Checking ps -e there were numerous instances of artsd running at one time, later a knotify message with option to close it down, which I did, still very slow.
ps result after multiple artsd problem ended:
That is just loading all the Kernel modules that were not in use at the start (due to the device not being initialized yet) so it can take a while depending on the way the machine is set up. (i believe that is what it is if i am not please correct me)
I don't know exactly- I thought it was the same as populating /dev with the hardware as in the the Debian bootup. A duff HDD is the obvious culprit, but not here as this HDD works in another machine, so either there is a module working in a permanent loop and this continues even when the boot is concluded, CPU at >85% all the time (has to be a specific incompatibility with this mainboard as older ones have worked fine for me...)
or the mainboard is itself defective and the tool to which your final para refers is appropriate!
If you notice extremely long wait times when formatting partitions in the
installer, and you're installing on a Thinkpad that has a SATA drive, it's
possible that the wrong driver is being used, which disables DMA on the drive
(and could happen on other machines). A bit more detail about it is here: http://www.thinkwiki.org/wiki/Proble...stem_hard_disk
Try passing "hda=noprobe" to the kernel when booting the installer, and it
should use the correct libata driver.
It looks partially relevant, but I can't be sure. Do you happen to know if your drive is SATA or PATA? (It is currently being recognized as PATA)
is dma=1. However, with nothing to lose, I tried Alien's instructions. Booting from the cd, with
Code:
hugesmp.s hda=noprobe
produced a strange result- none of my partitions were loaded on /dev, either as hda1,2 etc or sda1,sda2... I went through /dev and checked whether my partitions had appeared as anything else, they didn't.
Seeing as how dma was on, that is not problem. The problem is your drive is taking too long to be detected properly. You may have to specify the correct module to use or blacklist a particular module.
Quote:
Originally Posted by sonichedgehog
I have also tried appending hda-noprobe in lilo and making the suggested changes in lilo.conf & fstab. Not accepted in lilo as sda doesn't exist.
Right. You can't run lilo with those changes unless sda corresponds to the correct drive. You would have to boot with hda=noprobe on the install cd, mount your root partition, cd into, chroot, edit lilo (change the hda's to sda's and add the noprobe option), and then run lilo. You would have to do a similar procedure to change it back.
I think your drive really is PATA, though, so you shouldn't need to do this.
That is just loading all the Kernel modules that were not in use at the start (due to the device not being initialized yet) so it can take a while depending on the way the machine is set up. (i believe that is what it is if i am not please correct me)
It sounds like you need to specify the module that needs to be loaded (in rc.modules*) so probing isn't necessary for that hardware. Turning off probing might be needed as well, but it looks like it won't work unless you tell the kernel what you need. The big thing is to make sure that the right module is actually used. Hopefully it isn't something odd that isn't already built for the kernel (that would mean you would have to build a custom kernel).
The problem is your drive is taking too long to be detected properly. You may have to specify the correct module to use or blacklist a particular module.
OK! I like the idea of turning off the module that's hanging the boot up & killing performance & can envisage a solution that involves disabling some of the detection by commenting lines out, and re-enabling if & when there has been a hardware change.
What should I be looking for in rc.modules? I expect to have to try suppressing a number of modules one at a time and noting the effect, but if I went in right now it would be almost random.
Quote:
Hopefully it isn't something odd that isn't already built for the kernel (that would mean you would have to build a custom kernel).
Could be worthwhile, this may be anecdotal but I know of several comps like mine- which were excellent with W98- that were discarded due to software issues. Well, if it comes to building a custom kernel, I'll try anything once but there might be a month before I post again. I know there's lost of material out there and a recommendation for a beginner will be most helpful!
as suggested. There was a lot of investigation into markluocanada's HDD, but I think, as shadowsnipes suggests, noting that I have DMA, I don't need to look further into this.
The first thing you need to do is to properly identify your hardware. In particular, since we suspect your hard disk is taking a while to probe, we are interested in your disc controller(s).
Show us the output of
Code:
lspci -v
. Also, if you dual boot with Windows you can check under its hardware interface. Finally, it would be a good idea to see if there is any wiki or forum for your particular machine. Try searching around for it. At a minimum there should be a site that details the specs of your machine (ie. the manufacturer's site). There might be other good information there as well.
After the hardware is identified then you will need to look through the kernel docs to see how to support it. You could grep the docs for your device or make menuconfig and search through the disc controller options (there are help files you can read as well in there). You could also check which modules are loaded after your system is booted up.
Show us the output of
Code:
lsmod
. One of those might be the one that we need to specify. Once the module(s) that is needed is identified then you just add a modprobe line for it in rc.modules*. If we find there is a conflicting module then we will need to blacklist it.
Meanwhile, I have tried some further experiments & research.
The comp is Tiny 1999 with Excelstor J240 40gB HDD salvaged from a later Tiny (2002). Following Tiny's demise there is AFAICT nothing of technical value on the net relating to Tiny, so I have concentrated on the mainboard. I had access to the manual (typed MS6178 on search engine) before starting this thread, it is useful for hardware building but I didn't find anything relevant to the current problem.
If necessary I could get a M$ ghost image that I previously saved back on the comp, then reinstall slack as dual boot, but haven't done so yet. (I only dual boot with M$ on my latest comp because vista was provided and it's foolish to lose it)
The /udev delay has, according to several sources, been associated with usb devices. I tried removing the usb2.0 card (the mainboard has 2 built in usb1's) and the next boot was fast, into a fully effective system. On reboot, however, the system hung at /udev. Replacing the card made no difference.
I then did the same with the modem card- and the result was identical. The next boot was fast. I used the os for a while and am satisfied that it is fully effective if the boot has proceeded normally. The following boot was slow, and I could not "provoke" a normal boot by fiddling with bits of hardware.
So, is the udev daemon working effectively only on the first occasion after a hardware change? If so it is not consistent.
In summary, it is stated that Linux had never worked with the MS 6178 mainboard, and the above provides a bios flash utility to overcome this.
I would question the indication that Linux and the MS6178 with original bios are incompatible- my system is almost working. I have checked LQ for coreboot discussion & found nothing directly relevant to this case.
I have the source from svn, and the howto insists that the bios saviour is essential- I can see why. No serious risk here as this is an ex-work mainboard of little value, but the procedure seems troublesome and I think flawed- I am sure you need your linux os up and running in order to use the software. But I have probably missed something.
Maybe your suggestion of suppressing/enabling relevant modules will work? I don't know where to go with the checking of pci & module info against kernel docs, would welcome further guidance.
Adding --verbose to the udevtrigger (and the other verbosity change) might help you really determine where the sticking point is.
You could also shorten the timeout dramatically, but you may have to manually load the modules that don't "settle". You already have a list of modules that get loaded, so any that are missing probably need to be manually loaded if the timeout is not long enough.
However, the suggested changes did not work. The message related to PCIC & PCMCIA disappeared but otherwise no difference. So, I restored the affected files.
From the messages log, I can see that, straight after a modprobe that detected my mainboard, the hang began and went to my new timeout (set at 30 seconds).
AFter that, there is a message:
Jun 30 07:38:38 localhost udevd-event[2185]: run_program: '/sbin/modprobe' (stderr) 'FATAL: Module pci:v00008086d00002416sv00008086sd00002416bc07sc03i00 not found.'
That, I regret, is as far as I can go, and I have to ask for some help in interpreting the rest. I can see that the processor is locked into a long operation, but don't know how to address it.
If you have time (and I realize this is becoming a messy, time consuming task- thank you!) please take a look at the messages 30 june log (my comments in red with <<>>). 29 june shows result of pcmcia changes, now reversed. The other files are there is case they prove useful.
However, the suggested changes did not work. The message related to PCIC & PCMCIA disappeared but otherwise no difference. So, I restored the affected files.
Are you using a Cardbus or other type of PCMCI device? If this isn't a laptop then the answer is likely to be no, so you can safely just take away the execute perms on /etc/rc.d/rc.pcmcia.
Quote:
Originally Posted by sonichedgehog
From the messages log, I can see that, straight after a modprobe that detected my mainboard, the hang began and went to my new timeout (set at 30 seconds).
Ah, now we are finding what we were looking for! This is good news, but it is bad news that the problem is with your mainboard. I haven't looked at all the files (much less really read through them), but it sounds like this is the real problem area as you mentioned.
Code:
Jun 30 07:36:49 localhost udevd-event[2194]: run_program: '/sbin/modprobe dmi:bvnAmericanMegatrendsInc.:bvr62710:bd05/20/99:svnMicro-StarInc.:pnMS-6178:pvr1.0:rvnMicro-StarInc.:rnMS-6178:rvr1.0:cvnINTELString:ct3:cvr0000000:'
Jun 30 07:36:49 localhost udevd-event[2196]: run_program: '/sbin/modprobe input:b0017v0001p0001e0100-e0,1,2,k110,111,112,r0,1,amlsfw'
Jun 30 07:37:20 localhost udevsettle[2179]: udevsettle: timeout waiting for queue
If you take away the verbose and debug options (leaving the timeout at 30) does your system boot faster or slower than before (with default timeout of 120)? Use a stopwatch. If your system actually takes longer to boot with a shorter timeout try increasing the timeout to 60 and then compare (again versus timeout of 120).
Since the problem, as you suspected previously, appears to be your mainboard you can try a few things. First, try using the non-smp huge kernel. Second, poke around your BIOS and see if there is anything useful you can change. You might even need to update your BIOS (version 2.1 looks like the latest). Here is the Micro-Star page for your MS-6178. You can find the BIOS updates there.
I wouldn't worry about the coreboot pages you were looking at earlier, by the way. Just look at the description of the project:
Quote:
Originally Posted by Coreboot homepage
coreboot (formerly known as LinuxBIOS) is a Free Software project aimed at replacing the proprietary BIOS (firmware) you can find in most of today's computers.
I'd like to go straight for the BIOS- kill or cure!
Thanks for the safer suggestions:
Quote:
...you can safely just take away the execute perms on /etc/rc.d/rc.pcmcia.
No, not a laptop. I suspected it made no difference either way, but I restored the execute perms to ensure that I hadn't introduced a new problem before posting the log on my webspace.
Quote:
try using the non-smp huge kernel. Second, poke around your BIOS and see if there is anything useful you can change.
I have huge.s kernel (is that the correct one to try?) on another partition, I haven't examined the logs but it is behaving exactly the same. I have also looked at the BIOS and fiddled around (some time ago). There's not much that can be changed, compared to, for example, my trusty MS-5168. No luck there.
On the timing, it's not just the long boot- the system is "preoccupied" all the time.
I'll take your advice and leave corebios alone so...
Thanks for the Microstar link. I didn't see it previously because I went straight to the manual. Even at first glance, it all looks very microsoft, so -am I right? - I should swallow my pride, restore my XP image for now, and use the .zip's and .exe's in the traditional way.
Anyway, I'm very grateful for all your help. I'm sensing that the end of the quest is near- although whether through a successful outcome or a trashed bios remains to be seen!
I have huge.s kernel (is that the correct one to try?) on another partition, I haven't examined the logs but it is behaving exactly the same. I have also looked at the BIOS and fiddled around (some time ago). There's not much that can be changed, compared to, for example, my trusty MS-5168. No luck there.
I was talking about using /boot/vmlinuz-huge-* instead of vmlinuz-huge-smp-* or the generic kernel (for now). According to the logs you posted it looked like you were still using the smp kernel and it complained. Usually this does not matter, but with some older machines it can make a big difference, so I thought it was worth a quick check.
Quote:
Originally Posted by sonichedgehog
On the timing, it's not just the long boot- the system is "preoccupied" all the time.
Good to know that. I don't think you mentioned this before. That could mean that the hardware isn't just slow to detect, but that it never got detected/loaded properly.
Quote:
Originally Posted by sonichedgehog
Thanks for the Microstar link. I didn't see it previously because I went straight to the manual. Even at first glance, it all looks very microsoft, so -am I right? - I should swallow my pride, restore my XP image for now, and use the .zip's and .exe's in the traditional way.
Anyway, I'm very grateful for all your help. I'm sensing that the end of the quest is near- although whether through a successful outcome or a trashed bios remains to be seen!
Do you even need a BIOS update? What version do you have? As I said in my last post version 2.1 is the latest. And, no you should not need anything M$ to use a BIOS update. Most of the time you just extract the zip files into a formatted bootable floppy and then boot into it. Read any readme.txt's first. You should be able to get the boot floppy set up just fine in Linux.
It might also be worth a shot to try the Online customer support that MSI has. They might be of no help, but then again it shouldn't take long to find out, and they might be able to at least point you in the right direction.
Has any *nix OS worked properly on this machine recently? If not, you may want to try a LiveCD (or a couple) with good hardware detection like Knoppix or something similar. If it appears to work fine then take a look at its logs and the modules that get loaded.
Oh, and if your BIOS has a QuickBoot, try turning it off.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
