NetBSD Problem Report #47771

From tsutsui@ceres.dti.ne.jp  Sat Apr 27 04:02:35 2013
Return-Path: <tsutsui@ceres.dti.ne.jp>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 086A363ECDD
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 27 Apr 2013 04:02:34 +0000 (UTC)
Message-Id: <201304270402.r3R42UiA013520@mirage.localdomain>
Date: Sat, 27 Apr 2013 13:02:30 +0900 (JST)
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Reply-To: tsutsui@ceres.dti.ne.jp
To: gnats-bugs@gnats.NetBSD.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: possible fatal typo in sparc sbus_bus_addr() function
X-Send-Pr-Version: 3.95

>Number:         47771
>Category:       port-sparc
>Synopsis:       possible fatal typo in sparc sbus_bus_addr() function
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-sparc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Apr 27 04:05:00 +0000 2013
>Last-Modified:  Sun Apr 28 16:50:03 +0000 2013
>Originator:     Izumi Tsutsui
>Release:        NetBSD 6.0
>Organization:
>Environment:
System: NetBSD/sparc 6.0 GENERIC
Architecture: sparc
Machine: sparc
>Description:
It looks there is (a bit fatal) type in sbus_bus_addr() function,
which is used for framebuffer's mmap() functions.

sys/arch/sparc/dev/sbus.c has the following code:
http://nxr.netbsd.org/xref/src/sys/arch/sparc/dev/sbus.c?r=1.78#507

    507 bus_addr_t
    508 sbus_bus_addr(bus_space_tag_t t, u_int btype, u_int offset)
    509 {
    510 
    511 	/* XXX: sbus_bus_addr should be g/c'ed */
    512 	return (BUS_ADDR(btype, offset));
    513 }

The caller of this function in sys/dev/sbus/cgsix_sbus.c is:
http://nxr.netbsd.org/xref/src/sys/dev/sbus/cgsix_sbus.c?r=1.30#98

     98 	/* Remember cookies for cgsix_mmap() */
     99 	sc->sc_bustag = sa->sa_bustag;
    100 	sc->sc_paddr = sbus_bus_addr(sa->sa_bustag, sa->sa_slot, sa->sa_offset);

So sbus_bus_addr() takes a slot number in the 2nd arg
and offset in the 3rd arg.

This sc->sc_paddr is used to mmap(2) framebuffers in MI cgsix driver:
http://nxr.netbsd.org/xref/src/sys/dev/sun/cgsix.c?r=1.60#1100

   1114 			return (bus_space_mmap(sc->sc_bustag,
   1115 				sc->sc_paddr, u+mo->mo_physoff,
   1116 				prot, BUS_SPACE_MAP_LINEAR));

On the other hand, the definition of BUS_ADDR() is:
http://nxr.netbsd.org/xref/src/sys/arch/sparc/include/bus_defs.h?r=1.1#79

     79 #define	BUS_ADDR(io, pa)	\
     80 	((((uint64_t)(uint32_t)(io))<<32) | (uint32_t)(pa))

so there is no slot or offset in it.

The definition of SBUS_ADDR() is:
http://nxr.netbsd.org/xref/src/sys/arch/sparc/dev/sbusreg.h?r=1.6#54

     54 #define	SBUS_ADDR(slot, off)	(SBUS_BASE + ((slot) << 25) + (off))

so it looks BUS_ADDR() in sbus_bus_addr() is a typo of SBUS_ADDR().

>How-To-Repeat:
Code inspection.

>Fix:
See above, but needs more confirmation by sparc guru.
I'm not sure how sparc Xservers works, but applications
which directly access wsfb via wsdisplay (ttyE0)
don't work on sparc.

>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/47771: possible fatal typo in sparc sbus_bus_addr()
 function
Date: Sun, 28 Apr 2013 16:08:56 +0000

 On Sat, Apr 27, 2013 at 04:05:00AM +0000, Izumi Tsutsui wrote:
  > See above, but needs more confirmation by sparc guru.

 That is not me, but your explanation sounds plausible.

  > I'm not sure how sparc Xservers works, but applications
  > which directly access wsfb via wsdisplay (ttyE0)
  > don't work on sparc.

 Do they work if you apply the change? :-)

 (It doesn't look likely that doing so would cause anything to explode,
 but I don't really know...)

 -- 
 David A. Holland
 dholland@netbsd.org

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: dholland-bugs@NetBSD.org
Cc: gnats-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-sparc/47771: possible fatal typo in sparc sbus_bus_addr()function
Date: Mon, 29 Apr 2013 01:46:24 +0900

 >   > I'm not sure how sparc Xservers works, but applications
 >   > which directly access wsfb via wsdisplay (ttyE0)
 >   > don't work on sparc.
 >  
 >  Do they work if you apply the change? :-)

 No, recent mlterm-fb (which now supports generic wsfb) still doesn't work
 with a kernel with BUS_ADDR() -> SBUS_ADDR() changes on TME with bwtwo
 and cgthree, so I filed this PR.

 I wonder how old X11R6 Xsun servers worked on these framebuffers.

 ---
 Izumi Tsutsui

Home	PR Database Search