On Jun 28, Roger Leigh [EMAIL PROTECTED] wrote:
rleigh Kamion: Don't other parport users get different device nodes and
names? I'll check.
Yes, some doorstop architectures do. Look at the aliases in the
module-init-tools source package.
Kamion I also disagree with Henrik; if it's possible
Terve Martin,
I have seen the other messages (discover, ...) but I want to answer this mail
anyway.
If you don't have udev installed, install it. It should find 'lp' and
load it automatically at bootup, on hardware that has a parallel port.
udev 0.093-1 is installed.
If udev is already
ke, 2006-06-28 kello 07:54 +0200, Ronny Standtke kirjoitti:
I have seen the other messages (discover, ...) but I want to answer this mail
anyway.
How do I get the udev bootup output? What else (discover, ...) can I test to
help fixing this bug?
As pointed out by Henrique and Marco, udev
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
The parallel port itself is in either PnP or ACPI tables, so the kernel
notices it exists and fires up an coldplug event. Udev knows to load
parport_pc in that case. In fact all udev autodetection works like this:
it is kernel
ke, 2006-06-28 kello 11:26 +0100, Roger Leigh kirjoitti:
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
If you need lp, you either load it in through discover (which, unlike
udev, has the task of finding out all high and low-level drivers that should
be loaded in a system), load it
On Wed, 28 Jun 2006, Roger Leigh wrote:
I just installed discover on my i386 test system, and it didn't load
lp. I rebooted it to see what happened at startup, and it didn't load
lp then, either.
Please file a bug against discover, it has to auto-detect the need for lp
and other very common
On Wed, 28 Jun 2006, Martin-Éric Racine wrote:
We have too many hardware detection layers and none of them able to see
the full picture. Even worse, as witnessed in this particular case, they
all fail at detecting something as simple as the printer driver.
Anyhow, udev and discover duplicate
On Wed, 28 Jun 2006, Martin-Éric Racine wrote:
I have seen the other messages (discover, ...) but I want to answer this
mail
anyway.
How do I get the udev bootup output? What else (discover, ...) can I test
to
help fixing this bug?
As pointed out by Henrique and Marco, udev
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
On Wed, 28 Jun 2006, Roger Leigh wrote:
I just installed discover on my i386 test system, and it didn't load
lp. I rebooted it to see what happened at startup, and it didn't load
lp then, either.
Please file a bug against discover, it
ti, 2006-06-27 kello 18:25 +0200, Ronny Standtke kirjoitti:
Thank you very much. It was the missing lp module. I really wonder why my
printer was working all the time before. I am just a constantly
upgrading testing user. Who knows...
If you don't have udev installed, install it. It should
ti, 2006-06-27 kello 22:54 +0100, Roger Leigh kirjoitti:
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
On Tue, 27 Jun 2006, Henrique de Moraes Holschuh wrote:
Sorry, I didn't notice it was being forwarded to udev. I am reopening the
bug...
IMHO it is a udev issue. On an i386
At Tue, 27 Jun 2006 22:54:30 +0100,
Roger Leigh wrote:
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
On Tue, 27 Jun 2006, Henrique de Moraes Holschuh wrote:
Sorry, I didn't notice it was being forwarded to udev. I am reopening the
bug...
IMHO it is a udev issue. On an i386
On Wed, 28 Jun 2006, Kenshi Muto wrote:
IMHO it is a udev issue. On an i386 unstable system I've just
checked, it's loading parport and parport_pc, but not lp. This is a
bog standard PIII with an Intel 440BX chipset. It must have detected
the parallel port in order to load the parport
13 matches
Mail list logo
