headers
Rafal Boni | 1 Dec 2002 02:28
Picon

Re: Printing to LPT0 - Sun Ultra 5 - sparc64

In message <000501c29374$07394b80$6601a8c0 <at> caldwell>, you write: 

-> Is printing to the parallel port (lpt0) supported in NetBSD sparc64 - on a
-> Sun Ultra 5?

So I tried after Martin's addition of the lpt driver major numbers to the
system, and get the following results:
	(1) Using /dev/lpa0: nothing seem on printer, haven't yet hooked 
	    up the breakout box to see if signals are being twiddled or 
	    not; the printing job looks like it thinks it's done quite
	    quickly.

	(2) Using /dev/lpt0: printer starts up and makes some noises, looks
	    like it's going to print but never[*] gets to the point of 
	    producing any output.

On my x86 system, I used the interruptless (/dev/lpa0) device without any
serious problems; the only difference here is the machine driving the HP
and the printer cable (can't find old one, bought a new "Belkin IEEE1284
Pro" cable).  I haven't yet tried the old x86 system with the new cable
to confirm that it's the Ultra5 (in either HW or SW) and not the cable.

I'm going to poke some more, maybe add some tracing to the driver to try
and figure out what's up, maybe later this weekend...

--rafal

[*] I'm impatient, so after a couple of minutes I gave up 8-)

----
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rafal Boni | 2 Dec 2002 23:18
Picon

Re: Printing to LPT0 - Sun Ultra 5 - sparc64

[...Following up to myself...]

In message <200212010128.gB11Srd12639 <at> fearless-vampire-killer.waterside.net>,
I wrote thusly:

-> In message <000501c29374$07394b80$6601a8c0 <at> caldwell>, you write: 
-> 
-> -> Is printing to the parallel port (lpt0) supported in NetBSD sparc64 - on 
-> a
-> -> Sun Ultra 5?
-> 
-> So I tried after Martin's addition of the lpt driver major numbers to the
-> system, and get the following results:
-> 	(1) Using /dev/lpa0: nothing seem on printer, haven't yet hooked 
-> 	    up the breakout box to see if signals are being twiddled or 
-> 	    not; the printing job looks like it thinks it's done quite
-> 	    quickly.

This appears to be a timing issue, as the driver actually believes that
all the bytes have been pushed out.  I noticed there are some DELAY(1)'s
in the lpt.c code and recall that a few ports had off-by-one errors in 
their DELAY() macros or delay() functions so a DELAY(1) was in effect a
no-op... I'll check this out, but otherwise it looks like it's going to
have to be down-and-dirty tweaking until things work.

-> 	(2) Using /dev/lpt0: printer starts up and makes some noises, looks
-> 	    like it's going to print but never[*] gets to the point of 
-> 	    producing any output.

Here, the problem is that no interrupts are generated.  I didn't have the
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Nemeth | 4 Dec 2002 21:14
Picon
Favicon

OpenBSD vs. Sun

     Apparently, there has been a kerfluffle between Theo and Sun, with
Theo claiming that Sun won't give him the information needed to make
OpenBSD run on machines with Ultrasparc III processors.  See:

http://cl.com.com/Click?q=15-mYZ_IGcsljJcKthtkAUsEZG37dRR

     I'm wondering where NetBSD stands in this picture.  Do we have the
needed information?  Do we support any of the newer machines?
Permalink | Reply | 3 comments |
headers
Martin Husemann | 4 Dec 2002 21:32
Picon

Re: OpenBSD vs. Sun

On Wed, Dec 04, 2002 at 12:14:52PM -0800, John Nemeth wrote:

>      I'm wondering where NetBSD stands in this picture.  Do we have the
> needed information?  Do we support any of the newer machines?

We do not have that information and don't support UltraSparc III or III+
machines.

We did contact SUN about this (friendly & polite) and did receive an 
encouraging response. Nothing concrete has happened yet.

Martin
Permalink | Reply | 2 comments |
headers
Matt Fredette | 5 Dec 2002 20:48
Picon

softintr(9) patch


Hi.  While doing some MI device driver work I noticed that sparc's
softintr(9) implementation needs some fleshing out - currently,
softintr_establish() registers everything at priority level 1.
To get anything different you have to go outside softintr(9) and
use bus_intr_establish() and do a raise() or ienab_bis() by hand.

The following patch makes sparc's softintr(9) more universal and 
does away with BUS_INTR_ESTABLISH_SOFTINTR.  

ftp://ftp.netbsd.org/pub/NetBSD/misc/fredette/sparc-softintr.diff

I compiled and booted a GENERIC with this on my SS20, but the only
softintr-using things it has are the zs'es, softclock, and softnet, 
which seem fine.  The changes were more mechanical than not; still, 
I'd appreciate others testing amdaudio, fd, and especially sun4/sun4c.

This patch also removes BUS_INTR_ESTABLISH_SOFTINTR from sparc64.
sparc64 already has a full softintr(9), so those changes were minimal.
I compiled a sparc64 GENERIC but don't have any sparc64 hardware.

Comments and/or "ok to commit" welcome.  Thanks!

--

-- 
Matt Fredette
Permalink | Reply | 0 comments |
headers
Jason Wright | 5 Dec 2002 23:12

Re: OpenBSD vs. Sun

On Wed, Dec 04, 2002 at 09:32:51PM +0100, Martin Husemann wrote:
> We did contact SUN about this (friendly & polite) and did receive an 
> encouraging response. Nothing concrete has happened yet.
> 
So did we (OpenBSD), many months ago.  Sun is pretty good at
giving encouraging responses, but not at producing anything useful.

--Jason L. Wright
Permalink | Reply | 0 comments |
headers
Jason R Thorpe | 6 Dec 2002 00:12

Re: OpenBSD vs. Sun

On Wed, Dec 04, 2002 at 09:32:51PM +0100, Martin Husemann wrote:

 > We do not have that information and don't support UltraSparc III or III+
 > machines.
 > 
 > We did contact SUN about this (friendly & polite) and did receive an 
 > encouraging response. Nothing concrete has happened yet.

Probably some progress could be made if we (that is, NetBSD developers
who would do this work) offered to sign the NDA, under the same terms
that the Linux people got (i.e. "can release source code").  This might
save them a lot of hassle.

There is precendence for doing this -- e.g. I have an NDA with Intel
that allows me to see documentation on their Gigabit Ethernet stuff.
I am allowed to release source code for the drivers, but I am not allowed
to give a copy of the documentation to anyone else.  This suits me
just fine.

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
Permalink | Reply | 0 comments |
headers
Rick Kelly | 6 Dec 2002 02:00

Re: U5 + 1.6 + tar anomaly

Andrey Petrov said:

>It'd be very interesting to know if this problem exists in -current.
>Can you give it a try?

>Also is there any visible pattern in corrupted data? Like last xxx bytes
>of block, first xxx bytes of page?

I'm now running:

NetBSD sidewinder 1.6_STABLE NetBSD 1.6_STABLE (SIDEWINDER) #1: Sat Nov 23 15:34:35 MST 2002    
rmk <at> sidewinder:/usr/src/sys/arch/sparc64/compile/SIDEWINDER sparc64

Doing a "tar | tar" from the IDE disk to the SCSI disk now works without
error. Looks like something was pulled up that fixed the "bug".

--

-- 
Rick Kelly  rmk <at> rmkhome.com  www.rmkhome.com
Permalink | Reply | 0 comments |
headers
matthew green | 6 Dec 2002 03:28
Picon
Favicon

re: softintr(9) patch


   Comments and/or "ok to commit" welcome.  Thanks!

+#define AUDIO_SET_SWINTR softintr_schedule(sc->sc_sicookie)

"yuck"  don't use local variables in macros.  same here:

+#define FD_SET_SWINTR softintr_schedule(fdc->sc_sicookie)       

make softintr_priority() an inline function or macro?  seems a waste of a
function call ...

i think the magma driver needs to be tested before this is commited, as well.

.mrg.
Permalink | Reply | 0 comments |
headers
Paul Kranenburg | 6 Dec 2002 11:19
Picon

Re: softintr(9) patch

> Hi.  While doing some MI device driver work I noticed that sparc's
> softintr(9) implementation needs some fleshing out - currently,

It sure does.

> ...
> 
> Comments and/or "ok to commit" welcome.

Please hold on. I'm working on this and some more interrupt handling
related issues. I'll fetch your patch and integrate it. Thanks!

-pk
Permalink | Reply | 0 comments |

Gmane