headers
Stuart Henderson | 1 Aug 2010 15:13
Favicon
Gravatar

pcfiic(4) on Blade 2500 can't read from devices

iic(4) doesn't seem to work well on a Blade 2500; devices on the bus
are detected but reading from them fails:

pcfiic0 at ebus0 addr 320-321 ivec 0x2e
iic0 at pcfiic0
"SUNW,i2c-imax" at iic0 addr 0x9 not configured
"pca9556" at iic0 addr 0x18 not configured
admtt0 at iic0 addr 0x2c, unable to read fan setting
admtt1 at iic0 addr 0x2e, unable to read fan setting
"fm3560" at iic0 addr 0x37 not configured
"fm3560" at iic0 addr 0x4e not configured
spdmem0 at iic0 addr 0x5d: no EEPROM found
spdmem1 at iic0 addr 0x5e: no EEPROM found
spdmem2 at iic0 addr 0x65: no EEPROM found
spdmem3 at iic0 addr 0x66: no EEPROM found
"ics951601" at iic0 addr 0x69 not configured

There's a short delay after admtt attach messages, and a long
delay after each spdmem line (64 seconds). Inserting printfs to
the loop at the top of spdmem_attach_common(), there is a 1-second
delay for each spdmem_read, and every value returned from
spdmem_iic_read() is 0xff.

uint8_t
spdmem_iic_read(struct spdmem_softc *v, uint8_t reg)
{
        struct spdmem_iic_softc *sc = (struct spdmem_iic_softc *)v;
        uint8_t val = 0xff;

        iic_acquire_bus(sc->sc_tag,0);
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mark Kettenis | 1 Aug 2010 16:00
Picon
Picon
Favicon

Re: pcfiic(4) on Blade 2500 can't read from devices

> Date: Sun, 1 Aug 2010 14:13:02 +0100
> From: Stuart Henderson <stu <at> spacehopper.org>
> 
> iic(4) doesn't seem to work well on a Blade 2500; devices on the bus
> are detected but reading from them fails:
> 
> pcfiic0 at ebus0 addr 320-321 ivec 0x2e
> iic0 at pcfiic0
> "SUNW,i2c-imax" at iic0 addr 0x9 not configured
> "pca9556" at iic0 addr 0x18 not configured
> admtt0 at iic0 addr 0x2c, unable to read fan setting
> admtt1 at iic0 addr 0x2e, unable to read fan setting
> "fm3560" at iic0 addr 0x37 not configured
> "fm3560" at iic0 addr 0x4e not configured
> spdmem0 at iic0 addr 0x5d: no EEPROM found
> spdmem1 at iic0 addr 0x5e: no EEPROM found
> spdmem2 at iic0 addr 0x65: no EEPROM found
> spdmem3 at iic0 addr 0x66: no EEPROM found
> "ics951601" at iic0 addr 0x69 not configured

Can you try the attached diff?

Index: pcf8584.c
===================================================================
RCS file: /cvs/src/sys/dev/ic/pcf8584.c,v
retrieving revision 1.10
diff -u -p -r1.10 pcf8584.c
--- pcf8584.c	30 Apr 2010 15:18:29 -0000	1.10
+++ pcf8584.c	1 Aug 2010 13:59:36 -0000
 <at>  <at>  -274,9 +274,12  <at>  <at>  pcfiic_read(struct pcfiic_softc *sc, bus
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Kettenis | 1 Aug 2010 16:21
Picon
Picon
Favicon

Re: pcfiic(4) on Blade 2500 can't read from devices

> Date: Sun, 1 Aug 2010 16:00:21 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis <at> xs4all.nl>
> CC: tech <at> openbsd.org
> List-Owner: <mailto:tech-owner <at> openbsd.org>
> X-Loop: tech <at> openbsd.org
> Sender: owner-tech <at> openbsd.org
> X-XS4ALL-DNSBL-Checked: mxdrop127.xs4all.nl checked 192.43.244.163 against DNS blacklists
> X-CNFS-Analysis: v=1.1 cv=BV6iOS6O7aV3pd42iKzuhu9AXfb4rD1J2pLXhYW4ImA= c=1
> 	sm=0 a=oC6LqzNhtE8A:10 a=A3duGc4wJ8K8BtNzzvyz4A==:17 a=UBLVwNoYAAAA:8
> 	a=aGJVRp6NARZg9Kqi9TUA:9 a=uEjCT1qOjzX6jIdIbGkA:7
> 	a=Tl7SpIjGsPDy7bHnjLYpaUHstlYA:4 a=p_OKZn5TktUA:10
> 	a=A3duGc4wJ8K8BtNzzvyz4A==:117
> X-Virus-Scanned: by XS4ALL Virus Scanner
> X-XS4ALL-Spam-Score: 0.0 () none
> X-XS4ALL-Spam: NO
> Envelope-To: mark.kettenis <at> xs4all.nl
> 
> > Date: Sun, 1 Aug 2010 14:13:02 +0100
> > From: Stuart Henderson <stu <at> spacehopper.org>
> > 
> > iic(4) doesn't seem to work well on a Blade 2500; devices on the bus
> > are detected but reading from them fails:
> > 
> > pcfiic0 at ebus0 addr 320-321 ivec 0x2e
> > iic0 at pcfiic0
> > "SUNW,i2c-imax" at iic0 addr 0x9 not configured
> > "pca9556" at iic0 addr 0x18 not configured
> > admtt0 at iic0 addr 0x2c, unable to read fan setting
> > admtt1 at iic0 addr 0x2e, unable to read fan setting
> > "fm3560" at iic0 addr 0x37 not configured
(Continue reading)

Permalink | Reply | 0 comments |
headers
Theo de Raadt | 1 Aug 2010 19:28
Picon
Favicon

Re: [PATCH] flip order of steps in release(8)

> On Sat, Jul 31, 2010 at 12:00:48PM +0200, Mark Kettenis wrote:
> > > From: Daniel Dickman <didickman <at> gmail.com>
> > > Date: Fri, 30 Jul 2010 20:37:05 -0400
> > > 
> > > > Sorry, I don't think this makes sense.  I always start with doing a
> > > > make obj.  It's way too easy to mess things things up if you forget to
> > > > do that step, so running anything in my source tree without doing make
> > > > obj first makes me very nervous.
> > > >
> > > > Does changing the order actually fix something?
> > > 
> > > i believe so. when i followed the existing order in release(8) but
> > > without remembering to recreate /usr/obj first i got "/usr/obj does
> > > not exist" for every symlink being created.
> > 
> > Why did you remove /usr/obj in the first place?
> > 
> > The point about running make distrib-dirs is not to cover up mistakes
> > a user made, but to create new directories that were "created" because
> > new stuff got added.
> 
> right. so the step isn;t neccessary. but since it additionally covers
> that particular user error, where's the harm? plus, as daniel mentioned,
> it mirrors more closely the steps in making X.

There is great harm.  The first person who extends the distrib-dirs target
to depend on a /usr/obj already begin there is going to damage the tree
of every person who is doing this wrong.

> anyway, it is not really important. we can leave it if people think it's
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ingo Schwarze | 1 Aug 2010 19:46
Picon
Favicon

Re: [PATCH] flip order of steps in release(8)

Theo de Raadt wrote on Sun, Aug 01, 2010 at 11:28:01AM -0600:

> There is great harm.  The first person who extends the distrib-dirs target
> to depend on a /usr/obj already being there is going to damage the tree
> of every person who is doing this wrong.

> jmc <at>  wrote:
>> anyway, it is not really important. we can leave it if people think it's
>> not worth changing. on reflection, i'm inclined to think it probably
>> isn;t worth it.

> Please back it out.

There was no OK, so nothing was committed in the first place.
Permalink | Reply | 0 comments |
headers
Theo de Raadt | 2 Aug 2010 05:55
Picon
Favicon

Re: Building on i386 with DESTDIR

> I've found I need a few diffs to build my i386 system cleanly with
> gcc4 when the DESTDIR variable is set.

Please don't do this.  We want fewer building processes; rather than
more.  With a system this big there are always going to be accidental
and strange unwanted effects just from building differently.  It may
seem to have a point for you to do just one build, but then something
will accidentally get compiled wrong and you will submit a bug report
which we cannot reproduce.  It is not worth the pain.  

> 4) An additional header required for gscpm(4):
> 
> Index: sys/arch/i386/pci/gscpm.c
> ===================================================================
> RCS file: /cvs/src/sys/arch/i386/pci/gscpm.c,v
> retrieving revision 1.6
> diff -p -u -r1.6 gscpm.c
> --- sys/arch/i386/pci/gscpm.c   12 Dec 2006 23:14:27 -0000      1.6
> +++ sys/arch/i386/pci/gscpm.c   16 Jul 2010 14:54:23 -0000
>  <at>  <at>  -23,6 +23,7  <at>  <at> 
>  #include <sys/systm.h>
>  #include <sys/device.h>
>  #include <sys/kernel.h>
> +#include <sys/proc.h>
>  #include <sys/sysctl.h>
>  #ifdef __HAVE_TIMECOUNTER
>  #include <sys/timetc.h>

But this I commited.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ted Unangst | 2 Aug 2010 06:35
Picon

Re: Building on i386 with DESTDIR

On Sun, Aug 1, 2010 at 11:55 PM, Theo de Raadt <deraadt <at> cvs.openbsd.org>
wrote:
>> 4) An additional header required for gscpm(4):
>>
>> Index: sys/arch/i386/pci/gscpm.c
>> ===================================================================
>> RCS file: /cvs/src/sys/arch/i386/pci/gscpm.c,v
>> retrieving revision 1.6
>> diff -p -u -r1.6 gscpm.c
>> --- sys/arch/i386/pci/gscpm.c   12 Dec 2006 23:14:27 -0000      1.6
>> +++ sys/arch/i386/pci/gscpm.c   16 Jul 2010 14:54:23 -0000
>>  <at>  <at>  -23,6 +23,7  <at>  <at> 
>>  #include <sys/systm.h>
>>  #include <sys/device.h>
>>  #include <sys/kernel.h>
>> +#include <sys/proc.h>
>>  #include <sys/sysctl.h>
>>  #ifdef __HAVE_TIMECOUNTER
>>  #include <sys/timetc.h>
>
> But this I commited.

oops, this was wrong.  gscpm.c wants less sysctl.h, not more proc.h.
Permalink | Reply | 0 comments |

Gmane