Re: future libc6-sparcv9 and libc6-sparcv9b support

[David S. Miller]

From: Jakub Jelinek <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 06:53:36 -0400

> Do you remember when we talked about how pre-v9 support could be done,
> including fast mutex support (for mutexes NPTL uses just 0/1/2 values
> of the futexes and does atomic ops on them, so sticking a ldstub lock
> in the MS byte would work).

Yes I do, but I've lost all time to work on this.  And I see
no opportunity in the future.

> Do we need sparcv[78] NPTL programs being able to use process shared
> synchronization primitives with sparcv{9,64} NPTL programs, or is it
> enough when just sparcv[78] programs can talk together and sparcv{9,64}
> together?

I think the restriction is reasonable, and that's the way to go.

I was working on a way that would allow sharing, but the currently
layout of the glibc NPTL sources does not allow to override enough
of the implementation to pull it off.  I was going to put a spinlock
into the semaphore structure, and stuff like that, for example.  This
kind of approach would not have slowed down v9+/sparc64 much at all.

I really wanted to pursue things that way, just use ldstub for all
this stuff, but Ulrich would probably dislike it when he sees how much
stuff would need to be moved into sysdep/* overridable areas.  Every
change to semaphores generically would require some sparc updates, for
example.

Lack of an atomic word compare and swap makes current glibc development
incredibly painful.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: future libc6-sparcv9 and libc6-sparcv9b support

[David S. Miller]

From: GOTO Masanori <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 19:51:45 +0900

> Well, we sometimes meet words "optimization makes faster", but we
> merely see the actual result of performance gain.
> How much is the improvement of such optimized packages?  Is sparcv9b
> valuable compared with sparcv9?

Yes, because the optimized memcpy/memset in the sparcv9 package
is severely suboptimal for UltraSPARC-III and later chips, which
is what the sparcv9b package is needed for.

>  From your suggestion, normal libc6 package (that's also usable for
> pre sparcv9 archs) does not have any NPTL support, but libc6-sparcv9
> (and v9b) can have NPTL support.  IIRC, you have worked for 64bit NPTL
> support on sparc, so I expect libc6-sparc64 will be able to support
> NPTL without hassle.

Right.

> BTW, if we move to glibc 2.4 series in future, at that time we may
> need to drop LT support.  It means the traditional pre sparcv9 system
> will be also dropped.  Is that acceptable direction for sparc users?
> (Note that dropping LT is not decided and I think we shouldn't do so
> currently).

Right, it will be necessary.  To be honest, pure traditional sparc 32-bit
support is a real roadblock to progress in any of these areas.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUN Enterprise 3000

[Tyler]

You can also try a Woody install CD.

Tyler.

Frank F. Waarsenburg wrote:


Hi,

recently I bought a SUN Enterprise 3000, with only a serial interface
for console connections. I tried both the RedHat ZOOT (quite old) and
the debian 31r0a distributions, but both terminate with the same
problem: unable to mount the CDRom (where it just booted from...) Looks
like the scsi interface is not recognized. Any suggestions how to
continue from here? (other than getting Solaris10)

Frank


 




--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.12/77 - Release Date: 8/18/2005


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Enterprise 4000 setup

[Tyler]

Something "simple" (but seems silly and needless, since they should be 
able to find a fix, and release an updated (sarge) iso), try using a 
Woody install CD.


Tyler.

Bryan Schmidt wrote:

I am trying to setup an Enterprise 4000 server with 4 (166Mhz) CPU’s 
and 1Gb memory but I cannot even get the setup kernel to start. I do 
“boot cdrom” and get the following error.


Allocated 8 megs of memory at 0x4000 for kernel

Loading kernel version 2.4.27

Loading initial ramdisk (3041649 bytes at 0x470 phys, 0x40C virt)…

-

Remapping kernel… Illegal instruction

….and drops out to the OpenBoot prompt

I have installed with no problems using the same CD’s on a U2 with 
dual 300 Mhz CPU’s. Runs GREAT by the way Thanks to all the people 
ported to Sparc!


Thanks,

Bryan Schmidt

Systems Engineer

Area101, Inc.

9800 Mount Pyramid Court

Suite 400

Englewood, CO 80112

*www.area101.com *




--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.12/77 - Release Date: 8/18/2005


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Enterprise 4000 setup

[Romain Dolbeau]

Bryan Schmidt <[EMAIL PROTECTED]> wrote:

> I am trying to setup an Enterprise 4000 server with 4 (166Mhz) CPU's and
> 1Gb memory but I cannot even get the setup kernel to start.  I do "boot
> cdrom" and get the following error.
> 
> Allocated 8 megs of memory at 0x4000 for kernel
> Loading kernel version 2.4.27
> Loading initial ramdisk (3041649 bytes at 0x470 phys, 0x40C
> virt)...
> Remapping kernel... Illegal instruction

Could be anything, from unsupported to faulty hardware. I'd give a shot
at shuffling memory around, to see if one or more stick are faulty.
Also, try a complete HW check in the prom (there used to be a 'test-all'
command in the openboot console, maybe it's available on the E4000 ?)

good luck,

-- 
Romain Dolbeau
<[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Enterprise 4000 setup

[Bryan Schmidt]

Does anyone have an idea what could be wrong?  Thanks

 



Bryan Schmidt,

Systems Engineer



Area101, Inc.





9800 Mount Pyramid Court





Suite 400





Englewood, CO 80112





Office:: 303-708-9399





Fax: 303-708-8903



www.area101.com



 

Re: Re: Sarge and FFB video

[Bryan Schmidt]

Thank All,

 

I switched to the sunffb drivers abd the problem was
resolved.

 

Thanks

 



Bryan Schmidt

Systems Engineer



Area101, Inc.





9800 Mount Pyramid Court





Suite 400





Englewood, CO 80112





Office:: 303-708-9399





Fax: 303-708-8903



www.area101.com



 

Re: SUN Enterprise 3000

[Ben Collins]

This is exactly the case, and is exactly how I had to install my E3000.

On Thu, Aug 18, 2005 at 05:36:00PM +0200, Romain Dolbeau wrote:
> > Yes, I could. But that does not solve the problem. If the scsi drivers are
> > not available within Debian, it is never going to recognize the disks - as
> > is the case already. And will complain that there is no device to write
> > to. So, any help is appreciated.
> 
> During netboot (don't know about cdrom boot), SCSI drivers are not
> present in the loaded image, but are loaded afterward from the http
> source (or ftp source, or whatever). This is the case for the extremely
> common esp driver (used on almost all sun4c and sun4m machine, and some
> sun4u).
> 
> Maybe the SCSI driver you need would also be available in this manner,
> even if it's not present in the default kernel on cdrom.
> 
> -- 
> Romain Dolbeau
> <[EMAIL PROTECTED]>
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 
Ubuntu - http://www.ubuntu.com/
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
SwissDisk  - http://www.swissdisk.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUN Enterprise 3000

[Romain Dolbeau]

> Yes, I could. But that does not solve the problem. If the scsi drivers are
> not available within Debian, it is never going to recognize the disks - as
> is the case already. And will complain that there is no device to write
> to. So, any help is appreciated.

During netboot (don't know about cdrom boot), SCSI drivers are not
present in the loaded image, but are loaded afterward from the http
source (or ftp source, or whatever). This is the case for the extremely
common esp driver (used on almost all sun4c and sun4m machine, and some
sun4u).

Maybe the SCSI driver you need would also be available in this manner,
even if it's not present in the default kernel on cdrom.

-- 
Romain Dolbeau
<[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: future libc6-sparcv9 and libc6-sparcv9b support

[Ben Collins]

> Thanks for your precious follow up.
> 
>  From your suggestion, normal libc6 package (that's also usable for
> pre sparcv9 archs) does not have any NPTL support, but libc6-sparcv9
> (and v9b) can have NPTL support.  IIRC, you have worked for 64bit NPTL
> support on sparc, so I expect libc6-sparc64 will be able to support
> NPTL without hassle.
> 
> BTW, if we move to glibc 2.4 series in future, at that time we may
> need to drop LT support.  It means the traditional pre sparcv9 system
> will be also dropped.  Is that acceptable direction for sparc users?
> (Note that dropping LT is not decided and I think we shouldn't do so
> currently).

IMO, sparc32 should soon go the way of 386 and m68k support. Yes,
supporting these machines is nice, but there just aren't many people
supporting them upstream (which makes it harder for Debian to do so).
AFAIK, there is only one krnel hacker trying to get sparc32 to remain in a
working state.

When that happens there will only be libc6 package (with standard v9
optimization), and v9b optimized packages. The 64-bit package will never
go away.

You guys can decide when and if to do this.

-- 
Ubuntu - http://www.ubuntu.com/
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
SwissDisk  - http://www.swissdisk.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: future libc6-sparcv9 and libc6-sparcv9b support

[Ben Collins]

v9 is probably the most used optimized package. We cannot drop it. v9b is
used less, but it is still very important.

On Thu, Aug 18, 2005 at 02:07:28PM +0900, GOTO Masanori wrote:
> Hi,
> 
> I have a question about optimization package: libc6-sparcv9 and
> libc6-sparcv9b.  Both packages are prepared for optimized versions of
> libc6.  They are currently supported - but I would like to know what
> the advantage of those packages is.  Just optimization?  Are those
> packages widely used?
> 
> These days 2.6 kernel is getting popularity, so it's nice time to
> support NPTL on sparc systems.  But having a lot of optimized packages
> and variants like NPTL take much longer build time + maintenance cost.
> If we replace unpopular optimized libc6 packages with NPTL libc6 in
> future, it's much valuable for users, I think.
> 
> How about to drop libc6-sparcv9/sparcv9b and introduce NPTL-enabled
> libc6 in future?
> 
> Regards,
> -- gotom
> 

-- 
Ubuntu - http://www.ubuntu.com/
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
SwissDisk  - http://www.swissdisk.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SUN Enterprise 3000

[Romain Dolbeau]

Frank F. Waarsenburg <[EMAIL PROTECTED]> wrote:

> recently I bought a SUN Enterprise 3000, with only a serial interface for
> console connections. I tried both the RedHat ZOOT (quite old) and the
> debian 31r0a distributions, but both terminate with the same problem:
> unable to mount the CDRom (where it just booted from...) Looks like the
> scsi interface is not recognized. Any suggestions how to continue from
> here? (other than getting Solaris10)

You can try to netboot. On Sun hardware it's fairly easy, in particular
if you have another Debian system on the local network, as debian
packages everything required. You only need to configure the bootp
server (it's in the doc) and the tftp server (it's in the doc too).

good luck,

-- 
Romain Dolbeau
<[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

SUN Enterprise 3000

[Frank F. Waarsenburg]

Hi,

recently I bought a SUN Enterprise 3000, with only a serial interface
for console connections. I tried both the RedHat ZOOT (quite old) and
the debian 31r0a distributions, but both terminate with the same
problem: unable to mount the CDRom (where it just booted from...) Looks
like the scsi interface is not recognized. Any suggestions how to
continue from here? (other than getting Solaris10)

Frank

Re: future libc6-sparcv9 and libc6-sparcv9b support

[GOTO Masanori]

At Thu, 18 Aug 2005 12:58:58 +0200,
Christoph Hellwig wrote:
> I think m68k has no nptl either, and as m68k are a very vocal minority
> you'll have more flames about that ;-)
> 
> Let's try to get NPTL working on 2.3 with all supported architectures
> first, that's been long overdue - long term dropping LT is the only
> choice, but that'll need a lot more flamewars first unfortunately.

Exactly... your point makes much sense.  We should talk with Andreas
Schwab.

Regards,
-- gotom


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RE: Deb on Sparc Station 5

[Martin]

On Mon, 2005-08-15 at 09:20 +0100, Richard Mortimer wrote:
> Ok, so you say that it asks for a password after doing stop-A. That's
> probably typical of University machines because it makes it harder for
> students/staff bypassing privileges. 
> 
> As someone else said the easiest is probably to zap the OBP settings by
> playing with the contents of the device outside of the machine.
> 
> Failing that you need to get logged in a root on the existing OS (Solaris I
> presume) and then you can reset the password/security settings using the
> eeprom command.
Alternatively if you can put a suitable kernel & root image where it
expects to boot from (with security set up it was only intended to boot
from one place - often network) then you can use the Linux OpenPROM
filesystem and read the password setting out of the PROM as it is stored
unencrypted.

HTH

Cheers,
 - Martin



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: future libc6-sparcv9 and libc6-sparcv9b support

[Christoph Hellwig]

On Thu, Aug 18, 2005 at 07:51:45PM +0900, GOTO Masanori wrote:
> BTW, if we move to glibc 2.4 series in future, at that time we may
> need to drop LT support.  It means the traditional pre sparcv9 system
> will be also dropped.  Is that acceptable direction for sparc users?
> (Note that dropping LT is not decided and I think we shouldn't do so
> currently).

I think m68k has no nptl either, and as m68k are a very vocal minority
you'll have more flames about that ;-)

Let's try to get NPTL working on 2.3 with all supported architectures
first, that's been long overdue - long term dropping LT is the only
choice, but that'll need a lot more flamewars first unfortunately.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: future libc6-sparcv9 and libc6-sparcv9b support

[Jakub Jelinek]

On Thu, Aug 18, 2005 at 02:39:23AM -0400, David S. Miller wrote:
> > These days 2.6 kernel is getting popularity, so it's nice time to
> > support NPTL on sparc systems.  But having a lot of optimized packages
> > and variants like NPTL take much longer build time + maintenance cost.
> > If we replace unpopular optimized libc6 packages with NPTL libc6 in
> > future, it's much valuable for users, I think.
> > 
> > How about to drop libc6-sparcv9/sparcv9b and introduce NPTL-enabled
> > libc6 in future?
> 
> You'll only get NPTL to work on sparcv9 and later anyways.
> Pure traditional sparc 32-bit NPTL is non-functioning even
> in the current glibc tree.  And I doubt there is much incentive
> to write the support.

Well, there is some, as LinuxThreads has been removed from upstream glibc.
So supporting or not supporting NPTL equals to supporting or not supporting
pre-v9 CPUs at all.

Do you remember when we talked about how pre-v9 support could be done,
including fast mutex support (for mutexes NPTL uses just 0/1/2 values
of the futexes and does atomic ops on them, so sticking a ldstub lock
in the MS byte would work).  The only major problem is the process shared
synchronization.  That is dependent on an important decision.
Do we need sparcv[78] NPTL programs being able to use process shared
synchronization primitives with sparcv{9,64} NPTL programs, or is it
enough when just sparcv[78] programs can talk together and sparcv{9,64}
together?  Here for dynamically linked programs sparcv[78] programs
mean 32-bit programs dynamically linked with a sparcv[78] compiled glibc.
If interoperation between pre-v9 and v9+ NPTL is needed, then we'd need
to slow v9+ NPTL down a little bit, if it is not, perhaps pre-v9
libpthread.a could have all atomicity stuff dependent on some is_v9
variable that would be set in the constructors depending on what CPU
it is running on.

Jakub


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: future libc6-sparcv9 and libc6-sparcv9b support

[GOTO Masanori]

At Thu, 18 Aug 2005 02:39:23 -0400 (EDT),
David S. Miller wrote:
> > I have a question about optimization package: libc6-sparcv9 and
> > libc6-sparcv9b.  Both packages are prepared for optimized versions of
> > libc6.  They are currently supported - but I would like to know what
> > the advantage of those packages is.  Just optimization?  Are those
> > packages widely used?
> 
> Besides being compiled with the proper optimization and feature
> options, they use memcpy and memset implementations which are
> several orders of magnitude faster than plain Sparc versions.
> 
> Every single UltraSPARC debian system I have has these special
> versions of the library installed.  You can feel the difference
> these libraries make, performance wise, in many cases.

Well, we sometimes meet words "optimization makes faster", but we
merely see the actual result of performance gain.
How much is the improvement of such optimized packages?  Is sparcv9b
valuable compared with sparcv9?

> > These days 2.6 kernel is getting popularity, so it's nice time to
> > support NPTL on sparc systems.  But having a lot of optimized packages
> > and variants like NPTL take much longer build time + maintenance cost.
> > If we replace unpopular optimized libc6 packages with NPTL libc6 in
> > future, it's much valuable for users, I think.
> > 
> > How about to drop libc6-sparcv9/sparcv9b and introduce NPTL-enabled
> > libc6 in future?
> 
> You'll only get NPTL to work on sparcv9 and later anyways.
> Pure traditional sparc 32-bit NPTL is non-functioning even
> in the current glibc tree.  And I doubt there is much incentive
> to write the support.
> 
> Only sparcv9 and later work with NPTL, and since it requires TLS this
> means current CVS binutils is necessary as well especially if you wish
> to build 64-bit NPTL enabled glibc on sparc as well.

Thanks for your precious follow up.

 From your suggestion, normal libc6 package (that's also usable for
pre sparcv9 archs) does not have any NPTL support, but libc6-sparcv9
(and v9b) can have NPTL support.  IIRC, you have worked for 64bit NPTL
support on sparc, so I expect libc6-sparc64 will be able to support
NPTL without hassle.

BTW, if we move to glibc 2.4 series in future, at that time we may
need to drop LT support.  It means the traditional pre sparcv9 system
will be also dropped.  Is that acceptable direction for sparc users?
(Note that dropping LT is not decided and I think we shouldn't do so
currently).

Regards,
-- gotom


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remote printing from a Solaris box to a remote Debian-CUPS server (SOLVED)

[F. Kappen]

Richard Mortimer wrote:

> You might also want to look in /var/log/lpr.log
>
> > -Original Message-
> > From: Steffan Baron [mailto:[EMAIL PROTECTED]
> >
> > Does the access_log of your cups server say anything about
> > the connection from your solaris box? What about the error_log?
> >

Thank you very much, Richard and Steffan you pointed me to the right
direction. I feel rather ashamed and still cannot believe how stupid I
am. But I learned a lot about printing and networking. Without your
precious help, however, I wouldn't have succeeded. The point was: I
named the printer on Debian-system "ljet4p", but called the print queue
on SolarisBox "rljet4p". A look in "/var/log/lpr.log" on Debian-system
clarified the situation (thanks to Richard).

Debian-system:# tail -f /var/log/lpr.log
Aug 18 10:14:50 Debian-system cups-lpd[540]: Connection from
SolarisBox.meineDomaene.de ()
Aug 18 10:14:50 Debian-system cups-lpd[540]: Receive print job for
rljet4p
Aug 18 10:14:51 Debian-system cups-lpd[540]: Unknown destination
rljet4p!
Aug 18 10:14:51 Debian-system cups-lpd[540]: Closing connection

A change of the print queue name from "rlet4p" to "ljet4p" remedied the
defects. Now, all works just fine and I am happy.

During browsing the net I came across an article that shed some light on
the printing mechanism of the Solaris OS:

 http://developers.sun.com/solaris/articles/basicprinting.html

Although it wasn't useful for my problem, I consider it quite
instructive.

Again, thanks a lot

Cheers
Friedhelm



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Remote printing from a Solaris box to a remote Debian-CUPS server

[F. Kappen]

Steffan Baron wrote:

> >
> >thank you very much. That helped a lot and things are now clearer to me. I
> >followed your advices and after a "dpkg-reconfigure cupsys-bsd" , a "apt-get
> >install telnetd" and numerous trials with "update-inetd" and "telnet" I came
> >to the point, where I could establish a telnet connection from "SolarisBox" 
> >to
> >"Debian-system":
> >
> >SolarisBox > telnet Debian-system 515
> >Trying  ...
> >Connected to SolarisBox
>
> Shouldn't this be 'Debian-system' as well?

Yes,  of course, you are right. Sorry for the typo.

>
>
> >Unfortunately printing still doesn't work. That's frustrating and I'm rather
> >pointless at the moment. So I have to dig deeper into the subject.
>
> Does the access_log of your cups server say anything about the
> connection from your solaris box? What about the error_log?
>

The output from "access_log" gives no meaningful hint.
Debian-system:# tail /var/log/cups/access_log
localhost - - [17/Aug/2005:16:03:19 +0200] "POST / HTTP/1.1" 200 163
localhost - - [17/Aug/2005:16:14:59 +0200] "POST / HTTP/1.1" 200 163
localhost - - [18/Aug/2005:09:43:28 +0200] "POST / HTTP/1.1" 200 163
localhost - - [18/Aug/2005:10:00:46 +0200] "POST / HTTP/1.1" 200 137
localhost - - [18/Aug/2005:10:00:46 +0200] "POST / HTTP/1.1" 200 137

Whereas the output from "error-log" contains a line that I can not interpret:

Debian-system:# tail -f /var/log/cups/error-log
I [17/Aug/2005:16:18:45 +0200] Scheduler shutting down normally.
I [18/Aug/2005:09:22:22 +0200] Listening to 0:631
I [18/Aug/2005:09:22:22 +0200] Loaded configuration file "/etc/cups/cupsd.conf"
I [18/Aug/2005:09:22:22 +0200] Configured for up to 100 clients.
I [18/Aug/2005:09:22:22 +0200] Allowing up to 100 client connections per host.
I [18/Aug/2005:09:22:22 +0200] Full reload is required.
I [18/Aug/2005:09:22:28 +0200] LoadPPDs: Read "/etc/cups/ppds.dat", 2749 PPDs...
I [18/Aug/2005:09:22:32 +0200] LoadPPDs: No new or changed PPDs...
I [18/Aug/2005:09:22:32 +0200] Full reload complete.
E [18/Aug/2005:09:43:28 +0200] get_printer_attrs: resource name
'/printers/rljet4p' no good!

^

Thank you Steffan

Cheers
Friedhelm


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]