ports/emulators/rtc is a real time clock port, which is used by vmware (and instaled as a dependency for a emulators/vmware3 port). Along with the module, there comes a rc.d script, namely rtc.sh. It loads the module on start and unloads it on stop. The module however, is somewhat broken. After using vmware and "kldunload rtc.ko" I get a panic. Well, I know kldunloading modules is always tricky and I should not play with this when I don't have to, but this kldunload is enabled by default via the port! The rtc.ko also causes a panic after a reboot when it wasn't kldunloaded, but this panic is not so severe, as the buffers are flushed first and the filesystems are synced. Fix: First of all, remove the kldunload thing from rc.d script (ports/emulators/rtc/files/rtc.sh). VMware says that rtc.ko is only needed for some windows stuff. As the port is broken (at least on 5.1-R) and not so-needed, maybe it would be better to remove the dependency (or make it an option, with a warning). The best fix would be fixing the module itself, of course. ;) How-To-Repeat: Install ports/emulators/rtc and ports/emulators/vmware3. Configure a vmware guest system, turn it on, play with it, then turn off. Reboot the system.
The bug is that the module, on unloading, calls destroy_dev() twice for its device. Doing this causes a panic. Fix: --- ports/emulators/rtc/files/rtc.c_orig Thu Oct 2 10:20:17 2003 +++ ports/emulators/rtc/files/rtc.c Thu Oct 2 09:58:13 2003 @@ -168,7 +168,6 @@ if (sc->var.flags.opened) { return EBUSY; } - destroy_dev(sc->dev); FREE(sc, M_DEVBUF); return error; }
Responsible Changed From-To: freebsd-ports-bugs->freebsd-emulation Over to the maintainer group.
I ran into this some time ago, and found that you get different results depending on whether the device has been opened or not. Have you tried kldunloading "rtc" w/o using it first, e.g. directly after boot? I've been using the following patch for a while: --- rtc.c.org Wed Aug 20 20:41:50 2003 +++ rtc.c Thu Oct 2 08:40:37 2003 @@ -299,7 +299,8 @@ DLog(Lfail, "%p busy", sc); return error; } - destroy_dev(rtc_dev); + if (sc == NULL) + destroy_dev(rtc_dev); #if __FreeBSD_version < 500104 error = cdevsw_remove(&rtc_cdevsw); #endif Which seems to work find for me in all cases. I made a mental note to submit a PR once I've tested out the fix, and then of course, I forgot all about it... :) $.02, /Mikko
On Thu, Oct 02, 2003 at 08:45:19AM -0700, Mikko Työläjärvi wrote: > > I ran into this some time ago, and found that you get different > results depending on whether the device has been opened or not. > > Have you tried kldunloading "rtc" w/o using it first, e.g. directly > after boot? > > I've been using the following patch for a while: [snip] > Which seems to work find for me in all cases. I made a mental note to > submit a PR once I've tested out the fix, and then of course, I forgot > all about it... :) This patch doesn't work for me; kldunload rtc still causes a panic. -- Jan 'Winfried' Srzednicki w@expro.pl
On Thu, Oct 02, 2003 at 10:24:41AM +0200, Philipp Mergenthaler wrote: > The bug is that the module, on unloading, calls destroy_dev() twice > for its device. Doing this causes a panic. > > Fix: > --- ports/emulators/rtc/files/rtc.c_orig Thu Oct 2 10:20:17 2003 > +++ ports/emulators/rtc/files/rtc.c Thu Oct 2 09:58:13 2003 > @@ -168,7 +168,6 @@ > if (sc->var.flags.opened) { > return EBUSY; > } > - destroy_dev(sc->dev); > FREE(sc, M_DEVBUF); > return error; > } This one seems to work fine. Thanks. ;) -- Jan 'Winfried' Srzednicki w@expro.pl
Responsible Changed From-To: freebsd-emulation->emulation Change freebsd-emulation to emulation so that the list only receives one list of open PRs.
Responsible Changed From-To: emulation->silby I will fix this and a bunch of other things in the rtc driver in the next week or two.
State Changed From-To: open->closed Suggested fix committed.