Re: p9100 bug?

Hello,

On Feb 28, 2010, at 1:28 PM, der Mouse wrote:

> sys/dev/sbus/p9100.c (1.34) includes a macro PNOZZ_LATCH which is used
> in a handful of places.  However, this is dead code; sc- 
> >sc_last_offset
> is initialized (in various places) to 0xffffffff, and thus will never
> match anything &0xffffff80, so PNOZZ_LATCH will never do anything but
> make that (failing) comparison.

> Is this dead code (and thus removal-worthy), or should the assignment
> to sc_last_offset in PNOZZ_LATCH be outside the if rather than inside?

No, but the == should be an !=.

have fun
Michael

Re: Sparc possibly broken

Erik Fair schrieb:
> 
> On Feb 28, 2010, at 10:45, Frank Wißmann wrote:
> 
>> One of the drives has a jumper with (when I count right) 12 pins of 
>> which 4 are covered by the jumper. Seen from the front they are the 
>> leftmost ones.
> 
> We (NetBSD community) have no knowledge of the jumper definitions for 
> your disk drive.
> 
> Google for the drive model number and you will likely find the disk 
> drive manual online from HP (or someone); therein you should find the 
> definitions of the jumpers, which vary widely from drive to drive (even 
> from the same manufacturer).
> 
>     Erik <fair <at> netbsd.org>
> 
> 

Well, that's a real fair opinion . I try finding it in newsgroups. 
Until then I thank everybody for his/her thoughts.

Frank

--

-- 
GU d- s:+ a+ C+>$ UBS>$ P L- !E--- W N+ <at>  !o K--? !w--- O !M- !V- PS+ PE 
Y? !PGP- t+ 5 X !R tv- b++ DI !D G e h+ r- y?

When pack meets pack in the jungle

anyone else seeing a wqcurrent-sparc64 build error in the kernel?

#   compile  GENERIC_SUN4U/tda.o
/usr/cross/sparc/bin/sparc--netbsdelf-gcc -mno-fpu -ffreestanding
-fno-zero-initialized-in-bss -O2 -std=gnu99 -fno-strict-aliasing -Werror -Wall -Wno-main
-Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wswitch
-Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code -Wno-sign-compare -Wno-pointer-sign
-Wno-attributes -Werror -Wa,-Av8plus -Dsparc64 -D__sparc64__ -m32 -Wa,-Av8plusa -mcpu=ultrasparc
-I. -I/usr/src/sys/../common/include -I/usr/src/sys/arch -I/usr/src/sys -nostdinc
-DMAXUSERS=64 -D_KERNEL -D_KERNEL_OPT
-I/usr/src/sys/lib/libkern/../../../common/lib/libc/quad
-I/usr/src/sys/lib/libkern/../../../common/lib/libc/string
-I/usr/src/sys/lib/libkern/../../../common/lib/libc/arch/sparc/string
-I/usr/src/sys/dist/ipf -I/usr/src/sys/external/isc/ather
 os_hal/dist -I/usr/src/sys/external/isc/atheros_hal/ic -c /usr/src/sys/arch/sparc64/dev/tda.c
cc1: warnings being treated as errors
/usr/src/sys/arch/sparc64/dev/tda.c: In function 'tda_adjust':
/usr/src/sys/arch/sparc64/dev/tda.c:204: warning: format '%lu' expects type 'long unsigned int',
but argument 3 has type 'u_int64_t'
/usr/src/sys/arch/sparc64/dev/tda.c:204: warning: format '%lu' expects type 'long unsigned int',
but argument 4 has type 'u_int64_t'
*** [tda.o] Error code 1

--

-- 
Hisashi T Fujinaka - htodd <at> twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

Re: p9100 bug?

>> sys/dev/sbus/p9100.c (1.34) includes a macro PNOZZ_LATCH [...]
>> Is this dead code (and thus removal-worthy), or should the
>> assignment to sc_last_offset in PNOZZ_LATCH be outside the if rather
>> than inside?
> No, but the == should be an !=.

!!  Okay, it makes a bit more sense now.  (Doesn't seem to be necessary
in practice, though, given how basically working the p9100 is.)  Should
I send-pr this or something?

I really need to convert that PDF into something usable so I have a
decent stab at figuring these things out on my own....

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: p9100 bug?

Hello,

On Mar 3, 2010, at 11:18 AM, der Mouse wrote:

>>> sys/dev/sbus/p9100.c (1.34) includes a macro PNOZZ_LATCH [...]
>>> Is this dead code (and thus removal-worthy), or should the
>>> assignment to sc_last_offset in PNOZZ_LATCH be outside the if rather
>>> than inside?
>> No, but the == should be an !=.
>
> !!  Okay, it makes a bit more sense now.  (Doesn't seem to be  
> necessary
> in practice, though, given how basically working the p9100 is.)

Yeah, the SPARCbook docs are often incorrect, it seems to be based on  
docs for older hardware which was updated incompletely. Unfortunately  
we don't know which hardware needs  PNOZZ_LATCH - might be necessary  
for older SPARCbook 3 models or even older revisions of the 3GX.

>  Should I send-pr this or something?

No, I already committed a fix. PNOZZ_LATCH() is optional now, but for  
reasons of paranoia it's enabled in GENERIC and INSTALL. Just get rid  
of the options PNOZZ_USE_LATCH line ( or just don't add it to your  
kernel config )

> I really need to convert that PDF into something usable so I have a
> decent stab at figuring these things out on my own....

Re: p9100 bug?

On Wed, Mar 03, 2010 at 02:39:35PM -0500, Michael wrote:
> 
> Yeah, the SPARCbook docs are often incorrect, ...

I suspect that, in some cases, they contain what the ASIC was supposed
to do, not what it actually did!
The latter may never have been documented anywhere.

I worked for Tadpole for a while, the guys there had to guess how the
hardware worked as well!

	David

--

-- 
David Laight: david <at> l8s.co.uk

(unknown)

Free Sun sun4m, SPARC stuff in Austin, TX.

 I've got an assortment of sun4m equipment in Austin, TX that i'd like to
give to someone working on or running NetBSD.

Please note that this list may not be 100% accurate (it's pretty close,
but i'm not going to open every anti-static bag i have to make sure it's
as labeled):

 The machines are:

     SPARCstation-5/170, 256 MB RAM, (probably has one or two GX frame buffers)
     SPARCstation-20, 512 MB RAM, 2 x 50 MHz CPUs with 1 MB cache.
     SPARCstation-20, 384 MB RAM, 2 x 50 MHz CPUs

 I've also got at least (2) Sun Type-5 keyboards, and three mice, two of
them optical.

 I've got a quite a few misc SBus cards:

    Frame Buffers:
  	(4) GX
	(1) CG3 501-1718
	(1) 100 Mbps HME 501-2919
	(1) Antares SCSI/Ethernet
	(1) BW2/MG2501-1455
	(1) Monster 3-slot Frame buffer 370137001353
	(1) 2-slot GX 501-1645

  MBus processor cards:

Re: p9100 bug?

>> Should I send-pr this or something?
> No, I already committed a fix.  [...]

Is there any interest in other bugs?  p9100.c 1.34 breaks rather
unplesantly when asked to set a cursor <=32 pixels in the X direction;
I have a partial fix implemented, but it has other problems, less
severe but still in need of fixing.  I don't know where p9100.c has
gone since then, though, and see little point in trying to push fixes
upstream for bugs in versions nobody but me cares about any longer.
But the PNOZZ_LATCH bug makes it seem likely it hasn't seen much work
since 1.34....

> Also, we do not currently have envsys support for external battery
> packs, mostly because nobody seems to have one.

I'm one of the pack in that regard, sorry to say.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: Free Sun sun4m, SPARC stuff in Austin, TX.

Hello,

On Mar 7, 2010, at 2:38 AM, Johan van Zanten wrote:

> 	(1) Monster 3-slot Frame buffer 370137001353

The only 3 slot SBus framebuffer I'm aware of is some Matrox piece -  
is that what it is? I can't find anything with that part number.
Either way, being NetBSD's more or less official graphics driver guy  
I'm interested in this one.

have fun
Michael