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
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);
: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 y
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:
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 [EM
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'
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 PROTECT
> 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 s
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 th
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,
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;
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
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
>
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 be
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 PRO
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
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 PROTE
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.
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, dummy
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
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.
--
> 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
:
: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
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 pin
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 Th
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
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 fulf
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 ultima
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
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.${DEVN
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/$
:
: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 rel
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 multiplex
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
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 p
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 <[EMA
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,
* 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 keve
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
* 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 ty
40 matches
Mail list logo
