It's possibly a bug. Based on your description, it is more likely a hardware problem. The delay occurs between the probe of your second pciide bus (pciide1) and finding the hard drive (wd0) on that bus.

Question: Was this delay present when you booted the GENERIC kernel, or does it appear only when use use the GENERIC.MP kernel?

Question: Did this delay happen with the RAMDISK (/bsd.rd) kernel, too?

If it always happens, then it is most likely indicative of some problem communicating with the hard drive's electronics.

It is possible that you might obtain additional information on your console (and dmesg) during the hardware probes by booting in verbose mode. To do that:

Question: Was this delay present when you booted the GENERIC kernel, or does it appear only when use use the GENERIC.MP kernel?

Yes. But that's another problem. When I booted the GENERIC kernel, the whole system would go unresponsive a few seconds after starting Xmms (that I got with pkg_add). The only thing I could do was to forcibly shut it down. Then I ended up with an unusable pkg_add.

Unfortunately, there is only a limited amount of space for kernel messages in the in-core dmesg.

You might find useful information in /var/run/dmesg.boot or /var/log/messages.

----

I believe this particular problem - delays during kernel-probe at boot time -- has little or nothing to do with your system hang when running a multimedia application under GENERIC. Let's solve one problem at a time.

No errors were logged; if there had been any communication problems (cable,connector) we would have seen them here.

Attributes are a little confusing. While none of them should have anything to do with a delay during probe, some indicate disk-drive trouble, if they are at all accurate. It is unclear how accurate they are, the vendors all use different raw and normalized values.

Indicates the rate of hardware read errors that occurred when reading data from a disk surface. A non-zero value indicates a problem with either the disk surface or read/write heads. Note that Seagate drives often report a raw value that is very high even on new drives, and does not thereby indicate a failure.

Your drive was manufactured by FJ, not Seagate.

Your reallocated sector count (#5) and reallocation (#196) raw values are so large I believe they are meaningless. As is your run out cancel (#203). I'm guessing the vendor doesn't use these fields as intended.

A short offline test (#smartctl -t short /dev/wd0c) will test drive electronics, and basic seek and read operations. Wait two minutes, then run #smartctl -a /dev/wd0c, look near the bottom to see if the test is successful. The long offline test will read every addressable sector on the drive.