Re: Sparc Hey

install-sparc64-minimal-20110829 init stops when setting system clock

I'm trying to get my Sun Blade 100 going w/ install-sparc64-minimal-20110829.iso
but the init system gets stuck at "Setting the system clock using the
hardware clock [UTC]".

That's not to say the system locks up:  I can type characters and they
show up on the screen, but init doesn't let me proceed past the setting
system clock script.  The machine is definitely still working.  I've
waited 10 or 15 minutes but init won't give up on the "Setting the
system clock" script.

Actually I can ctrl-c out of it the first time init tries to start the
script, before runlevel 3.  But as soon as it enters runlevel 3 it tries
to start the system clock script again and I'm unable to ctrl-c out of
it.

I see in my kernel messages before modules are loaded that the kernel
successfully sets the system clock from the hardware clock:  apparently
install-sparc64-minimal-20110829.iso's kernel has CONFIG_RTC_HCTOSYS
set.  On my x86 systems /etc/conf.d/hwclock tells me "You do not need
this if you are running a modern kernel with CONFIG_RTC_HCTOSYS set to
y."  Should setting the system clock from the hardware clock be enabled
on the installcd at all?

Linux/SPARC64 Hardware Compatibility List

Four years ago I sent in an email with my box's details. This time I
have two new boxes; 

Model - Ultra 60
Kernel - 2.6.34-gentoo-r11
Stability - Excellent
OBP - 3.31
Net - Yes (HME)
Sound - Yes (CS4321)
Framebuffer - sunffb
Submitter - alexbuell
Comments - Dual 360MHz processors, 2GB RAM, 2 x 36GB SCSI SCA disks.
Console and X11 working well. Minor problems with GNOME/Firefox need
resolving.

Model - Sun Blade 2000
Kernel - 2.6.34-gentoo-r12
Stability - Excellent
OBP - 4.16.4
Sound - Yes (can't remember which chipset)
Framebuffer - xvr500 
Submitter - alexbuell
Comments - Dual 1.2GHz processors, 4GB RAM, 2 x 73GB FC-AL disks.
Console working well, need X11 fbdev although display looks corrupted,
X11 still works fine. As above, minor problems with GNOME/Firefox needs
sorting although I intend to help fix those problems.

Regards,
Alex
--

-- 
Tactical Nuclear Kittens

[Fwd: Re: [2.6.29.4] Blade 2000]

For you information if you have not seen this.  Looks like kernel
2.6.29(-r4) has problems on SB2000 at least with the disk firmware.

-------- Forwarded Message --------
From: David Miller <davem <at> davemloft.net>
To: joel.bertrand <at> systella.fr
Cc: sparclinux <at> vger.kernel.org
Subject: Re: [2.6.29.4] Blade 2000
Date: 	Thu, 11 Jun 2009 03:38:04 -0700 (PDT)

From: BERTRAND Joël <joel.bertrand <at> systella.fr>
Date: Fri, 29 May 2009 11:58:54 +0200

> BERTRAND Joël a écrit :
>>     Hello,
>>     I have made some minor modifications in bbc_i2c driver to add en entry
>>     in /proc directory. ALl mofications have been made against 2.6.29.4
>>     but I haven't verified that this kernel was bootable.
>>     I have built my own bbc_i2c driver as a module. 2.6.29.4 kernel hangs
>>     just after qla2xxx initialization. I don't think that this driver try
>>     to upload firmware. This firmware is built into the kernel.
>> CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
>> # CONFIG_STANDALONE is not set
>> # CONFIG_PREVENT_FIRMWARE_BUILD is not set
>> CONFIG_FW_LOADER=y
>> CONFIG_FIRMWARE_IN_KERNEL=y
>> CONFIG_EXTRA_FIRMWARE="ql2200_fw.bin"
>> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
>> Root rayleigh:[/lib/firmware] > ls
>> edgeport emi62 keyspan_pda ql2100_fw.bin ql2300_fw.bin ql2400_fw.bin
>> emi26     ess    korg         ql2200_fw.bin  ql2322_fw.bin  yamaha
>> Root rayleigh:[/lib/firmware] >
>> Configuration:
>> Blade 2000, 2 GB, 2*UIII+/900, Creator3D, internal NIC + 2*3Com NIC.
>>     Is it a known trouble ?
> 
> 	Nobody ? I have tried 2.6.29.1 with exactly the same bug. 2.6.28.7
> 	worked fine.

I just did a scan over the driver changes for qla2xxx from 2.6.28
and 2.6.29 and they were very extensive and complicated.

What we need to do to narrow this down is do a GIT bisect.  I hope
that you have a GIT tree handy and can do this?

Luckily it's pretty easy to only bisect through the qla2xxx changes.

Once you have a tree checked out, start like this:

bash$ git bisect start v2.6.29 v2.6.28 -- drivers/scsi/qla2xxx/

Configure and build that kernel, see if it shows the bug.

If the bug is there go into the GIT tree and say:

bash$ git bisect bad

else if the bug is not there say:

bash$ git bisect good

Rebuild and retest.  Repeat this process of testing and then
running "git bisect good" or "git bisect bad" until the guilty
changeset is found.  At most you'll need to do this 6 times.

Post the result here.

We'll find a way to fix this, thanks!
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--

-- 
Ferris McCormick (P44646, MI) <fmccor <at> gentoo.org>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)

Fw: [2.6.29.4] Blade 2000

Perhaps of interest if you use the ql2200_fw.bin

Begin forwarded message:

Date: Thu, 04 Jun 2009 15:39:06 -0700 (PDT)
From: David Miller <davem <at> davemloft.net>
To: joel.bertrand <at> systella.fr
Cc: sparclinux <at> vger.kernel.org
Subject: Re: [2.6.29.4] Blade 2000

From: BERTRAND Joël <joel.bertrand <at> systella.fr>
Date: Fri, 29 May 2009 11:58:54 +0200

> BERTRAND Joël a écrit :
>>     Hello,
>>     I have made some minor modifications in bbc_i2c driver to add en entry
>>     in /proc directory. ALl mofications have been made against 2.6.29.4
>>     but I haven't verified that this kernel was bootable.
>>     I have built my own bbc_i2c driver as a module. 2.6.29.4 kernel hangs
>>     just after qla2xxx initialization. I don't think that this driver try
>>     to upload firmware. This firmware is built into the kernel.
>> CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
>> # CONFIG_STANDALONE is not set
>> # CONFIG_PREVENT_FIRMWARE_BUILD is not set
>> CONFIG_FW_LOADER=y
>> CONFIG_FIRMWARE_IN_KERNEL=y
>> CONFIG_EXTRA_FIRMWARE="ql2200_fw.bin"
>> CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
>> Root rayleigh:[/lib/firmware] > ls
>> edgeport emi62 keyspan_pda ql2100_fw.bin ql2300_fw.bin ql2400_fw.bin
>> emi26     ess    korg         ql2200_fw.bin  ql2322_fw.bin  yamaha
>> Root rayleigh:[/lib/firmware] >
>> Configuration:
>> Blade 2000, 2 GB, 2*UIII+/900, Creator3D, internal NIC + 2*3Com NIC.
>>     Is it a known trouble ?
> 
> 	Nobody ? I have tried 2.6.29.1 with exactly the same bug. 2.6.28.7
> 	worked fine.

I wonder if there is some subtle endianness problem with the
qlogic firmware, so we load it incorrectly into the chip and
it hangs.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Ferris McCormick (P44646, MI) <fmccor <at> gentoo.org>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)

RE: [Fwd: Re: Just a note - Updated Sparc Icedtea6]

And, of course, forgot:

dev-java/ant-owanttask dev-java/asm dev-java/jarjar
dev-java/hamcrest-core dev-java/junit dev-java/java-getopt
dev-java/qdox dev-java/regexp dev-java/ant-trax dev-java/ant-junit

But so far, all good!  haven't seen any strange java errors crop up.

and, nice to know that these other packages work with just the
~sparc[64]  flag added.

No real hard-core testing, other than just the big ebuild dependancy
chain for ant.

> -----Original Message-----
> From: Leif Sawyer 
> Sent: Wednesday, June 03, 2009 3:28 PM
> To: 'gentoo-sparc <at> lists.gentoo.org'
> Cc: Dylan Wakefield
> Subject: RE: [gentoo-sparc] [Fwd: Re: Just a note - Updated 
> Sparc Icedtea6]
> 
> FYI -
> 
> just installed  icedtea6   on my Ultra2
> 
> updated virtual/jdk  and virtual/jre  so that they would 
> install as well.
> 
> updated dev-java/antlr   and built it successfully.
> 
> currently building  dev-java/ant-1.7.1-r1
>    core  built and installed correctly.
> the remaining packages will take some time:
> 
> dev-java/xml-commons-external dev-java/xml-commons-resolver  
> dev-java/ant-nodeps dev-java/jakarta-regexp dev-java/javacup 
> dev-java/bcel dev-java/xjavac dev-java/junit 
> dev-java/xalan-serializer dev-java/ant-apache-resolver 
> dev-java/ant-apache-regexp dev-java/xerces dev-java/xalan 
> dev-java/ant-junit dev-java/ant-trax
> 
> 
> hooray for java on sparc!
> 
> > -----Original Message-----
> > From: Ferris McCormick [mailto:fmccor <at> gentoo.org]
> > Sent: Monday, June 01, 2009 12:10 PM
> > To: Gentoo Sparc
> > Cc: Dylan Wakefield
> > Subject: [gentoo-sparc] [Fwd: Re: Just a note - Updated Sparc 
> > Icedtea6]
> > 
> > -------- Forwarded Message --------
> > From: Ferris McCormick <fmccor <at> gentoo.org>
> > To: Dylan Wakefield <dylanw <at> wix.com.au>
> > Subject: Re: Just a note - Updated Sparc Icedtea6
> > Date: Sun, 31 May 2009 21:07:24 +0000
> > 
> > On Mon, 01 Jun 2009 05:25:31 +1000
> > Dylan Wakefield <dylanw <at> wix.com.au> wrote:
> > 
> > > 
> > > 
> > > Hello Ferris,
> > > 
> > > Sorry to email directly, you once said it was ok.
> > > 
> > > I've got a drop in replacement for the current Icedtea6 
> ebuild, it 
> > > enables sparc support.
> > > 
> > > I've posted it to the usual place.
> > > 
> > > http://bugs.gentoo.org/159780
> > > 
> > > 
> > > 
> > > Cheers,
> > > Dylan
> > > 
> > Thanks,
> > I'll look at it later this week.
> > 
> > ===========================
> > 
> > Sparc people,
> >   I've looked at Dylan's ebuild.  It does enable sparc support for 
> > IcedTea6, it installs it correctly, and java-config sees it 
> and will 
> > correctly enable it.
> > 
> > I am not a java expert.  However, I did test it briefly with the 
> > netlogo simulation program (netlogo-4.0.3, available from third 
> > parties) and it can run a few of the demo models (I have 
> not done an 
> > exhaustive check).  This is a *major* step
> > --- we've never before even able to get this program to load.
> > 
> > Thus, if any of you have been wanting java or need it on 
> sparc, please 
> > give the ebuild icedtea6-bin-1.4.1.ebuild a test.  If it 
> looks good to 
> > you, I'll work with the java people to drop it into the 
> tree.  It's a 
> > replacement for the existing ebuild, and we can easily 
> distribute the 
> > sparc-specific parts of the distfiles to the mirrors.
> > 
> > Dylan, many thanks for all your efforts --- looks like this 
> might be a 
> > winner.  Are you ever on IRC?  If so, I'd like a few 
> minutes of your 
> > time.  (Yes, I see that there are time zone issues.)
> > 
> > Thanks and regards,
> > Ferris
> > 
> > Regards,
> > Ferris
> > 
> > --
> > Ferris McCormick (P44646, MI) <fmccor <at> gentoo.org> Developer, Gentoo 
> > Linux (Sparc, Userrel, Trustees)
> > --
> > Ferris McCormick (P44646, MI) <fmccor <at> gentoo.org> Developer, Gentoo 
> > Linux (Sparc, Userrel, Trustees)
> > 
> 

Re: [gentoo-dev] Project summaries - SPARC team summary

We are an architecture team, so except for one developer (bluebird) who
is actively working on true multilib support (64-bit userland), we are
mostly reactive to bug reports for security, testing, and keywording.

Currently we have enough developers to pretty much keep up with demand.
However, note the following:

1.  We need arch testers.  We use them to help with evaluating keyword
requests and as a breeding ground for new developers.  However, because
of this all of our arch testers have become developers and we need to
refresh the pool.

2.  Although we currently are keeping up with requests, the work load
is heavy enough that we face (in my opinion) a real risk of developer
burnout.  Thus, I would say that we are understaffed, although we have
one or two candidates in process.  I'd prefer to have about three more
developers as well as arch testers as mentioned above.

So, short term, we are in reasonable shape.  Longer term, we need to
recruit.

Regards,
Ferris
--
Ferris McCormick (P44646, MI) <fmccor <at> gentoo.org>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)

libraries on multilib profile

Hi all
i'm using multilib profile (default/linux/sparc/experimental/multilib)

when i compile something simple, like socat, i'm able to have it on 32 or 64 bit
but i don't found a way to have libraries on 32 AND 64 bit (lib32 and lib64)

for example
if i want a 64bit mysql, i need a 64bit ncurses, and so on

if i add -m64 to CFLAGS, portage will refuse to install it to lib32 due to multilib-strict FEATURE (which i
think is correct)

anybody has any workaround for this? i took a look to glibc ebuild, but it wasn't much help

thanks

Fw: NMI watchdog...

This didn't go anywhere first time.  If you end up with two copies,
apologies.
For those who do not read the sparclinux list.  This is very nice, and
many thanks to David Miller for providing it.

Begin forwarded message:

Date: Thu, 29 Jan 2009 15:54:12 -0800 (PST)
From: David Miller <davem <at> davemloft.net>
To: sparclinux <at> vger.kernel.org
Subject: NMI watchdog...

I just wanted to let folks know what I've been working on, sparc wise.

I have this reocurring issue where one of my workstations hangs
completely, no keyboard input, no console messages, nothing.

Since we have pseudo-NMI support in oprofile via performance counters
in the current tree I worked on rearchitecting this so that a nice NMI
watchdog layer could be added.

It is modelled after the x86 NMI watchdog, with the major difference
being that it is enabled by default.  The cost is one interrupt per
second, and the payback is enormous wrt. the ability to debug complete
system hangs.

Basically how it works is if we see no timer interrupts processed for
5 seconds we print a message, dump registers, and optionally panic the
system.

This will be supported on any system that has profiling counter
overflow interrupt support.  That essentially means any cpu from
UltraSPARC-III onward (including Niagara chips).

Another nice side effect of this work is that it gives us some of the
framework necessary for whatever generic performance counter layer
gets merged into the tree in the future (Ingo Molnar's work, perfmon3,
whatever).

I noticed while doing these changes that we need some work in the
handling of OOPSes and other errors.  In particular we need to start
using the existing generic infrastructure the kernel provides, such as
oops_enter(), oops_exit(), bust_spinlocks(), etc.  I do intend to work
on this.

I'm currently busy doing testing to make sure that the NMI watchdog
and oprofile work as expected.

I'll post the patches when I check them in.  I intend to push this
into the current stable tree because there are entire classes of bugs
people run into which can't be analyzed at all without this kind of
facility.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Ferris McCormick (P44646, MI) <fmccor <at> gentoo.org>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)

Fw: NMI watchdog...

For those who do not read the sparclinux list.  This is very nice, and
many thanks to David Miller for providing it.

Begin forwarded message:

Date: Thu, 29 Jan 2009 15:54:12 -0800 (PST)
From: David Miller <davem <at> davemloft.net>
To: sparclinux <at> vger.kernel.org
Subject: NMI watchdog...

I just wanted to let folks know what I've been working on, sparc wise.

I have this reocurring issue where one of my workstations hangs
completely, no keyboard input, no console messages, nothing.

Since we have pseudo-NMI support in oprofile via performance counters
in the current tree I worked on rearchitecting this so that a nice NMI
watchdog layer could be added.

It is modelled after the x86 NMI watchdog, with the major difference
being that it is enabled by default.  The cost is one interrupt per
second, and the payback is enormous wrt. the ability to debug complete
system hangs.

Basically how it works is if we see no timer interrupts processed for
5 seconds we print a message, dump registers, and optionally panic the
system.

This will be supported on any system that has profiling counter
overflow interrupt support.  That essentially means any cpu from
UltraSPARC-III onward (including Niagara chips).

Another nice side effect of this work is that it gives us some of the
framework necessary for whatever generic performance counter layer
gets merged into the tree in the future (Ingo Molnar's work, perfmon3,
whatever).

I noticed while doing these changes that we need some work in the
handling of OOPSes and other errors.  In particular we need to start
using the existing generic infrastructure the kernel provides, such as
oops_enter(), oops_exit(), bust_spinlocks(), etc.  I do intend to work
on this.

I'm currently busy doing testing to make sure that the NMI watchdog
and oprofile work as expected.

I'll post the patches when I check them in.  I intend to push this
into the current stable tree because there are entire classes of bugs
people run into which can't be analyzed at all without this kind of
facility.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

======================================================

Regards,
Ferris
--
Ferris McCormick (P44646, MI) <fmccor <at> gentoo.org>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)

tcunha is now the Sparc AT Subproject Lead

Hi.

Seeing as I've been very busy with other areas of Gentoo, that I haven't
been active in SPARC land for quite some time and that SPARC AT members
and users deserve an active lead, I've talked to Ferris (fmccor) and he
accepted my "resignation" as AT Lead.
As we're still committed to the success of the project, I went looking
for a new Lead and after "pestering" Tiago (tcunha), he accepted the
nomination. Tiago is one of the original ATs, since "promoted" to Gentoo
Dev, and is another example of the success of the Sparc AT team - 3
members have since become Gentoo Developers. Tiago has been doing great
work for Sparc, including the testing of KDE4 - the best DE will be
getting ~sparc keywords, after we take care of webkit ;) (shameless KDE
praise). Please give him a warm welcome to his new role.
Thanks Tiago for taking the role and best success for the team.

--
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE

PS - If you're interested, we (Sparc team) are still in the market to
"hire" more ATs