Sparc release requalification

[Jurij Smakov]

Hello,

I would like to point out that sparc release requalification is currently
placing it in "at risk" position for squeeze release. The most serious
problems with the port are lack of developer involvement (there is currently
one active porter/developer known to the release team, Bernd Zeimetz) and
the fact that current mixed 64-bit kernel with 32-bit userspace setup is
not supported upstream (CC'ing doko for comment). On top of that, the sid
kernels are not booting on my machine (SunBlade 1000), and I have an
independent confirmation from someone with a similar machine that they are
experiencing similar problems - I'm going to file a bug for that if the
situation does not improve with the next kernel upload.

In order to ensure that sparc is getting released with squeeze, at least a
couple of potential contributors with available time and access to sparc
hardware should make themselves known (for example, by replying to this
thread) and attempt to fix outstanding kernel and userspace issues, as well
as start regular installer testing (on a somewhat brighter note, Stephen
Gran has reported an almost successful install on T2K recently [0]).

[0] http://lists.debian.org/debian-boot/2009/08/msg00392.html 

Best regards,
--
Jurij Smakov                                           jurij@...
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Josip Rodin-7]

On Tue, Aug 18, 2009 at 09:43:35PM +0100, Jurij Smakov wrote:
> the sid kernels are not booting on my machine (SunBlade 1000), and I have
> an independent confirmation from someone with a similar machine that they
> are experiencing similar problems - I'm going to file a bug for that if
> the situation does not improve with the next kernel upload.

What seems to be the problem? FWIW the prtconfs.git repo has two SB1000
entries one of which is davem's, so we should have upstream support for
this at least.

Regarding the sparc kernel, it has recently seen a significant amount of
work esp. on 32-bit support, and in fact a new 32-bit subarch Leon was just
added, so we may actually be in a better situation than in lenny on that
front. The outlook certainly seems to be less gloomy than before.

> (on a somewhat brighter note, Stephen Gran has reported an almost
> successful install on T2K recently [0])

(Is that the newly donated machine that we had been talking about a while
ago?)

--
     2. That which causes joy or happiness.


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jurij Smakov]

On Tue, Aug 18, 2009 at 11:23:27PM +0200, Josip Rodin wrote:
> On Tue, Aug 18, 2009 at 09:43:35PM +0100, Jurij Smakov wrote:
> > the sid kernels are not booting on my machine (SunBlade 1000), and I have
> > an independent confirmation from someone with a similar machine that they
> > are experiencing similar problems - I'm going to file a bug for that if
> > the situation does not improve with the next kernel upload.
>
> What seems to be the problem? FWIW the prtconfs.git repo has two SB1000
> entries one of which is davem's, so we should have upstream support for
> this at least.

After the message mentioning the console handoff from earlyprom to a real
console it proceeds to clear the screen, however after a couple of lines
it hangs.
 

> Regarding the sparc kernel, it has recently seen a significant amount of
> work esp. on 32-bit support, and in fact a new 32-bit subarch Leon was just
> added, so we may actually be in a better situation than in lenny on that
> front. The outlook certainly seems to be less gloomy than before.
>
> > (on a somewhat brighter note, Stephen Gran has reported an almost
> > successful install on T2K recently [0])
>
> (Is that the newly donated machine that we had been talking about a while
> ago?)

No idea about that.

Best regards,
--
Jurij Smakov                                           jurij@...
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Josip Rodin-7]

On Tue, Aug 18, 2009 at 10:30:29PM +0100, Jurij Smakov wrote:

> > > the sid kernels are not booting on my machine (SunBlade 1000), and I have
> > > an independent confirmation from someone with a similar machine that they
> > > are experiencing similar problems - I'm going to file a bug for that if
> > > the situation does not improve with the next kernel upload.
> >
> > What seems to be the problem? FWIW the prtconfs.git repo has two SB1000
> > entries one of which is davem's, so we should have upstream support for
> > this at least.
>
> After the message mentioning the console handoff from earlyprom to a real
> console it proceeds to clear the screen, however after a couple of lines
> it hangs.

Did you try to avoid the handoff? That patch davem keeps telling people to
try when something like this happens:

--- a/arch/sparc64/kernel/setup.c
+++ b/arch/sparc64/kernel/setup.c
@@ -82,7 +82,7 @@ unsigned long cmdline_memory_size = 0;
 static struct console prom_early_console = {
        .name =         "earlyprom",
        .write =        prom_console_write,
-       .flags =        CON_PRINTBUFFER | CON_BOOT | CON_ANYTIME,
+       .flags =        CON_PRINTBUFFER | CON_ANYTIME,
        .index =        -1,
 };

--
     2. That which causes joy or happiness.


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Philipp Kern-6]

Josip,

am Tue, Aug 18, 2009 at 11:23:27PM +0200 hast du folgendes geschrieben:
> > (on a somewhat brighter note, Stephen Gran has reported an almost
> > successful install on T2K recently [0])
> (Is that the newly donated machine that we had been talking about a while
> ago?)

donated to Debian years ago, only DSA'ed very, very recently.

Kind regards,
Philipp Kern
--
 .''`.  Philipp Kern                        Debian Developer
: :' :  http://philkern.de                         Stable Release Manager
`. `'   xmpp:phil@...                         Wanna-Build Admin
  `-    finger pkern/key@...

[Matthias Klose]

On 18.08.2009 22:43, Jurij Smakov wrote:
> Hello,
>
> I would like to point out that sparc release requalification is currently
> placing it in "at risk" position for squeeze release. The most serious
> problems with the port are lack of developer involvement (there is currently
> one active porter/developer known to the release team, Bernd Zeimetz) and
> the fact that current mixed 64-bit kernel with 32-bit userspace setup is
> not supported upstream (CC'ing doko for comment).

The current configuration for a biarch toolchain defaulting to 32-bit isn't that
well supported. The 32-bit compiler defaults to v8 hardware which isn't
available anymore. The biarch setup tightly couples v9 and newer processor
support to 64-bit, so switching to a 64-bit userland would offer better use of
current hardware besides targeting a comparable setup as other distributions.
Newer projects like llvm don't target 32-bit sparc anymore, while they do for
64-bit.

I did speak with Martin Zobel at Debconf on how to get there, having two proposals:

  - define a new sparc64 port, and bootstrap this one using the 32bit port.

  - have an inplace-transition building required library packages for an
    upgrade as biarch packages and continue to use the current sparc name.

For both variants the toolchain is almost in place. glibc and binutils don't
need modifications, gcc needs some libraries be built as biarch on sparc. zlib
is already built as biarch on sparc. gmp and mpfr are already built as biarch on
other archs, ppl and cloog would be good to have, but we could start without the
graphite optimizations as well.

I can prepare the changes for gcc, but will not help with any other transition work.

[CCing debian-s390, because there are plans for a switch to s390x as well]

   Matthias


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bastian Blank]

On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote:
> I did speak with Martin Zobel at Debconf on how to get there, having two proposals:
>  - define a new sparc64 port, and bootstrap this one using the 32bit port.

This is rather easy. I already did a s390x bootstrap using this method.

>  - have an inplace-transition building required library packages for an
>    upgrade as biarch packages and continue to use the current sparc name.

This would mean that many packages needs to be modified. Is it really
worth the work needed if we consider the availability of multiarch in
the next time?

Bastian

--
He's dead, Jim.
                -- McCoy, "The Devil in the Dark", stardate 3196.1


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matthias Klose]

On 19.08.2009 13:42, Bastian Blank wrote:

> On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote:
>> I did speak with Martin Zobel at Debconf on how to get there, having two proposals:
>>   - define a new sparc64 port, and bootstrap this one using the 32bit port.
>
> This is rather easy. I already did a s390x bootstrap using this method.
>
>>   - have an inplace-transition building required library packages for an
>>     upgrade as biarch packages and continue to use the current sparc name.
>
> This would mean that many packages needs to be modified. Is it really
> worth the work needed if we consider the availability of multiarch in
> the next time?

you'll end up modifying a different set of packages for the new architecture
name in control and rules files. I don't know if this is less or more work.


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bastian Blank]

On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote:

> On 19.08.2009 13:42, Bastian Blank wrote:
>> On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote:
>>> I did speak with Martin Zobel at Debconf on how to get there, having two proposals:
>>>   - have an inplace-transition building required library packages for an
>>>     upgrade as biarch packages and continue to use the current sparc name.
>> This would mean that many packages needs to be modified. Is it really
>> worth the work needed if we consider the availability of multiarch in
>> the next time?
> you'll end up modifying a different set of packages for the new
> architecture name in control and rules files. I don't know if this is
> less or more work.

If I understand this correctly, this would need the modification off all
library packages to implement biarch semantic.

Bastian

--
Star Trek Lives!


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Mike Hommey]

On Wed, Aug 19, 2009 at 04:33:32PM +0200, Bastian Blank wrote:

> On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote:
> > On 19.08.2009 13:42, Bastian Blank wrote:
> >> On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote:
> >>> I did speak with Martin Zobel at Debconf on how to get there, having two proposals:
> >>>   - have an inplace-transition building required library packages for an
> >>>     upgrade as biarch packages and continue to use the current sparc name.
> >> This would mean that many packages needs to be modified. Is it really
> >> worth the work needed if we consider the availability of multiarch in
> >> the next time?
> > you'll end up modifying a different set of packages for the new
> > architecture name in control and rules files. I don't know if this is
> > less or more work.
>
> If I understand this correctly, this would need the modification off all
> library packages to implement biarch semantic.

... which will be needed anyways. So your choice is actually between
doing it and doing it plus some extra intermediate work.

Mike


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bastian Blank]

On Thu, Aug 20, 2009 at 07:09:44AM +0200, Mike Hommey wrote:
> On Wed, Aug 19, 2009 at 04:33:32PM +0200, Bastian Blank wrote:
> > If I understand this correctly, this would need the modification off all
> > library packages to implement biarch semantic.
> ... which will be needed anyways. So your choice is actually between
> doing it and doing it plus some extra intermediate work.

No, we don't need to do that. Thats what is multiarch for.

Bastian

--
Captain's Log, star date 21:34.5...


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Philipp Kern-6]

On Thu, Aug 20, 2009 at 10:45:46AM +0200, Bastian Blank wrote:
> On Thu, Aug 20, 2009 at 07:09:44AM +0200, Mike Hommey wrote:
> > On Wed, Aug 19, 2009 at 04:33:32PM +0200, Bastian Blank wrote:
> > > If I understand this correctly, this would need the modification off all
> > > library packages to implement biarch semantic.
> > ... which will be needed anyways. So your choice is actually between
> > doing it and doing it plus some extra intermediate work.
> No, we don't need to do that. Thats what is multiarch for.

It's not intended that multiarch supports switching architectures.  Of course
it would help to import some 64bit packages selectively from a sparc64 port
but most of your binaries would still be 32bit with the only partially supported
code generation?  Even on a rebuild you would have to pull in the 64bit
libs in a way you build against them by default?  (Or would that boil down
to passing another DEB_*_ARCH so that config.guess targets 64bit and stuffing
that into simple packages with arch:sparc?)

Kind regards,
Philipp Kern
--
 .''`.  Philipp Kern                        Debian Developer
: :' :  http://philkern.de                         Stable Release Manager
`. `'   xmpp:phil@...                         Wanna-Build Admin
  `-    finger pkern/key@...

[Matthias Klose]

On 19.08.2009 16:33, Bastian Blank wrote:

> On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote:
>> On 19.08.2009 13:42, Bastian Blank wrote:
>>> On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote:
>>>> I did speak with Martin Zobel at Debconf on how to get there, having two proposals:
>>>>    - have an inplace-transition building required library packages for an
>>>>      upgrade as biarch packages and continue to use the current sparc name.
>>> This would mean that many packages needs to be modified. Is it really
>>> worth the work needed if we consider the availability of multiarch in
>>> the next time?
>> you'll end up modifying a different set of packages for the new
>> architecture name in control and rules files. I don't know if this is
>> less or more work.
>
> If I understand this correctly, this would need the modification off all
> library packages to implement biarch semantic.

No, "just" a subset that an update from 32->64bit userland does work. Again, I
don't know how big this subset will be.

   Matthias


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bastian Blank]

On Thu, Aug 20, 2009 at 10:53:08AM +0200, Philipp Kern wrote:
> It's not intended that multiarch supports switching architectures.

It's also just an upgrade. Or did I miss something that would make it
impossible to replace perl/i386 with perl/amd64?

Bastian

--
Many Myths are based on truth
                -- Spock, "The Way to Eden",  stardate 5832.3


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Aurelien Jarno]

Bastian Blank a écrit :
> On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote:
>> I did speak with Martin Zobel at Debconf on how to get there, having two proposals:
>>  - define a new sparc64 port, and bootstrap this one using the 32bit port.
>
> This is rather easy. I already did a s390x bootstrap using this method.
>

If we are not sure that sparc and s390 (ie 32-bit versions) would be
suitable for squeeze, this is almost sure they won't be suitable for
squeeze+1.

Isn't it the right moment to start a sparc64 and an s390x port, and if
they are ready for squeeze release with them? Almost whatever upgrade
solution you offer will require to have at least one release with both
old and new architecture (like we did for arm -> armel).

Given that we already have sparc and s390 in the archive and that we
also already have 64-bit ports, I don't expect any major problem for
those new ports. Also given quite fast hardware exists for those
architectures, it can probably be done relatively quickly.

--
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@...                 http://www.aurel32.net


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jurij Smakov]

[dropping debian-release, as it's not very interesting for them anymore]

On Wed, Aug 19, 2009 at 12:00:54AM +0200, Josip Rodin wrote:

> On Tue, Aug 18, 2009 at 10:30:29PM +0100, Jurij Smakov wrote:
> > > > the sid kernels are not booting on my machine (SunBlade 1000), and I have
> > > > an independent confirmation from someone with a similar machine that they
> > > > are experiencing similar problems - I'm going to file a bug for that if
> > > > the situation does not improve with the next kernel upload.
> > >
> > > What seems to be the problem? FWIW the prtconfs.git repo has two SB1000
> > > entries one of which is davem's, so we should have upstream support for
> > > this at least.
> >
> > After the message mentioning the console handoff from earlyprom to a real
> > console it proceeds to clear the screen, however after a couple of lines
> > it hangs.
>
> Did you try to avoid the handoff? That patch davem keeps telling people to
> try when something like this happens:
>
> --- a/arch/sparc64/kernel/setup.c
> +++ b/arch/sparc64/kernel/setup.c
> @@ -82,7 +82,7 @@ unsigned long cmdline_memory_size = 0;
>  static struct console prom_early_console = {
>         .name =         "earlyprom",
>         .write =        prom_console_write,
> -       .flags =        CON_PRINTBUFFER | CON_BOOT | CON_ANYTIME,
> +       .flags =        CON_PRINTBUFFER | CON_ANYTIME,
>         .index =        -1,
>  };

I tried this patch, and the box still hangs early during boot with the
latest kernel from unstable, even though console handover does not
appear to be happening anymore. Here's the last screenful of messages
I see on the serial console:

[    0.000000] Kernel: Using 2 locked TLB entries for main kernel image.
[    0.000000] Remapping the kernel... done.
[    0.000000] OF stdout device is: /pci@8,700000/ebus@5/serial@1,400000:a
[    0.000000] PROM: Built device tree with 73716 bytes of memory.
[    0.000000] Top of RAM: 0x7fede000, Total RAM: 0x7fed6000
[    0.000000] Memory hole size: 0MB
[    0.000000] [0000000200000000-fffff80000400000] page_structs=131072 node=0 entry=0/0
[    0.000000] [0000000200000000-fffff80000800000] page_structs=131072 node=0 entry=1/0
[    0.000000] [0000000200800000-fffff80000c00000] page_structs=131072 node=0 entry=2/0
[    0.000000] [0000000200800000-fffff80001000000] page_structs=131072 node=0 entry=3/0
[    0.000000] Zone PFN ranges:
[    0.000000]   Normal   0x00000000 -> 0x0003ff6f
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[3] active PFN ranges
[    0.000000]     0: 0x00000000 -> 0x0003f7ff
[    0.000000]     0: 0x0003f800 -> 0x0003ff5d
[    0.000000]     0: 0x0003ff60 -> 0x0003ff6f
[    0.000000] Booting Linux...
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 259948
[    0.000000] Kernel command line: root=LABEL=root ro
[    0.000000] NR_IRQS:255
[    0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
[    0.000000] clocksource: mult[c80000] shift[16]
[    0.000000] clockevent: mult[147ae14] shift[32]
[   57.812617] Console: colour dummy device 80x25
[   57.865696] console [tty0] enabled
[   60.031281] Dentry cache hash table entries: 262144 (order: 8, 2097152 bytes)
[   60.120115] Inode-cache hash table entries: 131072 (order: 7, 1048576 bytes)
[   60.311406] Memory: 2062032k available (3304k kernel code, 1248k data, 208k init) [fffff80000000000,000000007fede000]
[   60.516890] Calibrating delay using timer specific routine.. 10.00 BogoMIPS (lpj=20015)
[   60.611164] Security Framework initialized
[   60.659890] SELinux:  Disabled at boot.
[   60.705771] Mount-cache hash table entries: 512
[   60.760489] Initializing cgroup subsys ns
[   60.807803] Initializing cgroup subsys cpuacct
[   60.860920] Initializing cgroup subsys devices
[   60.914042] Initializing cgroup subsys freezer
[   60.967166] Initializing cgroup subsys net_cls
[   61.022918] CPU 1: synchronized TICK with master CPU (last diff 0 cycles, maxerr 5 cycles)
[   61.022933] Brought up 2 CPUs
[   61.024050] net_namespace: 1936 bytes
[   61.200137] regulator: core version 0.5
[   61.245754] NET: Registered protocol family 16
[   61

It just hangs right there, with the last string only partially displayed
and cursor blinking right after '61'.

Best regards,
--
Jurij Smakov                                           jurij@...
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Josip Rodin-7]

On Sat, Aug 22, 2009 at 09:32:43PM +0100, Jurij Smakov wrote:

> > > > > the sid kernels are not booting on my machine (SunBlade 1000), and I have
> > > > > an independent confirmation from someone with a similar machine that they
> > > > > are experiencing similar problems - I'm going to file a bug for that if
> > > > > the situation does not improve with the next kernel upload.
> > > >
> > > > What seems to be the problem? FWIW the prtconfs.git repo has two SB1000
> > > > entries one of which is davem's, so we should have upstream support for
> > > > this at least.
> > >
> > > After the message mentioning the console handoff from earlyprom to a real
> > > console it proceeds to clear the screen, however after a couple of lines
> > > it hangs.
> >
> > Did you try to avoid the handoff? That patch davem keeps telling people to
> > try when something like this happens:
> >
> > --- a/arch/sparc64/kernel/setup.c
> > +++ b/arch/sparc64/kernel/setup.c
> > @@ -82,7 +82,7 @@ unsigned long cmdline_memory_size = 0;
> >  static struct console prom_early_console = {
> >         .name =         "earlyprom",
> >         .write =        prom_console_write,
> > -       .flags =        CON_PRINTBUFFER | CON_BOOT | CON_ANYTIME,
> > +       .flags =        CON_PRINTBUFFER | CON_ANYTIME,
> >         .index =        -1,
> >  };
>
> I tried this patch, and the box still hangs early during boot with the
> latest kernel from unstable, even though console handover does not
> appear to be happening anymore. Here's the last screenful of messages
> I see on the serial console:
>
> [   61.022933] Brought up 2 CPUs
> [   61.024050] net_namespace: 1936 bytes
> [   61.200137] regulator: core version 0.5
> [   61.245754] NET: Registered protocol family 16
> [   61
>
> It just hangs right there, with the last string only partially displayed
> and cursor blinking right after '61'.

Ugh. I guess you need to git bisect then.

--
     2. That which causes joy or happiness.


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jurij Smakov]

On Thu, Aug 20, 2009 at 12:20:01PM +0200, Matthias Klose wrote:

> On 19.08.2009 16:33, Bastian Blank wrote:
> >On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote:
> >>On 19.08.2009 13:42, Bastian Blank wrote:
> >>>On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote:
> >>>>I did speak with Martin Zobel at Debconf on how to get there, having two proposals:
> >>>>   - have an inplace-transition building required library packages for an
> >>>>     upgrade as biarch packages and continue to use the current sparc name.
> >>>This would mean that many packages needs to be modified. Is it really
> >>>worth the work needed if we consider the availability of multiarch in
> >>>the next time?
> >>you'll end up modifying a different set of packages for the new
> >>architecture name in control and rules files. I don't know if this is
> >>less or more work.
> >
> >If I understand this correctly, this would need the modification off all
> >library packages to implement biarch semantic.
>
> No, "just" a subset that an update from 32->64bit userland does
> work. Again, I don't know how big this subset will be.

Matthias, can you please make a definite statement on whether you, as a
toolchain maintainer, are willing to support the existing 32-bit userland
with a 64-bit kernel, or you consider a transition to 64-bit userland
a necessary condition for sparc to be released with squeeze. This will
be an important factor for the release team to determine what is going
to happen.

Thanks.
--
Jurij Smakov                                           jurij@...
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Sébastien Bernard-3]

On Sat, 22 Aug 2009 21:32:43 +0100, Josip Rodin Wrote :

> [dropping debian-release, as it's not very interesting for them anymore]
>
> On Wed, Aug 19, 2009 at 12:00:54AM +0200, Josip Rodin wrote:
> > On Tue, Aug 18, 2009 at 10:30:29PM +0100, Jurij Smakov wrote:
> > > > > the sid kernels are not booting on my machine (SunBlade 1000), and I have
> > > > > an independent confirmation from someone with a similar machine that they
> > > > > are experiencing similar problems - I'm going to file a bug for that if
> > > > > the situation does not improve with the next kernel upload.
> > > >
> > > > What seems to be the problem? FWIW the prtconfs.git repo has two SB1000
> > > > entries one of which is davem's, so we should have upstream support for
> > > > this at least.
> > >
> > > After the message mentioning the console handoff from earlyprom to a real
> > > console it proceeds to clear the screen, however after a couple of lines
> > > it hangs.
> >
> > Did you try to avoid the handoff? That patch davem keeps telling people to
> > try when something like this happens:
> >
> > --- a/arch/sparc64/kernel/setup.c
> > +++ b/arch/sparc64/kernel/setup.c
> > @@ -82,7 +82,7 @@ unsigned long cmdline_memory_size = 0;
> >  static struct console prom_early_console = {
> >         .name =         "earlyprom",
> >         .write =        prom_console_write,
> > -       .flags =        CON_PRINTBUFFER | CON_BOOT | CON_ANYTIME,
> > +       .flags =        CON_PRINTBUFFER | CON_ANYTIME,
> >         .index =        -1,
> >  };
>
> I tried this patch, and the box still hangs early during boot with the
> latest kernel from unstable, even though console handover does not
> appear to be happening anymore. Here's the last screenful of messages
> I see on the serial console:
>
> [    0.000000] Kernel: Using 2 locked TLB entries for main kernel image.
> [    0.000000] Remapping the kernel... done.
> [    0.000000] OF stdout device is: /pci@8,700000/ebus@5/serial@1,400000:a
> [    0.000000] PROM: Built device tree with 73716 bytes of memory.
> [    0.000000] Top of RAM: 0x7fede000, Total RAM: 0x7fed6000
> [    0.000000] Memory hole size: 0MB
> [    0.000000] [0000000200000000-fffff80000400000] page_structs=131072 node=0 entry=0/0
> [    0.000000] [0000000200000000-fffff80000800000] page_structs=131072 node=0 entry=1/0
> [    0.000000] [0000000200800000-fffff80000c00000] page_structs=131072 node=0 entry=2/0
> [    0.000000] [0000000200800000-fffff80001000000] page_structs=131072 node=0 entry=3/0
> [    0.000000] Zone PFN ranges:
> [    0.000000]   Normal   0x00000000 -> 0x0003ff6f
> [    0.000000] Movable zone start PFN for each node
> [    0.000000] early_node_map[3] active PFN ranges
> [    0.000000]     0: 0x00000000 -> 0x0003f7ff
> [    0.000000]     0: 0x0003f800 -> 0x0003ff5d
> [    0.000000]     0: 0x0003ff60 -> 0x0003ff6f
> [    0.000000] Booting Linux...
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 259948
> [    0.000000] Kernel command line: root=LABEL=root ro
> [    0.000000] NR_IRQS:255
> [    0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
> [    0.000000] clocksource: mult[c80000] shift[16]
> [    0.000000] clockevent: mult[147ae14] shift[32]
> [   57.812617] Console: colour dummy device 80x25
> [   57.865696] console [tty0] enabled
> [   60.031281] Dentry cache hash table entries: 262144 (order: 8, 2097152 bytes)
> [   60.120115] Inode-cache hash table entries: 131072 (order: 7, 1048576 bytes)
> [   60.311406] Memory: 2062032k available (3304k kernel code, 1248k data, 208k init) [fffff80000000000,000000007fede000]
> [   60.516890] Calibrating delay using timer specific routine.. 10.00 BogoMIPS (lpj=20015)
> [   60.611164] Security Framework initialized
> [   60.659890] SELinux:  Disabled at boot.
> [   60.705771] Mount-cache hash table entries: 512
> [   60.760489] Initializing cgroup subsys ns
> [   60.807803] Initializing cgroup subsys cpuacct
> [   60.860920] Initializing cgroup subsys devices
> [   60.914042] Initializing cgroup subsys freezer
> [   60.967166] Initializing cgroup subsys net_cls
> [   61.022918] CPU 1: synchronized TICK with master CPU (last diff 0 cycles, maxerr 5 cycles)
> [   61.022933] Brought up 2 CPUs
> [   61.024050] net_namespace: 1936 bytes
> [   61.200137] regulator: core version 0.5
> [   61.245754] NET: Registered protocol family 16
> [   61
>
> It just hangs right there, with the last string only partially displayed
> and cursor blinking right after '61'.
>
> Best regards,
> --
> Jurij Smakov                                           jurij@...
> Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC
>
>  

I think you hit the same bug as I do on my V240 (same hardware I think).
Please Check this patch and see if it resolves your problem :
http://marc.info/?l=linux-sparc&m=123922959800843&w=2 
<http://marc.info/?l=linux-sparc&m=123922959800843&w=2>


You can also check the whole thread. At the present time, the kernel
still freezes if this patch is not applied.
Unfortunately, all kernel now from debian or derived distribution are
hanging my machine. There is no workaroung but
disabling the NMI watchdog by this patch.

David said, he'll look this bug later. I'll need to remind him.

Seb


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[David Miller-13]

From: Sébastien Bernard <sbernard@...>
Date: Sun, 06 Sep 2009 23:21:42 +0200

> David said, he'll look this bug later. I'll need to remind him.

In Linus's tree is the following fix for this.  I'll submit it
to -stable when I get a chance.

sparc64: Kill spurious NMI watchdog triggers by increasing limit to 30 seconds.

This is a compromise and a temporary workaround for bootup NMI
watchdog triggers some people see with qla2xxx devices present.

This happens when, for example:

CPU 0 is in the driver init and looping submitting mailbox commands to
load the firmware, then waiting for completion.

CPU 1 is receiving the device interrupts.  CPU 1 is where the NMI
watchdog triggers.

CPU 0 is submitting mailbox commands fast enough that by the time CPU
1 returns from the device interrupt handler, a new one is pending.
This sequence runs for more than 5 seconds.

The problematic case is CPU 1's timer interrupt running when the
barrage of device interrupts begin.  Then we have:

        timer interrupt
        return for softirq checking
        pending, thus enable interrupts

                 qla2xxx interrupt
                 return
                 qla2xxx interrupt
                 return
                 ... 5+ seconds pass
                 final qla2xxx interrupt for fw load
                 return

        run timer softirq
        return

At some point in the multi-second qla2xxx interrupt storm we trigger
the NMI watchdog on CPU 1 from the NMI interrupt handler.

The timer softirq, once we get back to running it, is smart enough to
run the timer work enough times to make up for the missed timer
interrupts.

However, the NMI watchdogs (both x86 and sparc) use the timer
interrupt count to notice the cpu is wedged.  But in the above
scenerio we'll receive only one such timer interrupt even if we last
all the way back to running the timer softirq.

The default watchdog trigger point is only 5 seconds, which is pretty
low (the softwatchdog triggers at 60 seconds).  So increase it to 30
seconds for now.

Signed-off-by: David S. Miller <davem@...>
---
 arch/sparc/kernel/nmi.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/sparc/kernel/nmi.c b/arch/sparc/kernel/nmi.c
index 2c0cc72..b75bf50 100644
--- a/arch/sparc/kernel/nmi.c
+++ b/arch/sparc/kernel/nmi.c
@@ -103,7 +103,7 @@ notrace __kprobes void perfctr_irq(int irq, struct pt_regs *regs)
  }
  if (!touched && __get_cpu_var(last_irq_sum) == sum) {
  local_inc(&__get_cpu_var(alert_counter));
- if (local_read(&__get_cpu_var(alert_counter)) == 5 * nmi_hz)
+ if (local_read(&__get_cpu_var(alert_counter)) == 30 * nmi_hz)
  die_nmi("BUG: NMI Watchdog detected LOCKUP",
  regs, panic_on_timeout);
  } else {
--
1.6.4.2


--
To UNSUBSCRIBE, email to debian-sparc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...