On Thu, 2004-01-01 at 03:09, Haidong Xia wrote:
> Hello, everyone,
>
> If the kernel already has a pci driver for a pci card, how could I load
> another loadable driver for the same card?
You'll need to recompile your kernel without the driver, because you
can't have two drivers attached to the
On Mon, 2003-09-22 at 07:03, Nicholas Holley wrote:
> I'm running an up to date version of Freebsd 5.1, and I'm having
> problems with my soundcard. I have an Asus a7n8x deluxe. The kernel has
> pcm support compiled in and the sound card works mostly, but
> occasionally the soundcard will not wo
On Mon, 2003-09-22 at 20:08, Toni Schmidbauer wrote:
> On Mon, Sep 22, 2003 at 01:40:56PM +, [EMAIL PROTECTED] wrote:
> > # cvsup -g -L 2 /root/ports-supfile
> > Parsing supfile "/root/ports-supfile"
> > Connecting to cvsup1.FreeBSD.org
> > Cannot connect to cvsup1.FreeBSD.org: Connection r
Sorry if this message was sent twice. My mailsystem failed to send the first message
(at least to the mailing list).
On Sunday 23 March 2003 20:16, Charlie Schluting wrote:
> I was wondering if anyone could help:
> I'm using 5.0, and I just updated src-base and src-all with cvs.
>
> The make com
umbers and when asked generate a login password...
>
> Thanks
>
This C program will generate random passwords.
/* Copyright (C) Jan-Espen Pettersen
* This software is distributed WITHOUT ANY WARRANTY
*/
#include
#include
#include
int main()
{
int min_lenght = 8;
int max_lenght =
On Monday 24 March 2003 07:24, you wrote:
> On Mon, 2003-03-24 at 00:04, Jan-Espen Pettersen wrote:
> > This C program will generate random passwords.
> > ...
> > int main()
> > {
> > int min_lenght = 8;
> > int max_lenght = 30;
&g
Here is a workaround:
In printers.conf () you will probably find a line like this:
DeviceURI usb:/dev/ulpt0
change usb: to file:, so that it looks something like this:
DeviceURI file:/dev/ulpt0
Then restart cups. Cups will not read any status information from the
printer, but at least it can print.
> Here is a workaround:
>
> In printers.conf () you will probably find a line like this:
>
> DeviceURI usb:/dev/ulpt0
>
> change usb: to file:, so that it looks something like this:
>
> DeviceURI file:/dev/ulpt0
>
> Then restart cups. Cups will not read any status information fr
> The problem is that read operations on usb printers might just
> block/hang with no data from the printer (?). ulpt doesn't have
> non-blocking I/O, so I've made a patch that simply times out read
> operations, and disables further reads if it detects a blocking/stall
> condition. It is possible
sure that either the cups user or cups group has read
and write access to /dev/ulpt0.
I think most people use permissions like: root:cups 0660 (-rw-rw----).
Jan-Espen Pettersen
signature.asc
Description: OpenPGP digital signature
Rainer Heesen wrote:
> the permissions of /dev/ulp* are:
>
> crw-rw 1 root cups0, 169 Jul 3 20:35 /dev/ulpt0
> crw-rw 1 root cups0, 170 Jul 3 20:35 /dev/unlpt0
>
> the directory /var/cache/cups is group writable
>
> when I start a print job I get the message
>
> print
Rainer Heesen wrote:
> [EMAIL PROTECTED] ~# echo test > /dev/ulpt0
> bash: /dev/ulpt0: Device busy
>
> so I think it is not a cups problem, but what kind of program make the usb
> device busy?
>
It can't be any other program if fstat is not reporting anything. I've
been reading on the usb print
12 matches
Mail list logo
