Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC
* De: Maxim Sobolev <[EMAIL PROTECTED]> [ Data: 2002-10-27 ]
[ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ]
> On Sat, Oct 26, 2002 at 06:09:31PM -0700, Nate Lawson wrote:
> > On Thu, 24 Oct 2002, Maxim Sobolev wrote:
> > > Please review the patch, which adds two new types of events -
> > > NOTE_STARTEXEC and NOTE_STOPEXEC, that could be used to get
> > > notification when the image starts or stops executing. For example, it
> > > could be used to monitor that a daemon is up and running and notify
> > > administrator when for some reason in exits. I am running this code
> > > for more than a year now without any problems.
> > >
> > > Any comments and suggestions are welcome.
> >
> > Couldn't this just be done by init(8) and /etc/ttys? Or inetd? If you
> > want to write your own, couldn't you use waitpid()? Or a kevent() of
> > EVFILT_PROC with NOTE_EXIT/NOTE_FORK? I'm not sure I see the need for
> > this.
>
> EVFILT_PROC operates on pids, while NOTE_{START,STOP}EXEC operate on
> vnodes - it is the main difference. Currently, you can't reliably
> get a notification when kernes started executing some arbitrary
> executable from your fs.
This is not a job for the kernel, I don't think. Implement it in userland
in terms of having the daemon write to a pidfile at startup, and have SIGUSR1
make it tell the sender it's alive (using my sigq stuff this is trivial, just
send SIGUSR2 back), and periodically read the pidfile and try to communciate
with the daemon, and respawn it if it fails. This could be racey if done
poorly. However if you want this for *any* executable, rather than just
"some arbitrary executable" rather than some specific job, then while I wonder
how useful it is in a generic concept, the kq solution might be more
reasonable.
Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve
Will break world for fulltime employment. | finger [EMAIL PROTECTED]
http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC
On Sun, Oct 27, 2002 at 01:04:29AM -0700, Juli Mallett wrote:
> * De: Maxim Sobolev <[EMAIL PROTECTED]> [ Data: 2002-10-27 ]
> [ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ]
> > On Sat, Oct 26, 2002 at 06:09:31PM -0700, Nate Lawson wrote:
> > > On Thu, 24 Oct 2002, Maxim Sobolev wrote:
> > > > Please review the patch, which adds two new types of events -
> > > > NOTE_STARTEXEC and NOTE_STOPEXEC, that could be used to get
> > > > notification when the image starts or stops executing. For example, it
> > > > could be used to monitor that a daemon is up and running and notify
> > > > administrator when for some reason in exits. I am running this code
> > > > for more than a year now without any problems.
> > > >
> > > > Any comments and suggestions are welcome.
> > >
> > > Couldn't this just be done by init(8) and /etc/ttys? Or inetd? If you
> > > want to write your own, couldn't you use waitpid()? Or a kevent() of
> > > EVFILT_PROC with NOTE_EXIT/NOTE_FORK? I'm not sure I see the need for
> > > this.
> >
> > EVFILT_PROC operates on pids, while NOTE_{START,STOP}EXEC operate on
> > vnodes - it is the main difference. Currently, you can't reliably
> > get a notification when kernes started executing some arbitrary
> > executable from your fs.
>
> This is not a job for the kernel, I don't think.
Why not? Kernel now reports number of internal events via kqueue(2) interface,
there is nothing wrong in adding yet another one. BTW, linux and irix already
have similar functionality provided by /dev/imon.
> Implement it in userland
> in terms of having the daemon write to a pidfile at startup, and have SIGUSR1
> make it tell the sender it's alive (using my sigq stuff this is trivial, just
> send SIGUSR2 back), and periodically read the pidfile and try to communciate
> with the daemon, and respawn it if it fails. This could be racey if done
> poorly. However if you want this for *any* executable, rather than just
> "some arbitrary executable" rather than some specific job, then while I wonder
> how useful it is in a generic concept, the kq solution might be more
> reasonable.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC
* De: Maxim Sobolev <[EMAIL PROTECTED]> [ Data: 2002-10-27 ]
[ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ]
> On Sun, Oct 27, 2002 at 01:04:29AM -0700, Juli Mallett wrote:
> > * De: Maxim Sobolev <[EMAIL PROTECTED]> [ Data: 2002-10-27 ]
> > [ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ]
> > > On Sat, Oct 26, 2002 at 06:09:31PM -0700, Nate Lawson wrote:
> > > > On Thu, 24 Oct 2002, Maxim Sobolev wrote:
> > > > > Please review the patch, which adds two new types of events -
> > > > > NOTE_STARTEXEC and NOTE_STOPEXEC, that could be used to get
> > > > > notification when the image starts or stops executing. For example, it
> > > > > could be used to monitor that a daemon is up and running and notify
> > > > > administrator when for some reason in exits. I am running this code
> > > > > for more than a year now without any problems.
> > > > >
> > > > > Any comments and suggestions are welcome.
> > > >
> > > > Couldn't this just be done by init(8) and /etc/ttys? Or inetd? If you
> > > > want to write your own, couldn't you use waitpid()? Or a kevent() of
> > > > EVFILT_PROC with NOTE_EXIT/NOTE_FORK? I'm not sure I see the need for
> > > > this.
> > >
> > > EVFILT_PROC operates on pids, while NOTE_{START,STOP}EXEC operate on
> > > vnodes - it is the main difference. Currently, you can't reliably
> > > get a notification when kernes started executing some arbitrary
> > > executable from your fs.
> >
> > This is not a job for the kernel, I don't think.
>
> Why not? Kernel now reports number of internal events via kqueue(2) interface,
> there is nothing wrong in adding yet another one. BTW, linux and irix already
> have similar functionality provided by /dev/imon.
If you implemented a kq interface, and an imon wrapper, I'd be much more
impressed. A less-divergant interface to do this would be nice, even if
kq is the backing. In fact, especially if kq is the backing, kq is strong,
kq will make us smart.
--
Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve
Will break world for fulltime employment. | finger [EMAIL PROTECTED]
http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC
Juli Mallett wrote:
> > EVFILT_PROC operates on pids, while NOTE_{START,STOP}EXEC operate on
> > vnodes - it is the main difference. Currently, you can't reliably
> > get a notification when kernes started executing some arbitrary
> > executable from your fs.
>
> This is not a job for the kernel, I don't think. Implement it in userland
> in terms of having the daemon write to a pidfile at startup, and have SIGUSR1
> make it tell the sender it's alive (using my sigq stuff this is trivial, just
> send SIGUSR2 back), and periodically read the pidfile and try to communciate
> with the daemon, and respawn it if it fails. This could be racey if done
> poorly. However if you want this for *any* executable, rather than just
> "some arbitrary executable" rather than some specific job, then while I wonder
> how useful it is in a generic concept, the kq solution might be more
> reasonable.
The problem with daemon's is that they are not children of a process
other than "init". It's only useful to use SIGCHLD as the termination
notification if it's a parent process being notified.
For most daemons, this would mean relacing "init".
It's useful to replace "init", and "syslog", both, to be able to
track state for services; however, the notification on termination
is significantly better if anyone who cares can monitor for it.
The main problem with this approach is that it's not the service
identity that's communicated, but the name of a file, and the file
name is for a path that's probably relative to the current directory
in most cases (or could be), and so isn't globally unique.
It is also not useful to poll, since your daemon could be down for
an entire poll interval; also, it means you have to trust the poll
interval itself will be maintained... and if your failure is a
failure of the process doing the polling itself, that's broken.
In terms of most services, actually gross notification is the
minmal level of assurance: just because a program that's supposed
to offer a service is caught in an endless loop, so that there
has not been an exit, doesn't mean that it's actually offering
the service that it was intended to offer.
The best check is to actually attach to, and utilize the service.
There is also an intermediate level... which is probably best
served by kevents, actually. For network services, when a listen
on a socket occurs, it occurs on a socket specific to a service:
a well known port.
One obvious thing to do is to cause events to occur when a listen
is issued, and when a listen socket is closed. One might also do
an implicit listen in the case of an outstanding listen socket,
for which no listen was executed (default listen queue depth)...
basically a blocking accept vs. a connect and/or a select for
readability on an outstanding socket.
So there are various levels of service availability notification:
0) A "ping" of the system offering the service indicates that
the interrupt code and network stack are active, but nothing
else.
1) The program is running/stopped, with a notification latency
(this is your suggested scenario, having to do with pid
files).
2) The program is running/stopped, with no notification latency
(this is the NOTE_STARTEXEC/NOTE_STOPEXEC scenario).
3) A server is listening on a well known port/has stopped
listening on a well known port (this is my suggested scenario,
and has the benefit of accounting for configuration and other
latencies that #1 and #2 can miss -- it closes race windows).
4) Active status monitoring, through attempts to actually use a
service offered by a server (e.g. making a DNS request to a
DNS server, doing a "HEAD /" on an HTTP server, saying "EHLO"
to an SMTP server, etc.).
Obviously, #4 is the best approach. Barring that, #3 provides much
better identification of services, but onl works on netwqork services.
#2 provides information about services by (potentially relative or
non-matching) path name. Actually, the best approach for this would be
to return a "stat" buffer for the file that was exec'ed or stopped, so
that the caller could use the name information for logging, but could
verify that the "sendmail" being run was, say, /usr/local/bin/sendmail,
instead of /usr/sbin/sendmail: the way this would work is to have the
program which cared stat the executable that it expected to run, and
then compare the "stat" information (dev_t and ino_t) to verify that
the uniquely identified executable was in fact what was running. This
is *much* better than a (partial) path comparison by (nonunique) file
name (consider also: hard links with different names).
So, in general:
o NOTE_STARTEXEC/NOTE_STOPEXEC are a good idea; they close a
latency window, and they close a race window, and the eliminate
a single-point-of-failure that would come from having one
monitoring program ("who monitors the monitors?").
o
Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC
On Sun, Oct 27, 2002 at 01:24:19AM -0700, Juli Mallett wrote:
> * De: Maxim Sobolev <[EMAIL PROTECTED]> [ Data: 2002-10-27 ]
> [ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ]
> > On Sun, Oct 27, 2002 at 01:04:29AM -0700, Juli Mallett wrote:
> > > * De: Maxim Sobolev <[EMAIL PROTECTED]> [ Data: 2002-10-27 ]
> > > [ Subjecte: Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC ]
> > > > On Sat, Oct 26, 2002 at 06:09:31PM -0700, Nate Lawson wrote:
> > > > > On Thu, 24 Oct 2002, Maxim Sobolev wrote:
> > > > > > Please review the patch, which adds two new types of events -
> > > > > > NOTE_STARTEXEC and NOTE_STOPEXEC, that could be used to get
> > > > > > notification when the image starts or stops executing. For example, it
> > > > > > could be used to monitor that a daemon is up and running and notify
> > > > > > administrator when for some reason in exits. I am running this code
> > > > > > for more than a year now without any problems.
> > > > > >
> > > > > > Any comments and suggestions are welcome.
> > > > >
> > > > > Couldn't this just be done by init(8) and /etc/ttys? Or inetd? If you
> > > > > want to write your own, couldn't you use waitpid()? Or a kevent() of
> > > > > EVFILT_PROC with NOTE_EXIT/NOTE_FORK? I'm not sure I see the need for
> > > > > this.
> > > >
> > > > EVFILT_PROC operates on pids, while NOTE_{START,STOP}EXEC operate on
> > > > vnodes - it is the main difference. Currently, you can't reliably
> > > > get a notification when kernes started executing some arbitrary
> > > > executable from your fs.
> > >
> > > This is not a job for the kernel, I don't think.
> >
> > Why not? Kernel now reports number of internal events via kqueue(2) interface,
> > there is nothing wrong in adding yet another one. BTW, linux and irix already
> > have similar functionality provided by /dev/imon.
>
> If you implemented a kq interface, and an imon wrapper, I'd be much more
> impressed. A less-divergant interface to do this would be nice, even if
> kq is the backing. In fact, especially if kq is the backing, kq is strong,
> kq will make us smart.
Actually, the only user of /dev/imon I am aware of is SGI's fam package
(file alteration monitor). I've already implemented subset of it
using BSD kqueue as a backend instead of imon. Check bsdfam project
on sourceforge for details.
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
i am looking for a 5 volt signal
I'm looking for a 5 volt signal.
I have wires plugged into pins 2 and 25 of the parallel port.
I have written a small program:
#include
#include
#include
int main()
{
int fd;
while(1)
{
ioctl(fd, PPISDATA, 255);
}
}
and have it executing...
I have a multi-meter with the positive lead touching the pin 2 wire and the negative
lead touching pin 25 wire, but i am not registering any voltage.
=(
I am sad.
I have recompiled my kernel to disable plip and enable ppi. The following is a snipet
of my kernel configuration:
# Parallel port
device ppc0at isa? irq 7
device ppbus # Parallel port bus (required)
device lpt # Printer
#
# 2002 oct 27 - removed plip and added ppi.
#
#device plip# TCP/IP over parallel
device ppi # Parallel port interface device
#device vpo # Requires scbus and da
any help would be very much appreciated
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: i am looking for a 5 volt signal
Shouldn't the fact that the signal is in a while loop keep the 5 volt
signal going? Isn't the parallel port being blasted with the
value 255 over and over again?
The serial port will not fulfill what i am ultimately trying to achive. I
am trying to have the parallel port to control 8 relays each turing
on/off based upon which bit i send out to the port.
On Sun, 27 Oct 2002 [EMAIL PROTECTED] wrote:
> try using also the serial port and a logical buffer
>
> the 5 volt signal is very fast and your multimeter is maybe not to fast
>
> > I'm looking for a 5 volt signal.
> >
> > I have wires plugged into pins 2 and 25 of the parallel port.
> >
> > I have written a small program:
> >
> > #include
> > #include
> > #include
> >
> > int main()
> > {
> > int fd;
> > while(1)
> > {
> > ioctl(fd, PPISDATA, 255);
> > }
> > }
> >
> > and have it executing...
> >
> > I have a multi-meter with the positive lead touching the pin 2 wire and
> > the negative lead touching pin 25 wire, but i am not registering any
> > voltage.
> >
> > =(
> >
> > I am sad.
> >
> > I have recompiled my kernel to disable plip and enable ppi. The
> > following is a snipet of my kernel configuration:
> >
> > # Parallel port
> > device ppc0at isa? irq 7
> > device ppbus # Parallel port bus (required)
> > device lpt # Printer
> > #
> > # 2002 oct 27 - removed plip and added ppi.
> > #
> > #device plip# TCP/IP over parallel
> > device ppi # Parallel port interface device
> > #device vpo # Requires scbus and da
> >
> > any help would be very much appreciated
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
>
>
>
> -
> "UNIXMEXICO la comunidad *nix en todo México!"
> http://www.unixmexico.org/
>
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: i am looking for a 5 volt signal
I'm having problems just using 1 bit fromt he parallel port at this time.
On Sun, 27 Oct 2002 [EMAIL PROTECTED] wrote:
> the parallel port then is ok
> now you can use a logical multiplexer
>
> and from the paralel port you can use just 3 bits
>
> take a look to the data sheets ot this multiplexer
>
> http://www.cs.utah.edu/classes/cs3700/handouts/pdf/MM74C150.pdf
>
> the input of the multiplexer will be
>
> 000
> 001
> 010
> 011
> 100
> 101
> 110
> 111
>
> and at the ouput you will have a leched 1 or 0 ( 5volts or 0 volts) the
> ones you can aply to your relays
>
>
> > Shouldn't the fact that the signal is in a while loop keep the 5 volt
> > signal going? Isn't the parallel port being blasted with the
> > value 255 over and over again?
> >
> > The serial port will not fulfill what i am ultimately trying to achive.
> > I am trying to have the parallel port to control 8 relays each turing
> > on/off based upon which bit i send out to the port.
> >
> > On Sun, 27 Oct 2002 [EMAIL PROTECTED] wrote:
> >
> >> try using also the serial port and a logical buffer
> >>
> >> the 5 volt signal is very fast and your multimeter is maybe not to
> >> fast
> >>
> >> > I'm looking for a 5 volt signal.
> >> >
> >> > I have wires plugged into pins 2 and 25 of the parallel port.
> >> >
> >> > I have written a small program:
> >> >
> >> > #include
> >> > #include
> >> > #include
> >> >
> >> > int main()
> >> > {
> >> > int fd;
> >> > while(1)
> >> > {
> >> > ioctl(fd, PPISDATA, 255);
> >> > }
> >> > }
> >> >
> >> > and have it executing...
> >> >
> >> > I have a multi-meter with the positive lead touching the pin 2 wire
> >> and the negative lead touching pin 25 wire, but i am not registering
> >> any voltage.
> >> >
> >> > =(
> >> >
> >> > I am sad.
> >> >
> >> > I have recompiled my kernel to disable plip and enable ppi. The
> >> following is a snipet of my kernel configuration:
> >> >
> >> > # Parallel port
> >> > device ppc0at isa? irq 7
> >> > device ppbus # Parallel port bus (required)
> >> > device lpt # Printer
> >> > #
> >> > # 2002 oct 27 - removed plip and added ppi.
> >> > #
> >> > #device plip# TCP/IP over parallel
> >> > device ppi # Parallel port interface device
> >> > #device vpo # Requires scbus and da
> >> >
> >> > any help would be very much appreciated
> >> >
> >> >
> >> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> >> > with "unsubscribe freebsd-hackers" in the body of the message
> >>
> >>
> >>
> >> -
> >> "UNIXMEXICO la comunidad *nix en todo México!"
> >> http://www.unixmexico.org/
> >>
> >>
> >>
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
>
>
>
> -
> "UNIXMEXICO la comunidad *nix en todo México!"
> http://www.unixmexico.org/
>
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: i am looking for a 5 volt signal
: :Shouldn't the fact that the signal is in a while loop keep the 5 volt :signal going? Isn't the parallel port being blasted with the :value 255 over and over again? : :The serial port will not fulfill what i am ultimately trying to achive. I :am trying to have the parallel port to control 8 relays each turing :on/off based upon which bit i send out to the port. : :.. :> try using also the serial port and a logical buffer :> :> the 5 volt signal is very fast and your multimeter is maybe not to fast :> :> > I'm looking for a 5 volt signal. Uh guys. Parallel port digital outputs do not generally have a whole lot of drive. I really doubt a parallel port output could drive a relay. And it's probably TTL level equivalents, not CMOS. Even if you ganged the output bits together I doubt you would get enough drive out of them. A serial port output (+/-12 but you may see +/-10 or -5 and +12 or other out-of-spec combinations) is far more likely to be useful in driving a relay, though again there will not be much drive. It would be far better to supply the power you need from another source, like a +5V power supply. Or just get a wallwart with DC output and run it through a linear regulator. At least then you aren't likely to burn the house down :-) -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Suggestion: usbd.conf uses rc.conf for options
Hi:
I notice that usbd.conf has this for the mouse device:
device "Mouse"
devname "ums[0-9]+"
attach "/usr/sbin/moused -p /dev/${DEVNAME} -I /var/run/moused.${DEVNAME}.pid"
If usbd.conf could use rc.conf, this could be modified to
attach "/usr/sbin/moused ${moused_flags} -p /dev/${DEVNAME} -I
/var/run/moused.${DEVNAME}.pid"
That way the user wouldn't loose his moused_flags (like accelerator settings).
YMMV
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Suggestion: usbd.conf uses rc.conf for options
I agree, that would be a nice feature in usbd, but a workaround to gain the same
functionality would be:
attach "/usr/sbin/moused `/usr/bin/perl -e 'while(<>) { $foo = $_ . $foo; } if($foo =~
/^moused_flags="(.*?)"$/im) { print $1; }' < /etc/rc.conf` -p /dev/${DEVNAME} -I
/var/run/moused.${DEVNAME}.pid"
Baldur
On Sunday 27 October 2002 19:33, you wrote:
> Hi:
>
> I notice that usbd.conf has this for the mouse device:
>
> device "Mouse"
> devname "ums[0-9]+"
> attach "/usr/sbin/moused -p /dev/${DEVNAME} -I
> /var/run/moused.${DEVNAME}.pid"
>
> If usbd.conf could use rc.conf, this could be modified to
>
> attach "/usr/sbin/moused ${moused_flags} -p /dev/${DEVNAME} -I
> /var/run/moused.${DEVNAME}.pid"
>
> That way the user wouldn't loose his moused_flags (like accelerator
> settings).
>
> YMMV
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: i am looking for a 5 volt signal
Matthew Dillon wrote: > Uh guys. Parallel port digital outputs do not generally have a whole > lot of drive. I really doubt a parallel port output could drive a > relay. Depends on the amperage the relay draws. 8-). I used to use the paralell port output to drive a pulse dialer and "off hook" for a modem that didn't have the capability itself (a 300 baud accoustic couple modem). One of the reasons I laugh when I see the "war dialer" scene in War Games. That said, you damn well better not draw any real current from the parallel port, if you want to avoid cooking it. In other words, do *not* use it to power something external, and if you are using it for a 1/0 signal to something that wangts to switch a lot of volts and amps from a real power supply, consider using an SCR, instead. > > And it's probably TTL level equivalents, not CMOS. Even if you ganged > the output bits together I doubt you would get enough drive out of > them. > > A serial port output (+/-12 but you may see +/-10 or -5 and +12 or other > out-of-spec combinations) is far more likely to be useful in driving > a relay, though again there will not be much drive. It would be far > better to supply the power you need from another source, like a +5V > power supply. Or just get a wallwart with DC output and run it through > a linear regulator. At least then you aren't likely to burn the house > down :-) Get a brick and use an SCR to switch the brick. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: i am looking for a 5 volt signal
On Sun, Oct 27, 2002 at 11:19:15AM -0800, Matthew Dillon wrote: > > : > :Shouldn't the fact that the signal is in a while loop keep the 5 volt > :signal going? Isn't the parallel port being blasted with the > :value 255 over and over again? > : > :The serial port will not fulfill what i am ultimately trying to achive. I > :am trying to have the parallel port to control 8 relays each turing > :on/off based upon which bit i send out to the port. > : > :.. > :> try using also the serial port and a logical buffer > :> > :> the 5 volt signal is very fast and your multimeter is maybe not to fast > :> > :> > I'm looking for a 5 volt signal. > > Uh guys. Parallel port digital outputs do not generally have a whole > lot of drive. I really doubt a parallel port output could drive a > relay. Get a solid state relay. Parallel ports used to be build with TTL chips, but these days drive power is probably much less. > And it's probably TTL level equivalents, not CMOS. Even if you ganged > the output bits together I doubt you would get enough drive out of > them. Yup. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: i am looking for a 5 volt signal
On Sun, 27 Oct 2002 11:19:15 -0800 (PST) Matthew Dillon <[EMAIL PROTECTED]> wrote: > > : > :Shouldn't the fact that the signal is in a while loop keep the 5 volt > :signal going? Isn't the parallel port being blasted with the > :value 255 over and over again? > : > :The serial port will not fulfill what i am ultimately trying to achive. I > :am trying to have the parallel port to control 8 relays each turing > :on/off based upon which bit i send out to the port. > : > :.. > :> try using also the serial port and a logical buffer > :> > :> the 5 volt signal is very fast and your multimeter is maybe not to fast > :> > :> > I'm looking for a 5 volt signal. > > Uh guys. Parallel port digital outputs do not generally have a whole > lot of drive. I really doubt a parallel port output could drive a > relay. > > And it's probably TTL level equivalents, not CMOS. Even if you ganged > the output bits together I doubt you would get enough drive out of > them. > > A serial port output (+/-12 but you may see +/-10 or -5 and +12 or other > out-of-spec combinations) is far more likely to be useful in driving > a relay, though again there will not be much drive. It would be far > better to supply the power you need from another source, like a +5V > power supply. Or just get a wallwart with DC output and run it through > a linear regulator. At least then you aren't likely to burn the house > down :-) > > -Matt > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > Two things here... One, most multimeters do not have the senistivity to monitor a pulse like this, they will just see 0 volts. You really need a scope or a probe to see this. Second, you'll can't drive an analog relay off of Pport without a latch or something. A transistor setup would work just fine. Check out http://www.circuitcellar.com/ for stuff that would work... GB -- GB Clark II | Roaming FreeBSD Admin [EMAIL PROTECTED] | General Geek CTHULU for President - Why choose the lesser of two evils? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Fw: Anyone got time for a quick fix commit in the libc/db? Patch included
Hello, There are two seperate bugs in libc/db. The first is the in libc/db/hash/hash.c in hash_action. If hash_action is called with HASH_DELETE and the key is not found it will return -1 (error) instead of 1 (key not found) as documented in the man page. This bug is mentioned in PR misc/42429. The second is in libc/db/hash/ndbm.c. dbm_delete needs to be changed to return the status from the db call directly. As it stands now it just checks for a non-zero and returns -1 if this is so. If it returned the status directly then it would work as documented. This is the bug mentioned in PR misc/42422. Attached are two patch files relative to lib/libc/db/hash. Should have done more research before I sent the first PR...:) GB -PATCH1- *** hash.c Wed Sep 4 17:13:22 2002 --- hash.c.patched Wed Sep 4 17:11:03 2002 *** *** 685,692 save_bufp->flags &= ~BUF_PIN; return (SUCCESS); } - case HASH_GET: case HASH_DELETE: default: save_bufp->flags &= ~BUF_PIN; return (ABNORMAL); --- 685,693 save_bufp->flags &= ~BUF_PIN; return (SUCCESS); } case HASH_DELETE: + return 1; + case HASH_GET: default: save_bufp->flags &= ~BUF_PIN; return (ABNORMAL); -PATCH2- *** ndbm.c Wed Sep 4 17:14:44 2002 --- ndbm.c.patched Wed Sep 4 17:15:06 2002 *** *** 171,181 dbtkey.data = key.dptr; dbtkey.size = key.dsize; ! status = (db->del)(db, &dbtkey, 0); ! if (status) ! return (-1); ! else ! return (0); } /* --- 171,178 dbtkey.data = key.dptr; dbtkey.size = key.dsize; ! return (db->del)(db, &dbtkey, 0); ! } /* -CUT- GB -- GB Clark II | Roaming FreeBSD Admin [EMAIL PROTECTED] | General Geek CTHULU for President - Why choose the lesser of two evils? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting ACPI to work on -stable
On Thu, Oct 24, 2002 at 11:11:18PM +0200, Wilko Bulte wrote: > On Thu, Oct 24, 2002 at 04:36:50PM -0400, John Baldwin wrote: > > > > On 24-Oct-2002 Wilko Bulte wrote: > > > On Thu, Oct 24, 2002 at 04:29:20PM -0400, John Baldwin wrote: > > >> > > >> On 24-Oct-2002 Wilko Bulte wrote: > > >> > On Thu, Oct 24, 2002 at 03:22:19PM -0400, John Baldwin wrote: > > >> >> > > >> >> On 24-Oct-2002 Wilko Bulte wrote: > > >> >> > On Thu, Oct 24, 2002 at 02:25:57PM -0400, John Baldwin wrote: > > >> >> >> > > >> >> >> On 24-Oct-2002 Wilko Bulte wrote: > > >> >> >> > On Wed, Oct 23, 2002 at 04:20:17PM -0400, John Baldwin wrote: > > >> >> >> >> Ok, here are the instructions on getting ACPI going on 4-stable for > > >> >> >> >> those of you who are foolish^H^H^H^H^H^H^Hbrave: > > >> >> >> >> > > >> > > > >> >> > - pressing the lid switch results in an immediate reboot > > >> >> > - apm gives me: > > > Hmm, what does 'l *0xc01a5084' and 'l *0xc0160fe5' show? > > I did not trust this kernel.debug, built a new one and crashed it giving me: > > #0 dumpsys () at ../../kern/kern_shutdown.c:487 > #1 0xc015a5dd in db_fncall (dummy1=0, dummy2=0, dummy3=0, While playing with the laptop it proved that roughly all power events lead to the panic. Like running the battery flat for example :) It panics just before it gets killed because of lack of power. Wilko -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Show me the light
I got a LED and touched it to the positive and negative ends of two 1.5v
AA batteries in a serial configuration.
The LED lit up. I then crimped on pins to the end of the LED wires and
again tested it with the batteries. Again, I saw the light.
I plugged said tinned pins into the 2nd and 25th pinout of a 25 pin port
(the parallel port): positive lead to the 2 pin, and negative pin to\
the the 25 pin.
I then executed the following program:
I have written a small program:
#include
#include
#include
int main()
{
int fd;
while(1)
{
ioctl(fd, PPISDATA, 255);
}
}
I am expecting to see that LED light up, flashing if not creating a solid
light. However, I am not.
any help would be very much appreciated
Sincerely,
David
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: i am looking for a 5 volt signal
: :Matthew Dillon wrote: :> Uh guys. Parallel port digital outputs do not generally have a whole :> lot of drive. I really doubt a parallel port output could drive a :> relay. : :Depends on the amperage the relay draws. 8-). : :I used to use the paralell port output to drive a pulse dialer and :"off hook" for a modem that didn't have the capability itself (a :300 baud accoustic couple modem). One of the reasons I laugh when :I see the "war dialer" scene in War Games. : :That said, you damn well better not draw any real current from the :parallel port, if you want to avoid cooking it. In other words, do :*not* use it to power something external, and if you are using it :for a 1/0 signal to something that wangts to switch a lot of volts :and amps from a real power supply, consider using an SCR, instead. : :-- Terry Huh. I would have expected you to use the current loop on the phone line to power the dialer. There's a significant amount of power available there, though you would have to isolate the circuit since the common mode could be upwards of one or two hundred volts. In anycase, I can only concur on the danger of ganging the parallel power output bits. A single chip is driving those outputs and is almost certainly not rated to deal with a maximal current draw from all of them at once for long periods of time. It could fry. Though if it's a TTL output there isn't much current there anyway (TTL can sink a lot of current but it can't source it, the equivalent resistance to VCC is fairly high). Serial port pins are a much better bet. Serial port outputs can handle shorts far better then parallel port outputs and since the voltages are higher you can draw a good chunk of current out of them. Use diodes to rectify the serial port outputs (be sure to orient them properly, BAR side is positive. Flip the orientation for the negative supply). -o--o positive supply to circuit | (bar) | (around +10V) DIODE DIODE | | serial-pin serial-pin | | DIODE DIODE (OPTIONAL IF YOU NEED A NEGATIVE | (bar) | SUPPLY) -o--o negative supply to circuit (around -10V) Then: positive supply to circuit -[LINREG] +5V to circuit Use a 100uF (or more), a 10uF, and 0.1uF capacitor on the input side of the regulator and a 0.1uF capacitor on the output side of the regulator. The 0.1's should be as close to the linear regulator as possible. i.e.: ---supplyo-oo[LINREG]--o +5V supply | || 5V | CAP CAP CAPCAP | || | gnd gnd gndgnd 100 10 0.1 0.1 You can gang the serial outputs (by wire-dioding them together). The driver chips are far better able to handle that sort of thing, and since the output is +12V (well, usually +9 to +12) you can pull more current before it drops down to < 5V, so you can power 5V circuitry from it (up to a point). I expect you can get at least 20mA @ 5V out of ganged serial port outputs, possibly more. You could use an SCR but linear regulators are far, far better (a little 3-pin TO92 package linear regulator). And linear regulators have overcurrent protection as well (for themselves, not for whatever is powering them). It's fairly difficult to blow one up. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Show me the light
> I got a LED and touched it to the positive and negative ends of two 1.5v > AA batteries in a serial configuration. > The LED lit up. I then crimped on pins to the end of the LED wires and > again tested it with the batteries. Again, I saw the light. > > I plugged said tinned pins into the 2nd and 25th pinout of a 25 pin port > (the parallel port): positive lead to the 2 pin, and negative pin to\ > the the 25 pin. As far as I remember, there is open collector output on parallel port, so your wish impossible %-) Try "-" batteryes to ground, "+" batteries to "+" LED and "-" LED to data. And remember - you probably blow up your port, if not use current restrictor, usually resistor. I advice to replace LED with voltmeter in parallel with 2..5 Kohm resistor instead. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Show me the light
David Nicholas Kayal wrote (on Oct 27):
> int main()
> {
> int fd;
> while(1)
> {
> ioctl(fd, PPISDATA, 255);
> }
> }
Doesn't "fd" normally need to have a value, such as that of a valid
descriptor before you ioctl() it? Like:
fd = open("/dev/ppi0", O_RDWR);
Chris.
--
== [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting ACPI to work on -stable
On Sun, 27 Oct 2002, Wilko Bulte wrote: > > I did not trust this kernel.debug, built a new one and crashed it giving me: > > > > #0 dumpsys () at ../../kern/kern_shutdown.c:487 > > #1 0xc015a5dd in db_fncall (dummy1=0, dummy2=0, dummy3=0, > > While playing with the laptop it proved that roughly all power events > lead to the panic. Like running the battery flat for example :) > It panics just before it gets killed because of lack of power. The other way round it's the same: when you load the battery and it's getting 100% full -> boom. I already have three different coredumps :-) regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX-Systemadministrator Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID) Fax.: (+43 1) 4277-9140 der Universität Wien http://mailbox.univie.ac.at/~le/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting ACPI to work on -stable
On Sun, Oct 27, 2002 at 11:24:32PM +0100, Lukas Ertl wrote: > On Sun, 27 Oct 2002, Wilko Bulte wrote: > > > > I did not trust this kernel.debug, built a new one and crashed it giving me: > > > > > > #0 dumpsys () at ../../kern/kern_shutdown.c:487 > > > #1 0xc015a5dd in db_fncall (dummy1=0, dummy2=0, dummy3=0, > > > > While playing with the laptop it proved that roughly all power events > > lead to the panic. Like running the battery flat for example :) > > It panics just before it gets killed because of lack of power. > > The other way round it's the same: when you load the battery and it's > getting 100% full -> boom. I already have three different coredumps :-) Sounds logical ;) I have not tried that yet. -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting ACPI to work on -stable
Wilko Bulte wrote: > > > > #0 dumpsys () at ../../kern/kern_shutdown.c:487 > > #1 0xc015a5dd in db_fncall (dummy1=0, dummy2=0, dummy3=0, > > While playing with the laptop it proved that roughly all power events > lead to the panic. Like running the battery flat for example :) > It panics just before it gets killed because of lack of power. Most likely, there is a BIOS data area that is inaccessible to the BIOS code that gets invoked as a result of the interrupt, since most of the control stuff is implemented as BIOS traps, especially for the cheap-o processors, but also because you have to make the BIOS match the hardware implementation, and those vary widely. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: i am looking for a 5 volt signal
Matthew Dillon wrote: > Huh. I would have expected you to use the current loop on the > phone line to power the dialer. There's a significant amount > of power available there, though you would have to isolate the > circuit since the common mode could be upwards of one or two > hundred volts. Telephone is 24 volts DC, which generally falls off to 18v at the customer permises. Ring is AC line voltage, to support mechanical ringers (e.g. 120v AC between ring, 24v DC between tip and ring). I worked as a lineman on private phone systems starting around age 14. 8-). > You could use an SCR but linear regulators are far, far better > (a little 3-pin TO92 package linear regulator). And linear regulators > have overcurrent protection as well (for themselves, not for whatever > is powering them). It's fairly difficult to blow one up. My SCR suggestion was based on the idea that you wanted to switch lots of volts/amps using Vcc chip levels to do it. THere are actually two threads here now: doing that, and lighting up a small number of LEDs (mention hardware projects, and the EE hobbiest wannabes come out of teh woodwork to ask for circuits... 8-)). Here is a good beginning parallel port project site: LED:http://www.free-hosting.lt/stech/lights/lights.htm Relay: http://www.armory.com/~rstevew/Public/Tutor/SolidStateRelaysDIY.txt Or a kit you can buy, with schematics: http://www.u-net.com/epr/electron/issue2/feat0302.htm Or more serious prebuilt stuff: http://www.lptek.com/io.htm And here is a wider selection, that has parallel port and serial port projects: http://ourworld.compuserve.com/homepages/Bill_Bowden/ ...and I'm disclaiming any responsibility, if you cook something with any of this... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Show me the light
Put a voltmeter on the PP port. Measure voltage. put am ammeter on the PP port. measure current. (start at 10 amps to be safe, trust me, you're not going to cause the ammeter any trouble). See if Voc and Isc are in a usable range. If not, go get yerself a little reed relay or solid state relay. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Show me the light
On Mon, 28 Oct 2002 [EMAIL PROTECTED] wrote: > As far as I remember, there is open collector output > on parallel port, so your wish impossible %-) oops, I forgot that little deal. Yup, you need a pullup. you can get PP relay modules for not much. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Show me the light
It seems Ronald G Minnich wrote: > On Mon, 28 Oct 2002 [EMAIL PROTECTED] wrote: > > > As far as I remember, there is open collector output > > on parallel port, so your wish impossible %-) > > oops, I forgot that little deal. Yup, you need a pullup. Only the control signals are OC, the databits are tri state. Actually, depending on how many databits one needs, the rest can be used to provide a usable powersupply when they are set to '1'. I use that for an 8chan AD converter that then fit into the parport plug housing and no need for an external power supply. But beware the current you can get this way is very limitted... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Show me the light
I have powered leds from the parallel port, there's about 10mA of current available on each data pin without destroying anything. so I wired 8 leds, each with a 330 ohm series resistor, no external power supply. Baldur On Sunday 27 October 2002 22:48, you wrote: > On Mon, 28 Oct 2002 [EMAIL PROTECTED] wrote: > > As far as I remember, there is open collector output > > on parallel port, so your wish impossible %-) > > oops, I forgot that little deal. Yup, you need a pullup. > > you can get PP relay modules for not much. > > ron > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Show me the light
Baldur Gislason wrote: > I have powered leds from the parallel port, there's about 10mA of current > available on each data pin without destroying anything. so I wired 8 leds, > each with a 330 ohm series resistor, no external power supply. Use 470 ohm; your chip will last longer with all bits lit. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Programming the Parallel Port using ppi.
I've updated the program to read as thus:
#include
#include
#include
#include
int main()
{
int fd;
u_int8_tval;
fd = open("/dev/ppi0", O_RDWR);
val = 0xff;
while(1)
{
ioctl(fd, PPISDATA, &val);
ioctl(fd, PPIGCTRL, &val);
val |= STROBE;
ioctl(fd, PPISCTRL, &val);
val &= ~STROBE;
ioctl(fd, PPISCTRL, &val);
}
}
I have tried to test the output of pins 2 through 9, with a voltmeter, using pin 25 as
the ground pin.
Nothing registered.
I tried again to use the LED, but that did not register anything as well.
I am thinking of putting a 1k ohm resister on the positive side of the LED.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Programming the Parallel Port using ppi.
In message <[EMAIL PROTECTED]>, David Nicholas Kayal cleopede: > val = 0xff; For this kind of testing, it is sometimes useful to use a value like 0xaa or 0x55, and probe the adjacent lines--don't forget that if there is inversion going on, 0xff will produce all 0v outputs. Just a random thought, it may not help here, but aa/ff are generally more useful than all 1's or all 0's. Greg Shenaut To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Programming the Parallel Port using ppi.
Shouldn't 0xff result in 5v outputs? On Sun, 27 Oct 2002, Greg Shenaut wrote: > In message <[EMAIL PROTECTED]>, >David Nicholas Kayal cleopede: > > val = 0xff; > > For this kind of testing, it is sometimes useful to use a value > like 0xaa or 0x55, and probe the adjacent lines--don't forget that > if there is inversion going on, 0xff will produce all 0v outputs. > Just a random thought, it may not help here, but aa/ff are generally > more useful than all 1's or all 0's. > > Greg Shenaut > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: i am looking for a 5 volt signal
> In anycase, I can only concur on the danger of ganging the parallel > power output bits. A single chip is driving those outputs and is > almost certainly not rated to deal with a maximal current draw from > all of them at once for long periods of time. It could fry. The output signals don't go straight from the chip - do they? I've seen few KOhms resistors on most boards for each output pin. 27.10.2002; 19:32:00 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Programming the Parallel Port using ppi.
In message <[EMAIL PROTECTED]>, David Nicholas Kayal cleopede: >Shouldn't 0xff result in 5v outputs? Sure, but in general you may get more information by using an alternating bit pattern (aa/55), that's all. Can you print from this port? Greg Shenaut To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Programming the Parallel Port using ppi.
I don't have a printer, so I am not sure. On Sun, 27 Oct 2002, Greg Shenaut wrote: > In message <[EMAIL PROTECTED]>, >David Nicholas Kayal cleopede: > >Shouldn't 0xff result in 5v outputs? > > Sure, but in general you may get more information by using an > alternating bit pattern (aa/55), that's all. > > Can you print from this port? > > Greg Shenaut > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Programming the Parallel Port using ppi.
In message: <[EMAIL PROTECTED]> David Nicholas Kayal <[EMAIL PROTECTED]> writes: : Shouldn't 0xff result in 5v outputs? Depends on of the pins are negative logic, now doesn't it :-) And most Parallel ports I've measured clock in at about 3.3V. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Increasing KVM
How exactly would I go about increasing KVM? I tried bumping up KVA_PAGES from 256 to 260, but all that did was cause page faults whenever apache (or fatboy, like in this case) was started... here's the error from /var/log/messages Oct 24 14:51:12 qt20 /kernel: Oct 24 14:51:12 qt20 /kernel: Oct 24 14:51:12 qt20 /kernel: Fatal trap 12: page fault while in kernel mode Oct 24 14:51:12 qt20 /kernel: mp_lock = 0002; cpuid = 0; lapic.id = Oct 24 14:51:12 qt20 /kernel: fault virtual address = 0xafcaae5c Oct 24 14:51:12 qt20 /kernel: fault code= supervisor write, page not present Oct 24 14:51:12 qt20 /kernel: instruction pointer = 0x8:0xb0257d11 Oct 24 14:51:12 qt20 /kernel: stack pointer = 0x10:0xe590ee40 Oct 24 14:51:12 qt20 /kernel: frame pointer = 0x10:0xe590ee4c Oct 24 14:51:12 qt20 /kernel: code segment = base 0x0, limit 0xf, type 0x1b Oct 24 14:51:12 qt20 /kernel: = DPL 0, pres 1, def32 1, gran 1 Oct 24 14:51:12 qt20 /kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Oct 24 14:51:12 qt20 /kernel: current process = 250 (fatboy) Oct 24 14:51:12 qt20 /kernel: interrupt mask= none <- SMP: XXX Oct 24 14:51:12 qt20 /kernel: trap number = 12 Oct 24 14:51:12 qt20 /kernel: panic: page fault Oct 24 14:51:12 qt20 /kernel: mp_lock = 0002; cpuid = 0; lapic.id = Oct 24 14:51:12 qt20 /kernel: boot() called on cpu#0 Oct 24 14:51:12 qt20 /kernel: Oct 24 14:51:12 qt20 /kernel: syncing disks... 15 3 I remember reading somewhere that NKPT should also be increased if you're going to fiddle with KVA_PAGES, is that true? Clearly there's something I'm not doing, I remember reading about people cranking KVA_PAGES up to 768. --Ian. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Programming the Parallel Port using ppi.
:Depends on of the pins are negative logic, now doesn't it :-) : :And most Parallel ports I've measured clock in at about 3.3V. : :Warner That sounds about right. I found a web page with the circuit for a TTL output. http://www.play-hookey.com/digital/electronics/ttl_gates.html If you go down to the bottom you'll see the circuit. A TTL 'high' is +5V through a 130 ohm resistor through a transitor (0.7V drop), through a diode (another 0.7V drop) = 5 - 1.4 = 3.6V, but it's actually less because there is current through the transistor, causing an additional drop through the 130ohm resistor. The real problem is the 130 ohm resistor. Each 1 mA you pull on the output will drop the voltage another 0.13V, which means you can't pull much current out of the output (and also that the output is nowhere near 5 volts even if you don't pull any current out of it). A TTL output is much better pulling to ground (sinking current rather then sourcing it). As you can see, when the output is a zero the bottom transistor is turned on and that is basically a direct connection to ground through a 0.7V drop, with no resistor (though there is an equivalent resistance due to the transitor), so TTL can pull down to 0.7V or so, usually at least 20mA. - Now, if this were a CMOS output you basically have two symmetrical FETs: http://www.play-hookey.com/digital/electronics/cmos_gates.html Which have an equivalent resistance of 50 ohms typically (well, the web page says 200 ohms but I think it's more around 50 for HCMOS). So a CMOS 1 is essentially 50 ohms to +V and a CMOS 0 is essentially 50 ohms to ground. This is the nice thing about CMOS... the lowest voltage is basically ground (not 0.7V), and the highest output voltage is basically +V (e.g. 5V rather then 3.3-3.6V). But a parallel port output is not a [H]CMOS output, it's a TTL output, which makes it a very poor power source. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Programming the Parallel Port using ppi.
On Sun, Oct 27, 2002 at 04:31:46PM -0800, David Nicholas Kayal wrote:
> #include
> #include
> #include
> #include
>
> int main()
> {
> int fd;
> u_int8_tval;
>
> fd = open("/dev/ppi0", O_RDWR);
> val = 0xff;
> while(1)
> {
> ioctl(fd, PPISDATA, &val);
> ioctl(fd, PPIGCTRL, &val);
> val |= STROBE;
> ioctl(fd, PPISCTRL, &val);
> val &= ~STROBE;
> ioctl(fd, PPISCTRL, &val);
> }
> }
You should really check your return values. The parallel port is not
writeable by default, so unless you've changed it, or are running as
root, your program is most likely failing to even open it, but you're
not noticing because you aren't checking your return codes.
-Brian
--
Brian Dean
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Increasing KVM
Ian Campbell wrote: > How exactly would I go about increasing KVM? I tried bumping up > KVA_PAGES from 256 to 260, but all that did was cause page faults > whenever apache (or fatboy, like in this case) was started... here's the > error from /var/log/messages [ ... ] > I remember reading somewhere that NKPT should also be increased if > you're going to fiddle with KVA_PAGES, is that true? Clearly there's > something I'm not doing, I remember reading about people cranking > KVA_PAGES up to 768. You only need to make additional changes if you are running a version of FreeBSD prior to 4.5; otherwise, just changing the KVA_PAGES should be enough. If you have a kernel where changing NKPT is relevent, then you are running a version before 4.5-RELEASE, and, and KVA_PAGES should have no effect whatsoever on the KVA size (it will be ignored, much as if you had used: option FRITZ_THE_CAT=260 (i.e. you can set any variable you want, and if no one looks at it, no one cares what you set it to). Prior to 4.6, Matt Dillon's autosizing patches had not yet been committed for KVA usage. On systems with large amounts of RAM, this meant that the amount of KVA space for page tables grew too large too quickly. Subsequent to the 4.6 release, there were additional changes for autotuning. Therefore you should be running at least 4.7-RELEASE, if you are messing with this at all. You haven't said whether you were running -current; everyone will assume that you are not, since you posted to the wrong mailing list for -current kernel issues (-hackers). One thing that would help is a traceback of why the fault was happening, which you haven't provided, since you only provided the fact that you were having a fault, and a meaningless address and other information, which is useless without the kernel and source code you are using. So first thing, you should get a system dump, run the debugger against a debug kernel image, and get a traceback. It will give you information which you will need to have for anyone to answer your question. My guess is that you are using up all available physical memory for backing KVA, and then crashing in a page fault attempting to trap to allocate physical backing pages for KVA space you've allocated for some reason, but have not yet used. This happens a lot these days in -current, because the wrong map is being used for preallocation of space with the new allocator (see -current list archived for recent patches for this, if you are running -current). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
