headers
cbeerse@gmail.com | 2 Mar 2005 11:28
Picon

Re: [parisc-linux] Upgrading from 2.4 to 2.6

Harry Cochran wrote:

> Thanks for your input. Could it really be true that the "stable" version of
> 2.6 (2.6.8-2-32-smp) can't recognize an ext3 root partition? The only way I
> know to "load a new kernel" since I can only boot fromt he install cd is to
> blow away what I have spent a lot of time building. Seems like I'm missing
> something.

Yes, that is true. IF the ext3 filesystem is not built into the kernel (but 
compiled as a module) then the system cannot use that as the root filesystem. 
Its a kind of chicken and egg problem: the kernel needs to know the filesystem 
to access the modules.

You donnot need to put away a lot: If ext2 is buld-in and ext3 is not, just 
update (downdate...) /etc/fstab to indicate that root is in ext2. I expect ext3 
is readable as ext2 too. If needed you might need to downgrade the root to ext2 
(with `tune2fs`, remove the journalling stuff).

An other idea is to use an other machine to put a kernel on the boot-partition 
that can read ext3.

Then, you can also try to load the ext3 module (or any other module) from an 
other medium like tape, cdrom or network, if the kernel can use that.

Success

CBee

> 
> -----Original Message-----
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rajesh Shah | 18 Mar 2005 22:48
Picon
Favicon

[Patch 1/12] ACPI based root bridge hot-add

When you hot-plug a (root) bridge hierarchy, it may have p2p
bridges and devices attached to it that have not been configured
by firmware. In this case, we need to configure the devices 
before starting them. This patch separates device start from
device scan so that we can introduce the configuration step in
the middle. 

I kept the existing semantics for pci_scan_bus() since there
are a huge number of callers to that function.

Also, I have no way of testing the changes I made to the parisc
files, so this needs review by those folks. Sorry for the massive
cross-post, this touches files in many different places.

Signed-off-by: Rajesh Shah <rajesh.shah <at> intel.com>
---

 linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/common.c   |    2 -
 linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/legacy.c   |    2 +
 linux-2.6.11-mm4-iohp-rshah1/arch/i386/pci/numa.c     |    2 +
 linux-2.6.11-mm4-iohp-rshah1/arch/ia64/pci/pci.c      |    2 -
 linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_bind.c  |   16 +++++++++++-
 linux-2.6.11-mm4-iohp-rshah1/drivers/acpi/pci_root.c  |   24 +++++++++++++++++-
 linux-2.6.11-mm4-iohp-rshah1/drivers/parisc/dino.c    |    1 
 linux-2.6.11-mm4-iohp-rshah1/drivers/parisc/lba_pci.c |    2 +
 linux-2.6.11-mm4-iohp-rshah1/drivers/pci/probe.c      |    2 -
 linux-2.6.11-mm4-iohp-rshah1/include/linux/pci.h      |    8 ++++--
 10 files changed, 53 insertions(+), 8 deletions(-)

diff -puN arch/i386/pci/common.c~pci_serparate_device_add arch/i386/pci/common.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grant Grundler | 20 Mar 2005 00:19
Favicon

Re: J5000 LCD heartbeat

On Sat, Mar 19, 2005 at 10:33:24PM +0000, 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?

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.

> (Incidentally, the INI CC01 is only on the screen - /proc/pdc/led returns the 
> normal kernel version - I assume this is because the message was printed by 
> the hardware, itself?)

The firmware. IIRC, /proc/pdc/led just returns a cached value.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Grant Grundler | 20 Mar 2005 00:20
Favicon

Re: [parisc-linux] Re: J5000 LCD heartbeat

On Sat, Mar 19, 2005 at 04:19:11PM -0700, Grant Grundler wrote:
> 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?

sorry - meant LCD here

> 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.

and here.

grant
Permalink | Reply | 0 comments |
headers
David Pye | 20 Mar 2005 20:18
Picon

Re: J5000 LCD heartbeat

On Saturday 19 March 2005 23:19, Grant Grundler wrote:
> On Sat, Mar 19, 2005 at 10:33:24PM +0000, 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Pye | 20 Mar 2005 20:52
Picon

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thibaut VARENE | 20 Mar 2005 20:40
Favicon

Re: J5000 LCD heartbeat

On Sun, 20 Mar 2005 19:18:29 +0000
David Pye <dmp <at> davidmpye.dyndns.org> wrote:

> On Saturday 19 March 2005 23:19, Grant Grundler wrote:
> > On Sat, Mar 19, 2005 at 10:33:24PM +0000, 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thibaut VARENE | 20 Mar 2005 21:03
Favicon

Re: J5000 LCD heartbeat

On Sun, 20 Mar 2005 19:52:29 +0000
David Pye <dmp <at> davidmpye.dyndns.org> 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 
 <at> 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,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stuart Brady | 20 Mar 2005 22:52

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 
>  <at> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Pye | 21 Mar 2005 00:17
Picon

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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane