I have a Samsung laptop with Via electronics. The video card is a Via Chrome 9. It works in X with the Openchrome driver, but not with the kernel's framebuffer console driver.

I first noticed this when I was installing NuTyX. This is a binary distro with a stock kernel and an initrd, but based on LFS. When it booted, the screen went crazy. First it blacked out, and then it cycled slowly through all the primary colours. The only way to stop it was to reboot.

Tnut suggested blacklisting the fb module and not using the initrd at all. So I rebuilt the kernel to boot directly to the hard drive and all was well.

I've just built LFS on the same machine. That has simple init scripts that don't use a framebuffer console, so I didn't expect any trouble booting it. But when it got to running the udev startup script, the screen played up in exactly the same way.

The logs showed that the init script sequence had completed normally. Only the display had failed. By putting a few extra echoes into the udev script, I found that it was the command udevadm settle that was causing the mayhem. And when I blacklisted fb, the problem disappeared.

What I would like to know is how and why this command causes my video card to misbehave. I couldn't find anything relevant on Google.

Especially in the booting up phase on your LFS type init scripts, timing can be an issue. If you want to double check that <udevadm settle> is causing mayhem, un-blacklist fb, check the problem reappears, and then comment out 'udevadm settle.' I imagine fb is causing the problem.

I tried un-blacklisting viafb and then giving the udevadm settle command by hand. Nothing happened. So your guess about it being an initialisation issue seems to be right.

In simple terms, what does this command actually do and why is it in the udev initialisation script? I imagine it must play some necessary role, so I'm cautious about commenting it out. I'd feel happier about putting in something extra like a brief sleep if I knew what I was doing!

I don't find the udevadm man page very informative; it assumes more knowledge of how hardware works than I have. And I still don't understand how an event watchdog interacts with a video card. Surely video cards are passive recipients of instructions. How can they generate events?

From my read of the udevadm man page, udevadm settle seems to act for /dev/ nodes much the way sync acts for disks. Blacklisting viafb was good, if it's causing issues. Do you still have a problem?

The problem with issuing udevadm settle is that as the video is continually updating udevadm may continue running. That would be issued prior to some command which required a zero queue length, like if they were changing the video dev node prior to starting X, or doing something like that. I am not aware of what they're up to. I would remind you of Rule #1 of maintenance: :-).

At the moment, I don't need this module. But I was thinking ahead. There's a webcam on this laptop and I know it works in Linux because I eventually got it to work in Dragora. It was a huge effort because most camera software didn't work on it, but I found a program (guvcview) that would and built it by hand. I'd like to make it work in LFS too. As far as I can remember, the video modules are dependent on viafb.

Your No.1 rule is why I didn't want to just comment out udevadm settle as you first suggested. I'm sure it's in there to do something essential. I'd just like to know what.

What I have at the moment is a workaround. What I'd really like to have is an explanation.

Grok the script and see what it's doing. The lines before that 'udevadm settle' and directly after it will tell you what they're up[ to. LFS bootscripts are simple, efficient, but not terribly sophisticated. I feel pretty sure the sky fall in if you comment out udevadm settle, but maybe it was prompting the loading of viafb?

This is what happens after the udev daemon is launched:

/sbin/udevadm trigger --action=add --type=subsystems
/sbin/udevadm trigger --action=add --type=devices
/sbin/udevadm trigger --action=change --type=devices

Then comes the settle command, presumably to clear whatever has been set in motion. Though it looks to me as if the daemon has merely been told what sort of events to look out for in future.

I tried to log the kernel module state just before and after the settle command, to see if viafb does indeed get loaded, but of course the hard drive at this stage is mounted read-only, so no luck there!

Ok. So the ultimate answer to the ultimate question eludes us. Have you got a problem still with viafb blacklisted? If not, Rule #1 applies.

We've been chasing a red herring! It has nothing to do with udevadm at all. The culprit is the kernel. Logs of failed boots show that viafb, when available, is loaded at about the same time that udevd starts, followed by fbcon.

I just tested with the udevadm settle command commented out but with viafb available. In this case, the udev script runs much faster (no wait for settling) and about three other messages have time to appear before the console crashes. I don't have time to check the logs now, but I bet they show viafb loading followed by fbcon.

Tomorrow I'll try blacklisting fbcon rather than viafb and see what happens. If it doesn't crash, then we've found our culprit. Though I still don't understand why the kernel loads it, as I didn't ask for a framebuffer console on the command line.

Like I said before, I might need viafb in the future but I can certainly live without fbcon.

btw that's probably why I had no trouble when I loaded viafb by hand outside the boot sequence.

Try running this in an xterm That will search for each in modules.dep. The format is module: dependency other_dependency etc.

So if you load the module, it checks this and loads all the dependencies first. It may give an idea if viafb needs fbcon, or vice versa.

1 members found this post helpful.

It turns out that fbcon was built-in so it couldn't be blacklisted. I rebuilt the kernel with fbcon as a module (for some reason you're not allowed to omit it completely). Then I un-blacklisted viafb and blacklisted fbcon instead. Hurrah! Boot was normal!

So, to sum up, it was fbcon that was causing all the trouble and it had nothing to do with either viafb or udevadm. Which means that this post now has a completely irrelevant title. I shall mark it as solved, but unless Jeremy changes the title of the post, the solution won't easily be found by anyone.

As far as inter-module dependency is concerned, I checked with grep as you suggested and there is no direct dependence of either module on the other. But there seems to be a logical dependency, in that kernel launches fbcon automatically after the framebuffer driver is loaded -- probably after any framebuffer driver is loaded.

Glad you sorted it. Time to promote yourself and change the sigfile:-)