Re: J5000 LCD heartbeat
On Saturday 19 March 2005 23:19, Grant Grundler wrote: On Sat, Mar 19, 2005 at 10:33:24PM +, David Pye wrote: The other thing is that the kernel version which is displayed on the lcd by default is overwritten partly by a: INI CC01 It's not a huge issue for me, as I can overwrite it again by echo'ing my message into /proc/pdc/lcd post boot. This is the firmware showing the Chassis Log as emitted by the kernel. Some platforms (e.g. A500/rp2470) use chassis logs to set the LED properly. Is it possible to make the write to the display later in the boot process, so it occurs after the INI CC01 is printed? I would think it's possible. You want to track down where the CC01 chassis_log is emitted then propose a better place to initialize LED display? I think I have an idea that it's related to CPU1 init, but I haven't confirmed this yet - depending on your feedback to the idea below, I won't bother tracing it down. Another idea is the chassis log code might want to clear the LED diplay when displaying a chassis log and then a few seconds later refresh the LED display with the original contents or something. At the very least, I think it needs to clear the lcd display before it sends the chassis code to the PDC. How does this sound: Clear the lcd Send the chassis code set up a timer for 15 seconds, say, to restore the original display text This requires a couple of changes to led.c so firmware.c can tell whether the machine has an LCD or not. (If it does, then do the above, otherwise just send the chassis code as before.) If you agree that this is something useful, I will do some more hacking on it. Otherwise, I'll do the other option and arrange the the chassis log to be sent before the lcd has the initial text printed on it. Another idea I had was this: How about making the text scrollable? ie if the string is longer than the viewport, scroll it along at a reasonable rate. I'm willing to have a play with this too, if people think it's something worth having. Did you have any hints you could give me as to fix my very occasional heartbeat issue either? Cheers, David snip thanks, grant pgphpXzZx7vWC.pgp Description: PGP signature
Re: J5000 LCD heartbeat
Hi, and thanks for your reply. On Sunday 20 March 2005 19:40, you wrote: I think I have an idea that it's related to CPU1 init, but I haven't confirmed this yet - depending on your feedback to the idea below, I won't bother tracing it down. Don't bother. I have that kind of message left on my j5k LCD has well, that's been there for ages, without problem. Well, I'd like to see it gone myself, even though it doesn't do anything unpleasant. It is a little messy, at least having it mangled up with the Linux default text is. If all it takes to prevent it is to make the lcd init happen slightly later in the boot process (ie after the chassis code was emitted), I'd have thought it would be an easy win. If you think about the firmware code that drives the display of chassis messages, it's firmware, changing how it works is pretty much not possible at that point. If you think about the PDC Chassis driver, that code doesn't work (read, isn't activated) on j5k and other System Map firmware machines, it only works on PDC PAT machines (eg high end servers). Yeah, true. So, if the PDC chassis driver isn't used on the j5k, how does the chassis message get sent from the kernel to the PDC? I haven't worked that out yet. I don't think this is either useful nor desirable. We want to have the firmware messages going over whatever the led/lcd driver would have shown, and going into such a pain for a corner case doesn't really seem worth it. At the very least, clearing the display first before the message is shown would have been helpful, imho. I'd personally like to have the firmware message displayed only for a limited time, though I can see a counter argument for this. But not for having cleared the display first, though. (Whether this is possible depends on your answer as to how the PDC is told to display the message!) Another idea I had was this: How about making the text scrollable? ie if the string is longer than the viewport, scroll it along at a reasonable rate. That has been considered and eventually ruled out. Remember we're in kernel context, this is not meant to be eye candy etc. The pretty formatting you suggest should be eventually a userland task, certainly not a supplementary burden for the kernel. Yep, agreed, that probably isn't a worthwhile thing to add. I was just thinking of other random ideas, that's all. Did you have any hints you could give me as to fix my very occasional heartbeat issue either? I recall that the LCD heartbeat is quite slow on my j5k as well, but nothing really awful, afaicr. Well, here it's sufficiently slow to be utterly useless as a heartbeat, anyway. It usually flips state every 10-30 seconds, depending on how it feels. It certainly doesn't boot. I realise the LCD functionality is something fairly minor, and that I'm being picky, but I'd be happy to invest some time to do some fine tuning. The only two must-haves for me is to nail the INI CC01 message being displayed over the Linux kernel version display, and preferably to make my heart beat too ;) Thanks, David HTH Thibaut VARENE The PA/Linux Team http://www.pateam.org/ pgpqbXe1LIxfs.pgp Description: PGP signature
Re: J5000 LCD heartbeat
On Sun, 20 Mar 2005 19:18:29 + David Pye [EMAIL PROTECTED] wrote: On Saturday 19 March 2005 23:19, Grant Grundler wrote: On Sat, Mar 19, 2005 at 10:33:24PM +, David Pye wrote: Is it possible to make the write to the display later in the boot process, so it occurs after the INI CC01 is printed? I would think it's possible. You want to track down where the CC01 chassis_log is emitted then propose a better place to initialize LED display? I think I have an idea that it's related to CPU1 init, but I haven't confirmed this yet - depending on your feedback to the idea below, I won't bother tracing it down. Don't bother. I have that kind of message left on my j5k LCD has well, that's been there for ages, without problem. Another idea is the chassis log code might want to clear the LED diplay when displaying a chassis log and then a few seconds later refresh the LED display with the original contents or something. At the very least, I think it needs to clear the lcd display before it sends the chassis code to the PDC. How does this sound: If you think about the firmware code that drives the display of chassis messages, it's firmware, changing how it works is pretty much not possible at that point. If you think about the PDC Chassis driver, that code doesn't work (read, isn't activated) on j5k and other System Map firmware machines, it only works on PDC PAT machines (eg high end servers). Clear the lcd Send the chassis code set up a timer for 15 seconds, say, to restore the original display text This requires a couple of changes to led.c so firmware.c can tell whether the machine has an LCD or not. (If it does, then do the above, otherwise just send the chassis code as before.) AFAIK, it's not possible for the led.c driver to figure out whether the firmware has sent anything to the LCD display. If you agree that this is something useful, I will do some more hacking on it. Otherwise, I'll do the other option and arrange the the chassis log to be sent before the lcd has the initial text printed on it. I don't think this is either useful nor desirable. We want to have the firmware messages going over whatever the led/lcd driver would have shown, and going into such a pain for a corner case doesn't really seem worth it. Another idea I had was this: How about making the text scrollable? ie if the string is longer than the viewport, scroll it along at a reasonable rate. That has been considered and eventually ruled out. Remember we're in kernel context, this is not meant to be eye candy etc. The pretty formatting you suggest should be eventually a userland task, certainly not a supplementary burden for the kernel. At some point we looked after writing a complete driver for the LCD display, but it happens that it's much more complicated than first expected. For instance, accessing the other row of the LCD is almost impossible. In any case, it would probably consume resource for nothing really worth it. I'm willing to have a play with this too, if people think it's something worth having. IMHO it's not. Did you have any hints you could give me as to fix my very occasional heartbeat issue either? I recall that the LCD heartbeat is quite slow on my j5k as well, but nothing really awful, afaicr. HTH Thibaut VARENE The PA/Linux Team http://www.pateam.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: J5000 LCD heartbeat
On Sun, 20 Mar 2005 19:52:29 + David Pye [EMAIL PROTECTED] wrote: Hi, and thanks for your reply. On Sunday 20 March 2005 19:40, you wrote: I think I have an idea that it's related to CPU1 init, but I haven't confirmed this yet - depending on your feedback to the idea below, I won't bother tracing it down. Don't bother. I have that kind of message left on my j5k LCD has well, that's been there for ages, without problem. Well, I'd like to see it gone myself, even though it doesn't do anything unpleasant. It is a little messy, at least having it mangled up with the Linux default text is. If all it takes to prevent it is to make the lcd init happen slightly later in the boot process (ie after the chassis code was emitted), I'd have thought it would be an easy win. it's not that simple. If you want to have it gone, add @reboot echo /proc/pdc/lcd in your root crontab :) If you think about the firmware code that drives the display of chassis messages, it's firmware, changing how it works is pretty much not possible at that point. If you think about the PDC Chassis driver, that code doesn't work (read, isn't activated) on j5k and other System Map firmware machines, it only works on PDC PAT machines (eg high end servers). Yeah, true. So, if the PDC chassis driver isn't used on the j5k, how does the chassis message get sent from the kernel to the PDC? I haven't worked that out yet. That message is a *firmware* one. It is send by the machine itself, not by anything in the kernel (at least, directly). I don't think this is either useful nor desirable. We want to have the firmware messages going over whatever the led/lcd driver would have shown, and going into such a pain for a corner case doesn't really seem worth it. At the very least, clearing the display first before the message is shown would have been helpful, imho. As i told you, this is not possible. The firmware doesn't know there's already something on the display. And you don't want to rewrite the PDC firmware, do you? :) I'd personally like to have the firmware message displayed only for a limited time, though I can see a counter argument for this. But not for having cleared the display first, though. (Whether this is possible depends on your answer as to how the PDC is told to display the message!) This is certainly not a good idea, but if you want that, add the following to your root crontab: */10 * * * * echo /proc/pdc/lcd This will redraw the original message every 10mn. Did you have any hints you could give me as to fix my very occasional heartbeat issue either? I recall that the LCD heartbeat is quite slow on my j5k as well, but nothing really awful, afaicr. Well, here it's sufficiently slow to be utterly useless as a heartbeat, anyway. It usually flips state every 10-30 seconds, depending on how it feels. It certainly doesn't boot. I realise the LCD functionality is something fairly minor, and that I'm being picky, but I'd be happy to invest some time to do some fine tuning. The only two must-haves for me is to nail the INI CC01 message being displayed over the Linux kernel version display, and preferably to make my heart beat too ;) The LED/LCD driver uses tasklets, which are quite CPU expensive. I think this is one of the reason the heartbeat is slow. Though 30s seems alot to me either. HTH Thibaut VARENE The PA/Linux Team http://www.pateam.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [parisc-linux] Re: J5000 LCD heartbeat
On Sun, Mar 20, 2005 at 09:03:57PM +0100, Thibaut VARENE wrote:
it's not that simple.
If you want to have it gone, add
@reboot echo /proc/pdc/lcd
in your root crontab :)
BTW, If anyone really wants scrolling, this script should do it. It has
to use character 16 for spaces, which is a bit broken -- YMMV.
#!/bin/bash
STR=Linux $(uname -r)
END=
# Prevent the PDC from stripping leading spaces by
# using character 16 (octal 20) as a space...
STR=$(echo $STR | tr ' ' '\20')
while(true); do
echo ${STR}${END} /proc/pdc/lcd
END=${END}${STR:0:1}
STR=${STR:1}
if [ -z ${STR:-} ]; then
STR=${END}
END=
fi
sleep 0.25
done
The character set is interesting:
1-8 for the disk/network/heartbeat symbols
32-127 are the standard ascii characters, except that:
92 is a yen symbol
126 is a left arrow
127 is a right arrow
128-159 are unused
160-254 seem to be a mix of japanese, greek and accented roman letters
240 is an empty box
255 is a filled in square
Hope that helps,
--
Stuart Brady
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: J5000 LCD heartbeat
On Sunday 20 March 2005 20:03, Thibaut VARENE wrote: On Sun, 20 Mar 2005 19:52:29 + David Pye [EMAIL PROTECTED] wrote: Hi, and thanks for your reply. On Sunday 20 March 2005 19:40, you wrote: I think I have an idea that it's related to CPU1 init, but I haven't confirmed this yet - depending on your feedback to the idea below, I won't bother tracing it down. Don't bother. I have that kind of message left on my j5k LCD has well, that's been there for ages, without problem. snip it's not that simple. If you want to have it gone, add @reboot echo /proc/pdc/lcd in your root crontab :) I think that's a perfectly acceptable solution for me, so I've done that. Thankyou! snip Did you have any hints you could give me as to fix my very occasional heartbeat issue either? I recall that the LCD heartbeat is quite slow on my j5k as well, but nothing really awful, afaicr. Well, here it's sufficiently slow to be utterly useless as a heartbeat, anyway. It usually flips state every 10-30 seconds, depending on how it feels. It certainly doesn't boot. I realise the LCD functionality is something fairly minor, and that I'm being picky, but I'd be happy to invest some time to do some fine tuning. The only two must-haves for me is to nail the INI CC01 message being displayed over the Linux kernel version display, and preferably to make my heart beat too ;) The LED/LCD driver uses tasklets, which are quite CPU expensive. I think this is one of the reason the heartbeat is slow. Though 30s seems alot to me either. Well, I've had a bit of a play with this, and think I have a feel of what causes it. The led_LCD_driver() fires each time the tasklet decides the led statuses should change, but each time it only updates at best one of the four LEDs. Every time it fires, it either updates one led, or it writes the command register, to avoid sleeping. This means, that it requires eight fires of the tasklet (and eight times of it having decided an LCD state should flip) before the heartbeat will be written to. It seems to be a rare occasion that these all line up (most of the time the heartbeat has pulsed back to its previous state before the LCD panel itself gets updated. I'm wondering whether it's worth doing one of the following: Add a separate workqueue and use that instead of the tasklet, as the workqueue function can sleep, update the heartbeat each time it fires, as well as any of the other LEDs that have changed state. Add a single workqueue item for the heartbeat LED and use the tasklet to handle the rest of the LEDs, as it seems to do an acceptable job for them. What are your thoughts on that? Cheers, David HTH Thibaut VARENE The PA/Linux Team http://www.pateam.org/ pgpJKhjbzcb6e.pgp Description: PGP signature
Re: J5000 LCD heartbeat
On Sunday 20 March 2005 22:57, David Pye wrote:
Well, I've had a bit of a play with this, and think I have a feel of what
causes it.
The led_LCD_driver() fires each time the tasklet decides the led statuses
should change, but each time it only updates at best one of the four LEDs.
Every time it fires, it either updates one led, or it writes the command
register, to avoid sleeping. This means, that it requires eight fires of
the tasklet (and eight times of it having decided an LCD state should flip)
before the heartbeat will be written to. It seems to be a rare occasion
that these all line up (most of the time the heartbeat has pulsed back to
its previous state before the LCD panel itself gets updated.
It appears my hunch was correct
/* update the LCD/LEDs */
if (currentleds != lastleds || led_type == LED_HASLCD) {
led_func_ptr(currentleds);
lastleds = currentleds;
}
If I modify the conditional as above, so it fires the led_func_ptr each time
the tasklet fires for LCD users (even if the leds haven't nominally changed)
my heart beats!
Admittedly, it doesn't QUITE beat right, because of the rate the tasklet
fires, and the rate at which the heart is supposed to beat.
I'm convinced another solution, like one of the ones I mentioned earlier, is a
better idea, of course.
I now get:
a normal double beat, followed a single beat (repeats).
Which is better than no beats at all in my book!
Cheers,
David
Cheers,
David
pgpbvA39WCx6j.pgp
Description: PGP signature
hppa ....all distribs i could find for a hp 9000 k210
hello all i have spent a couple weeks trying to get my brand new ..to me server up ...i have burned 25 iso's read every hppa post my imagination could get up..hacked and slashed /DEV AND INIT* ..RCS* AND JUST GENERALLY ..OPS CAPS... everything i can think off...which is a fair amount been hacking a few years. Ok here is the problem...this is the image that is supposed to work with my system...2.4.18-pa46. and every one after :)...There is no debian dist. smp that doesnt crash on boot that i can downloadand insult to injury that image cant be found...at least not with searches i have advailable... ok enough rant,,,well almost...i think the newer woody dist sucks for hppa , im sure on i386 and others it fast and great ..but a woody or sarge install on a hppa is just a waste of time ..takes 3-5 mins for partman to scan and come up with a scsi list...cant mount partitionseven with priority lowim on a k-class server so im a small crowd..but so far ..my 210 and my works 460 ..im not happy with the hppa port. its sad i have to use a pa-2.4.20-pa3 iso to hack into a woody or sarge install because those dist take 20 mins to give me a partition table or a menu? Now that ive insulted the entire hppa development community ..here is my problem..id i do a net...cd install of woody or sarge..not even smp..i lose my console when debian gets to init 2i hacked into one the rc files to get a su login ..but my console only works in runlevel 1 or "S" ..i can telnet in now and play with the system..but there is a serious install or login script error on K-class or with seeing ttyB0 as console. ive been looking for days and i think because the install always breaks...no console.. that this may be a rare error on this class or an unaddressed one..I'm sure its an easy fix ..but i'm not seeing itmy last best hope is to do a firmware upgrade and maybe firmware map will jive with kernel'ssigh..hope i dont dead box my sys LOL when i get this one fixed ..gunna work the spinlock errors on smpKERNAL PANICDUMP..HALT at least if i get that far i can make my own kernel ..hehe mx
