[parisc-linux] some bugs

[parisc-linux] some bugs

[M. Grabert]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3471 bytes --]

Hi,

I just played a little with my C240 (serial console and X11 forwarding),
and decided to install a 64bit kernel just for fun (and to help you
testing them). I know that 64bit doesn't make sense at all (at least
not in the near future, since there is no 64bit userland support and I guess
not many applications would profit from it even if there was one).
Needless to say that I'm running a 32bit kernel again ;)


on all 2.4.x kernels tested so far
==================================
- the 32bit kernel shipped with the 0.9.3 iso (IIRC 2.4.9)
- 2.4.18-pa4-32bit
- 2.4.18-pa5-32bit
- 2.4.18-pa14-32bit
- 2.4.18-pa14-64bit

I've seen following issues:

- leds don't seem to work (i.e. no heartbeat or other leds on or blinking - or
  is my hp really so idle ?)
  This is just with the latest 2.4.18-pa14 kernels (2.4.18-pa5-32bit worked,
  but IIRC not perfectly)

- 100Mbit is not supported properly (full-duplex support is always
  recognized, but 100Mbit just occationally).
  Of course it's a full 10/100Mbit SWITCH (no hub), and I checked the cables
  Moreover I just have 100Mbit network devices plugged into the switch.

- the 'poweroff' command doesn't work, it just shutdowns the machine, but does
  no real poweroff. (AFAIK 'poweroff' is a synonym for 'shutdown -p now', isn't
  it ? this doesn't work either).
  The powerkey works as expected (including powering off the workstation)
  with 32bit kernels.



for kernel 2.4.18-pa14-64bit (32bit PDC):
========================================
- if fs type "auto" is set for a ext3 partition, the kernel detects the /, but
  the mount command (in the bootscript) fails to detect the fstype. Setting the
  fstype entry in /etc/fstab to "ext3" or "ext2" fixes the problem.
  Since 'mount -a' fails to detect the fs type, it won't remount /
  in read-write mode, and thus the system won't boot correctly.

  But "auto" in /etc/fstab works with the corresponding 32bit kernel

- crashme is effective (example settings, after a few minutes kernel crashed,
  even MagicSysRq didn't work. It didn't seem to 'work' on 2.4.18-pa5-32bit,
  I didn't try with the 2.4.18-pa14-32bit kernel)

- once I got a kernel oops at interrupt_stack() at boot up (attached to mail),
  but eveything seemed to work. I didn't get any more kernel oops.

- shutdown&poweroff when hitting powerkey does not work (it just switches off
  the workstation immediately; it works properly on the corresponding 32bit
  kernel and 2.4.18-pa5-32bit)

- if I compile in support for STIcon/STIfb, it doesn't switch the output
  to the console (after the 'branching to kernel entry point' message).
  At least I waited for quite some time, and I didn't seem to go on.
  I didn't compile in support for STIcon/STIfb for the 32bit kernel,
  therefore I can't tell whether there is the same problem or not.
  STIcon/STIfb works with 2.4.18-pa5-32bit. Well, my FX/2 card isn't supported
  for fb, but at least the kernel doesn't hang with that kernel.



some things that work on both 32/64bit kernel (2.4.8-pa14), probably not worth
to mention:

- tmpfs, ext3, ext2, iso9660
- harmony audio
- serial console, MagicSysRq over serial console
- of course scsi, ethernet and running 32bit applications
- ventilators ;)


N.B. I didn't try the latest modutils, in which the pa8000 cpu issue is fixed.
therefore I didn't compile any modules
BTW, i use the tulip driver for ethernet. Is it also possible (and safe)
to use the generic DEC driver ?

greetings max

[-- Attachment #2: tail of dmesg --]
[-- Type: TEXT/plain, Size: 2425 bytes --]

EXT3 FS 2.4-0.9.17, 10 Jan 2002 on sd(8,2), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
eth0: Setting full-duplex based on MII#1 link partner capability of 41e1.
eth0: no IPv6 routers present

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000000000000000000000000 Not tainted
r00-03  0000000000000000 000000004006fff8 00000000404252d7 00000000400a5628
r04-07  00000000404358bc 0000000000001200 0000000000029f00 000000003c6ef35f
r08-11  0000000000054020 000000000fffffff 0000000000051c18 0000000000028678
r12-15  0000000000029e78 000000000002d030 00000000faf01390 0000000000017000
r16-19  0000000000028678 0000000000028678 0000000000002000 0000000040205b50
r20-23  0000000000000004 0000000040189634 00000000404252b8 00000000000005e5
r24-27  0000000000001200 0000000000029f00 0000000000000005 0000000000028678
r28-31  fffffffffffffff0 0000000000001fff 00000000faf026c0 000000004018963f
sr0-3   0000000000000380 0000000000000380 0000000000000000 0000000000000380
sr4-7   0000000000000380 0000000000000380 0000000000000380 0000000000000380

IASQ: 0000000000000380 0000000000000380 IAOQ: 0000000040051a6f 0000000040051a73
 IIR: 3af64797    ISR: 0000000000000380  IOR: 000000004043c067
 CPU:        0   CR30: 000000002ced0000 CR31: 0000000010610000
 ORIG_R28: 000000000002ae78

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111011100001111 Not tainted
r00-03  0000000000000000 0000000001605dd2 000000004004ce8f 0000000000052720
r04-07  0000000000050c14 0000000000000002 0000000000050c14 0000000000000016
r08-11  000000000004df56 0000000201603ad0 0000000000000009 00000000000311f0
r12-15  0000000000000024 0000000000000002 000000000004e7e0 00000000015fb634
r16-19  0000000000028678 0000000000028678 00000000015ea788 000000004006fff8
r20-23  000000000000b748 00000000fffee91b 000000000001ab60 0000000000051014
r24-27  0000000000050c14 0000000000000001 000000000004f310 0000000000028678
r28-31  0000000000000003 0000000000025a22 00000000faf027c0 0000000000000010
sr0-3   0000000000000400 0000000000000400 0000000000000000 0000000000000400
sr4-7   0000000000000400 0000000000000400 0000000000000400 0000000000000400

IASQ: 0000000000000400 0000000000000400 IAOQ: 000000004004be8f 000000004004be93
 IIR: d2d61e6c    ISR: 0000000000000400  IOR: 000000004043a066
 CPU:        0   CR30: 000000002ced0000 CR31: 0000000010610000
 ORIG_R28: 000000000002ae78

Re: [parisc-linux] some bugs

[Helge Deller]

Hi Max,

On Tuesday 09 April 2002 19:15, M. Grabert wrote:
>
> on all 2.4.x kernels tested so far
> ==================================
> - the 32bit kernel shipped with the 0.9.3 iso (IIRC 2.4.9)
> - 2.4.18-pa4-32bit
> - 2.4.18-pa5-32bit
> - 2.4.18-pa14-32bit
> - 2.4.18-pa14-64bit
>
> I've seen following issues:
>
> - leds don't seem to work (i.e. no heartbeat or other leds on or blinking -
> or is my hp really so idle ?)
>   This is just with the latest 2.4.18-pa14 kernels (2.4.18-pa5-32bit
> worked, but IIRC not perfectly)

Could you post me some of your bootlogs ?

> - 100Mbit is not supported properly (full-duplex support is always
>   recognized, but 100Mbit just occationally).
>   Of course it's a full 10/100Mbit SWITCH (no hub), and I checked the
> cables Moreover I just have 100Mbit network devices plugged into the
> switch.

I never had problems with tulip and 100MBit here (on c3k).

> - the 'poweroff' command doesn't work, it just shutdowns the machine, but
> does no real poweroff. (AFAIK 'poweroff' is a synonym for 'shutdown -p
> now', isn't it ? this doesn't work either).
>   The powerkey works as expected (including powering off the workstation)
>   with 32bit kernels.

I've looked again at that problem during my latest patches (2.4.18-pa15).
As far as it seems to me we can't poweroff the system directly via software only.
The only possible thing we can do, is to catch all powerbutton presses from the
user and allow or disallow the controlled shutdown of the system. So the current
implementation is, that a) if you press the powerbutton we detect it and initiate
a clean shutdown. The PDC ROM will then power off the system automatically for 
us at the end of the shutdown procedure.
And: b) If you only tell Linux to "shutdown -n" (without having pressed the button)
we initiate the shutdown procedure, stop to catch any powerbutton presses and 
thus enable PDC to power off the system as soon as you press the button later on. 
But in this case you will still need to press the button to really power off the 
machine.  We just only allow the PDC to directly power it off.

So currently I don't see any solution here. You will _always_ have to press the power
button at least once: Directly while the kernel runs, or after you have started "shutdown -n".
Of course I may be wrong, in which case I would appreciate if someone from HP
would correct me here.


> for kernel 2.4.18-pa14-64bit (32bit PDC):
> ========================================
> - if fs type "auto" is set for a ext3 partition, the kernel detects the /,
> but the mount command (in the bootscript) fails to detect the fstype.
> Setting the fstype entry in /etc/fstab to "ext3" or "ext2" fixes the
> problem. Since 'mount -a' fails to detect the fs type, it won't remount /
> in read-write mode, and thus the system won't boot correctly.
>
>   But "auto" in /etc/fstab works with the corresponding 32bit kernel

This should be reported to the debian folks.

> - crashme is effective (example settings, after a few minutes kernel
> crashed, even MagicSysRq didn't work. It didn't seem to 'work' on
> 2.4.18-pa5-32bit, I didn't try with the 2.4.18-pa14-32bit kernel)
>
> - once I got a kernel oops at interrupt_stack() at boot up (attached to
> mail), but eveything seemed to work. I didn't get any more kernel oops.

We don't have chance to trace this bug without having your System.map.

> - shutdown&poweroff when hitting powerkey does not work (it just switches
> off the workstation immediately; it works properly on the corresponding
> 32bit kernel and 2.4.18-pa5-32bit)

Ryan committed some related changes here in 2.4.18-pa16. 
Could you retry with this kernel and check the results with CONFIG_PDC_NARROW 
enabled and disabled ?

> - if I compile in support for STIcon/STIfb, it doesn't switch the output
>   to the console (after the 'branching to kernel entry point' message).
>   At least I waited for quite some time, and I didn't seem to go on.
>   I didn't compile in support for STIcon/STIfb for the 32bit kernel,
>   therefore I can't tell whether there is the same problem or not.
>   STIcon/STIfb works with 2.4.18-pa5-32bit. Well, my FX/2 card isn't
> supported for fb, but at least the kernel doesn't hang with that kernel.

Are you using the latest palo ? Do you maybe have "console=ttyS00" as 
kernel boot parameter (check /proc/cmdline).

Helge

Re: [parisc-linux] some bugs

[M. Grabert]

On Wed, 10 Apr 2002, Helge Deller wrote:

> > - leds don't seem to work (i.e. no heartbeat or other leds on or blinking -
> > or is my hp really so idle ?)
> >   This is just with the latest 2.4.18-pa14 kernels (2.4.18-pa5-32bit
> > worked, but IIRC not perfectly)
>
> Could you post me some of your bootlogs ?

of course. but I have no access to the c240 until tomorrow.
I have access to /proc/pdc/leds, echo "0 0 0" and echo "1 1 1"
will change the /proc/pdc/leds entry, but not leds with flash.

> > - 100Mbit is not supported properly (full-duplex support is always
> >   recognized, but 100Mbit just occationally).
> >   Of course it's a full 10/100Mbit SWITCH (no hub), and I checked the
> > cables Moreover I just have 100Mbit network devices plugged into the
> > switch.
>
> I never had problems with tulip and 100MBit here (on c3k).

10Mbit works perfectly. 100Mbit works once it is detected, which is
often, but not always. Lately it seems to be working most of the times
on 100Mbit, perhaps due latest improvements in the kernel ?

But perhaps it's only a h/w issue (incompatibility with switch and
network card?). Once the workstation is switched on, it seems
the kernel won't change the connection mode (e.g. changing from
10Mbit to 100Mbit) that was initially negotiated by the network card.
Thus is presume that sometimes the h/w 100Mbit negotiation works,
sometimes not, since the 10Mbit mode is entered BEFORE starting the
linux kernel (which don't change it to 100Mbit).

> > - the 'poweroff' command doesn't work, it just shutdowns the machine, but
> > does no real poweroff. (AFAIK 'poweroff' is a synonym for 'shutdown -p
> > now', isn't it ? this doesn't work either).
> >   The powerkey works as expected (including powering off the workstation)
> >   with 32bit kernels.

[...]      // cutting out interesting stuff

> So currently I don't see any solution here. You will _always_ have to press the power
> button at least once: Directly while the kernel runs, or after you have started "shutdown -n".
> Of course I may be wrong, in which case I would appreciate if someone from HP
> would correct me here.

Ah, I see! It's a little bit strange though

> > - if fs type "auto" is set for a ext3 partition, the kernel detects the /,
> > but the mount command (in the bootscript) fails to detect the fstype.
> > Setting the fstype entry in /etc/fstab to "ext3" or "ext2" fixes the
> > problem. Since 'mount -a' fails to detect the fs type, it won't remount /
> > in read-write mode, and thus the system won't boot correctly.
> >
> >   But "auto" in /etc/fstab works with the corresponding 32bit kernel
>
> This should be reported to the debian folks.

Well, yes, maybe, because it's 'mount' specific. But why is it working
with the 32bit kernel? I thought this kind of things should be
platform-independent ...

> > - crashme is effective (example settings, after a few minutes kernel
> > crashed, even MagicSysRq didn't work. It didn't seem to 'work' on
> > 2.4.18-pa5-32bit, I didn't try with the 2.4.18-pa14-32bit kernel)
> >
> > - once I got a kernel oops at interrupt_stack() at boot up (attached to
> > mail), but eveything seemed to work. I didn't get any more kernel oops.
>
> We don't have chance to trace this bug without having your System.map.

That's true ;)
I just looked into the kernel oops and System.map and the only address
that matched the address range of a function in System.map was
interrupt_stack (exactly 00000000106100000). Since there was just one,
not reproducable kernel oops, and since I don't know what caused it,
it doesn't make sense to investigate it further. There are no other
kernel oops in /var/log/messages.
I just thought perhaps there would be a known issue with interrupt_
stack on 64bit or so ...

> > - shutdown&poweroff when hitting powerkey does not work (it just switches
> > off the workstation immediately; it works properly on the corresponding
> > 32bit kernel and 2.4.18-pa5-32bit)
>
> Ryan committed some related changes here in 2.4.18-pa16.
> Could you retry with this kernel and check the results with CONFIG_PDC_NARROW
> enabled and disabled ?

okay, but it will take some time tough ;)

> > - if I compile in support for STIcon/STIfb, it doesn't switch the output
> >   to the console (after the 'branching to kernel entry point' message).
> >   At least I waited for quite some time, and I didn't seem to go on.
> >   I didn't compile in support for STIcon/STIfb for the 32bit kernel,
> >   therefore I can't tell whether there is the same problem or not.
> >   STIcon/STIfb works with 2.4.18-pa5-32bit. Well, my FX/2 card isn't
> > supported for fb, but at least the kernel doesn't hang with that kernel.
>
> Are you using the latest palo ? Do you maybe have "console=ttyS00" as
> kernel boot parameter (check /proc/cmdline).

no, there is no console entry in palo.conf. Palo is the one from
ISO 0.9.3, and it might be updated by apt-get (I'm using unstable).

BTW, one question:

I always wondered if sid (unstable) is the preferred dist for
debian/hppa (very likely a debian-mailing-list question, but what
do you kernel hackers and developers use and prefer?)

thanks, greetings max

Re: [parisc-linux] some bugs

[John David Anglin]

> > > - 100Mbit is not supported properly (full-duplex support is always
> > >   recognized, but 100Mbit just occationally).
> > >   Of course it's a full 10/100Mbit SWITCH (no hub), and I checked the
> > > cables Moreover I just have 100Mbit network devices plugged into the
> > > switch.
> >
> > I never had problems with tulip and 100MBit here (on c3k).
> 
> 10Mbit works perfectly. 100Mbit works once it is detected, which is
> often, but not always. Lately it seems to be working most of the times
> on 100Mbit, perhaps due latest improvements in the kernel ?
> 
> But perhaps it's only a h/w issue (incompatibility with switch and
> network card?). Once the workstation is switched on, it seems
> the kernel won't change the connection mode (e.g. changing from
> 10Mbit to 100Mbit) that was initially negotiated by the network card.
> Thus is presume that sometimes the h/w 100Mbit negotiation works,
> sometimes not, since the 10Mbit mode is entered BEFORE starting the
> linux kernel (which don't change it to 100Mbit).

I've a similar problem with a C200 under hpux.  The card doesn't always
autonegotiate 100Mbit full-duplex in the PDC at boot.  I then force the
card to 100Mbit full-duplex in the hpux driver initialization.  However,
even this sometimes fails.  Then, if something happens to the switch
configuration, I have never seen the card renegotiate the link settings
successfully.  I have a feeling that it might be better to set the PDC
default to 100Mbit half-duplex, and also set the switch and boot
parameters to the same (ie., don't use full-duplex or autonegotiation).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] some bugs

[Grant Grundler]

"M. Grabert" wrote:
> But perhaps it's only a h/w issue (incompatibility with switch and
> network card?).

Possibly. Perhaps just unplugging the cable, wait 5 seconds (or so)
and plug it back in should force a re-negotiation. Not a great work
around but perhaps a start.

...
> Well, yes, maybe, because it's 'mount' specific. But why is it working
> with the 32bit kernel? I thought this kind of things should be
> platform-independent ...

I agree - I doubt this is a mount command problem.
It might be an issue with our 32-bit syscall wrappers in the 64-bit kernels.

> - crashme is effective (example settings, after a few minutes kernel
> crashed, even MagicSysRq didn't work. It didn't seem to 'work' on
> 2.4.18-pa5-32bit, I didn't try with the 2.4.18-pa14-32bit kernel)

crashme support requires someone with good CPU knowledge to chase
down the holes in the kernel trap handler. It's just not a priority
for anyone I know unfortunately. I'd rather see said person work
on improving fork/exec performance and other lmbench results
where parisc-linux lags horribly. However, if someone wants to
learn more about the space where PARISC implementations diverge
from the architecture, making crashme "run" is a challenging
place to start.

> BTW, one question:
> 
> I always wondered if sid (unstable) is the preferred dist for
> debian/hppa (very likely a debian-mailing-list question, but what
> do you kernel hackers and developers use and prefer?)

I use both depending on the role of the machine.
At home, I'm running sid so I can play frozen-bubble (just kidding,
it's not ported to hppa yet). At work, machines I've setup are
running woody since I want to "test" how well the release is doing
that we will be recommending to non-developers.

Occasionally, sid has "hickups", nothing I haven't been able
to recovery from though it entirely possible trash the machine
(eg bad libc deb). Save those older .debs in /var/cache/apt/archives.

grant

Re: [parisc-linux] some bugs

[M. Grabert]

On Wed, 10 Apr 2002, Grant Grundler wrote:

> "M. Grabert" wrote:
> > But perhaps it's only a h/w issue (incompatibility with switch and
> > network card?).
>
> Possibly. Perhaps just unplugging the cable, wait 5 seconds (or so)
> and plug it back in should force a re-negotiation. Not a great work
> around but perhaps a start.

doesn't work. As somebody other mentioned, no re-negotiation will
work for some strange reason. It was also suggested to set up the
lan configuration in pdc to "100Mbit"; Well, it was already set
to 100Mbit, so I changed it to "Autodetect". Now it seems to work
and re-negotiation also works!

> > Well, yes, maybe, because it's 'mount' specific. But why is it working
> > with the 32bit kernel? I thought this kind of things should be
> > platform-independent ...
>
> I agree - I doubt this is a mount command problem.
> It might be an issue with our 32-bit syscall wrappers in the 64-bit kernels.

I didn't investigate this any further ...

[...]

STIfb support seems to work, I think I was just hallucinating
(or the serial cable was loose). At least it doesn't hang the C240.

The power button works now with 2.4.18-pa16-64! Great work.
Modules also work! I don't see any difference now between in the
behaviour of the 32bit and 64bit version of the kernel ;)

Thanks alot,
   Happy max