[asterisk-users] Re: modprobe wctdm fails in /etc/rc.local on FC5

[Tzafrir Cohen]

Below is a good example of misusing init.d scripts with the obvious
results of the need for ugly workarounds. Why do you fight against the
design of your system?

See specific comments below,

On Wed, Aug 16, 2006 at 08:20:55AM -0400, Steven wrote:
> rc.local:
> 
> touch /var/lock/subsys/local
> 
> setpci -v -s 00:1f.1 LATENCY_TIMER=4
> setpci -v -s 02:0e.0 LATENCY_TIMER=4
> setpci -v -s 0b:07.0 LATENCY_TIMER=4
> setpci -v -s 0c:08.0 LATENCY_TIMER=4
> setpci -v -s 10:0d.0 LATENCY_TIMER=0
> setpci -v -s 06:02.0 LATENCY_TIMER=ff
> sleep 5

Why a sleep here? What exactly do you wait for?

"sleep" is an indication of a bad workaround for a race condition. It is
a bad workaround, as you can never know if you sleep enough.

> 
> echo UnLoading wct4xxp
> rmmod -v wct4xxp
> rmmod -v zaptel
> sleep 3

Huh? Why is that? 

BTW: 'genzaptelconf -u' will unload all zaptel modules. If 'modprobe -r'
works on your system: that's even better.

> 
> echo Loading wct4xxp
> /sbin/modprobe -v zaptel
> sleep 5
> /sbin/modprobe -v wct4xxp
> sleep 5
> # ztcfg -vvvv
> #sleep 5

The 'sleep'-s here are because of the following bugs:

1. running ztcfg automatically on modules load
2. not properly waiting for /dev/zap/ctl to be generated by udev

> 
> echo 1 > /proc/irq/201/smp_affinity
> echo 1 > /proc/irq/217/smp_affinity
> echo 0 > /proc/irq/209/smp_affinity
> echo 1 > /proc/irq/14/smp_affinity
> 
> /usr/sbin/amportal start

Now, that's an init.d script. Most of the code above should be merged
into the zaptel init.d script (which is run before asterisk/amportal).
Then the init system will run amportal later. If actually needed.

-- 
Tzafrir Cohen         sip:tzafrir at local.xorcom.com
icq#16849755          iax:tzafrir at local.xorcom.com
+972-50-7952406          jabber:tzafrir at jabber.org
tzafrir.cohen at xorcom.com     http://www.xorcom.com