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?

I have read
http://www.linuxquestions.org/questi...%2Fudevtrigger

and

http://www.linuxquestions.org/questi...lation-645586/
Which are very helpful, but before I try again (which requires systemrescuecd so can be time consuming) I want to ask whether there is some other issue?

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
which in my layman's thanking looks a bit like the hang I have in slackware, starting with
and later on
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:
dmesg result:

triggering udev events: /sbin/udevtrigger --retry-failed,

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!

Is this relevant?
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)

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.

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.

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

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.

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!

Thanks T3slider, but I have seen this before, probably when checking out

http://www.linuxquestions.org/questi...6/#post3169143

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

Result of lspci:
Result of lsmod: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.

The following is slightly worrying.

http://www.coreboot.org/News#2007.2F..._now_supported

http://www.coreboot.org/MSI_MS-6178_Build_Tutorial

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.

Many thanks _ Phil

I just remembered something I meant to mention before. Why don't you try to increase the verbosity of the udev events and then recheck your logs?

Try changing /etc/udev/udev.conf's udev_log to "info" or even "debug".

Also, in /etc/rc.d/rc.udev, try modifying this line
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.

Of the extemely "verbose" output following the suggested changes, I identified the following:

Working on this, I find http://ubuntuforums.org/showthread.php?t=286827

http://random.openminds.be/2007/02/1...obe-not-found/

and

http://www.linuxquestions.org/questi...aviour-492115/

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.

I have posted the files at http://cid-110ecf7e446877f7.skydrive...se.aspx/Public (they are too long to post here)

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.

-Phil

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.

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.

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:

I'd like to go straight for the BIOS- kill or cure!

Thanks for the safer suggestions:

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.

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

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.

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.

Thanks for your comments there, I've tried the quickboot...

Have a few questions relating to BIOS identification. This is getting into general hardware rather than slackware, should I stop here and start afresh in the appropriate forum?

The slow performance issue is only mentioned in passing in this thread and explicit in a previous one but I really should have made it clear, as you say.

BIOS is 1.5. There is a credible amount of discussion on the web about trouble (under M$) with outdated BIOS. I now have a bootable floppy using FDOEM144 and copied the essential BIOS files ie flash utility & new BIOS to it. I now think this is the most likely area to try.

Running the utility, it gave me "Flash type Intel E82802AB /3.3v(4mB) which I don't recognize from anywhere else. Asked for file name to program- I entered the name of the new BIOS, reply "the program file's part number does not match with your system". I now know that I have to disable cache in BIOS & short across the lock terminals with jumper, adjacent to BIOS on mainboard. However what file name should I have entered? If its the name of my existing bios, that is on the first screen I see as A617801 V1.5MR 060300, but it has to be exactly the right format.

The long reference at the bottom of my initial screen is 63-10B1-001169-00101111-071595-WHITNEY-1WHITNEY-H, I know that's essential for identification although don't know the full significance.

Big big question.... all the BIOS material on the MSI page you referred me to is Award and my screen shows AMI. I am confident I have stated the mainboard name correctly, although it has ver 1.1 stamped on it and that isn't referred to anywhere. Web research indicated some similarity with MS6183 and that has mostly AMI, indeed a v1.7, but a few Award BIOS options. The date on v1.5 there (7jan00) is closer to the date on my screen (3feb00) than was the case for the Award (30nov99) although not identical, but maybe that's too ambiguous to be of any use.

Maybe my mainboard has the wrong bios? Close enough to boot but with resultant bugs. I don't have the experience to guess, maybe either bios will work. With the right "file name to program" I could get the latest Award BIOS 2.1 in there.

Maybe ver1.1 required the AMI bios, in which case I need 1.7.

I'll see what I can get from forums, MSI themselves, etc. Unlike LQ, most of these sources take a while to respond.

Meanwhile I'm very unlikely to try flashing the BIOS until I have a better idea, especially as, AFAICT, I have no removable chip (or if I did, no spare chip) as a backup.

Thanks. As I said, I'm probably well off topic now so don't mind posting afresh.

The part name should be on the mainboard somewhere, but it may not be easily visible. It should be obvious which of the two mainboards you have, though. If nothing else you can measure the dimensions because they are different sizes (not to mention they look a lot different). They have different audio chipsets as well.
MS-6183

If your mainboard does indeed have the wrong BIOS, then that could account for your problems. It doesn't sound like you have a lot to lose here. A computer this old is easy to get from a Library's/Universitiy's mass upgrade leftovers.

I've moved this to http://www.linuxquestions.org/questi...5/#post3203987 which is appropriate for it.

I'd like to thank you once again for your help on this, it's made me use the logs to better advantage and I've learned all sorts of things along the way, like mounting and unmounting in live distros. I'll post again here with the conclusion.

Regards -Phil

No conclusion yet but
1 Able to reduce boot time to normal by making rc.udev & other files non executable, comments to rc.S & rc.M, so far no damage except no mouse but can probably enable that in rc.modules
but
2 That's not the problem, boot was slow because I think HDD not addressed properly? Not a boot process hanging performance after all. Performance is very slow even after reduced boot.

Knoppix is fine until I try to load it on the HDD either directly or through enlarged swapfile, then it hangs. But HDD reads and writes fine. Probably bios?

Check the logs again. Does it hang when booted live after you mount a hard drive partition?

I will check the logs but regret I am unsure... booting live has only hung once in (numerous) occasions, and mounting hd partitions, then reading/writing, has been successful. Shall I check the log after a normal Knoppix boot?

I have a theory that the source of the error is a configuration file amended automatically from a previous session; with the result that only the first session (or two) with any new distro is successful. Knoppix or any other live distro is the same as the first boot with a new distro, therefore...