2.6.25-rc5-mm1 - Kernel

Hi!

> > It's a pity, I had just nearly finished a new approach. Instead of
> > relying on populate_rootfs() and the filesystem infrastructure, the new
> > approach directly finds the file in the initramfs.
>
> So that avoids the VFS layer issues, but it's still strictly much worse
> than just having a run-time loading.
>
> What's the problem with just loading a new DSDT later? Potentially as in
> *much* later: including when user-space is all up-and-running?
>
> For things like DVD install images, you'd quite possibly want to have a
> few known-workaround DSDT images with the installer, and just say "ok, we
> want to fix up this ACPI crap in order to get working suspend/resume" kind
> of thing.
>
> So what's the reason for pushing for this insanely-early workaround in the
> first place, instead of letting user-space do something like
>
> cat my-dsdt-image > /proc/sys/acpi/DSDT
>
> or whatever at runtime?

You have interpretted code runing (AML), and you want to replace it
with different code?

Akin to changing from one kernel to different during runtime?

Yes, I guess it might work for very simple changes, but if you need to change
data structures between origina and modified DSDT, you are in for a
big trouble, right?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Fri, 2008-03-21 at 14:17 +0100, Pavel Machek wrote:
> > So what's the reason for pushing for this insanely-early workaround in the
> > first place, instead of letting user-space do something like
> >
> > cat my-dsdt-image > /proc/sys/acpi/DSDT
> >
> > or whatever at runtime?
>
> You have interpretted code runing (AML), and you want to replace it
> with different code?
>
> Akin to changing from one kernel to different during runtime?

Heh. That gave me an idea.

Can we use kexec for this? Let's say you get as far in boot as the
initrd and realize that you're running on one of these screwed up
systems. Can you stick the new DSDT somewhere known (and safe) in
memory, and kexec yourself back to the beginning of the kernel boot?

When you boot up the second time, you have the new, shiny DSDT there
which is, of course, used instead of the bogus BIOS one.

It costs you some bootup time, but we're talking about working around
really busted hardware here.

-- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi!
> > > So what's the reason for pushing for this insanely-early workaround in the
> > > first place, instead of letting user-space do something like
> > >
> > > cat my-dsdt-image > /proc/sys/acpi/DSDT
> > >
> > > or whatever at runtime?
> >
> > You have interpretted code runing (AML), and you want to replace it
> > with different code?
> >
> > Akin to changing from one kernel to different during runtime?
>
> Heh. That gave me an idea.
>
> Can we use kexec for this? Let's say you get as far in boot as the
> initrd and realize that you're running on one of these screwed up
> systems. Can you stick the new DSDT somewhere known (and safe) in
> memory, and kexec yourself back to the beginning of the kernel boot?
>
> When you boot up the second time, you have the new, shiny DSDT there
> which is, of course, used instead of the bogus BIOS one.
>
> It costs you some bootup time, but we're talking about working around
> really busted hardware here.

Hmmm. I guess we should turn off acpi mode, kexec, turn on acpi mode
with new dsdt.

Turning off acpi is not exactly easy, but specs describe how to do
it...

So yes, this is hard but doable.

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Pavel Machek wrote:
> Hi!
>> Can we use kexec for this? Let's say you get as far in boot as the
>> initrd and realize that you're running on one of these screwed up
>> systems. Can you stick the new DSDT somewhere known (and safe) in
>> memory, and kexec yourself back to the beginning of the kernel boot?
>>
>> When you boot up the second time, you have the new, shiny DSDT there
>> which is, of course, used instead of the bogus BIOS one.
>>
>> It costs you some bootup time, but we're talking about working around
>> really busted hardware here.
>
> Hmmm. I guess we should turn off acpi mode, kexec, turn on acpi mode
> with new dsdt.
>
> Turning off acpi is not exactly easy, but specs describe how to do
> it...
Why do you think it's necessary to turn off acpi mode? What will not
work if we keep it on all the time?

BTW, let me summarize my understanding of the kexec approach:
* the userspace write the new DSDT (cat my-dsdt-image >
/sys/firmware/acpi/tables/DSDT)
* the kernel don't use this DSDT directly but keeps it somewhere warm
and fuzzy in the RAM
* userspace does a kexec
* the new kernel boots and at some (early) point, dsdt_override() is
called. It detects that the special place in the RAM for a new DSDT is
used. It provides this pointer to ACPI as the new place to read the DSDT.

Dave, am I correctly understanding the scenario you had in mind?

I have pratically no knowledge of kexec. Is there a documented way to
pass big chunk of data from one kernel to another one? How can I do that?

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Mon, 2008-03-24 at 18:05 +0100, Eric Piel wrote:
> BTW, let me summarize my understanding of the kexec approach:
> * the userspace write the new DSDT (cat my-dsdt-image >
> /sys/firmware/acpi/tables/DSDT)
> * the kernel don't use this DSDT directly but keeps it somewhere warm
> and fuzzy in the RAM
> * userspace does a kexec
> * the new kernel boots and at some (early) point, dsdt_override() is
> called. It detects that the special place in the RAM for a new DSDT is
> used. It provides this pointer to ACPI as the new place to read the DSDT.
>
> Dave, am I correctly understanding the scenario you had in mind?

Yeah, that's basically what I was thinking.

But, this is only for a case where we can't do the real runtime
replacement that Linus has been advocating. That approach is clearly
superior, but I would imagine that it'll require some serious ACPI
surgery and won't cover things like if the SRAT table was messed up.

> I have pratically no knowledge of kexec. Is there a documented way to
> pass big chunk of data from one kernel to another one? How can I do that?

Heh. Documented, no. What OS do you think this is? I'm not sure it
has ever been really needed before.

At one point, kexec just make a copy of the e820 table to tell the new
kernel where it's ram was. If you carved out a chunk of memory and set
it as reserved, the new kernel could go looking there.

kexec is Eric Biederman's (on cc) baby, and he might have some more
concrete suggestions for you.

-- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Mon 2008-03-24 18:05:14, Eric Piel wrote:
> Pavel Machek wrote:
>> Hi!
>>> Can we use kexec for this? Let's say you get as far in boot as the
>>> initrd and realize that you're running on one of these screwed up
>>> systems. Can you stick the new DSDT somewhere known (and safe) in
>>> memory, and kexec yourself back to the beginning of the kernel boot?
>>>
>>> When you boot up the second time, you have the new, shiny DSDT there
>>> which is, of course, used instead of the bogus BIOS one.
>>>
>>> It costs you some bootup time, but we're talking about working around
>>> really busted hardware here.
>>
>> Hmmm. I guess we should turn off acpi mode, kexec, turn on acpi mode
>> with new dsdt.
>>
>> Turning off acpi is not exactly easy, but specs describe how to do
>> it...
> Why do you think it's necessary to turn off acpi mode? What will not work
> if we keep it on all the time?
>
> BTW, let me summarize my understanding of the kexec approach:
> * the userspace write the new DSDT (cat my-dsdt-image >
> /sys/firmware/acpi/tables/DSDT)
> * the kernel don't use this DSDT directly but keeps it somewhere warm and
> fuzzy in the RAM
> * userspace does a kexec
> * the new kernel boots and at some (early) point, dsdt_override() is
> called. It detects that the special place in the RAM for a new DSDT is
> used. It provides this pointer to ACPI as the new place to read the
> DSDT.

Yes, and now ACPI layer tries to enable already enabled ACPI... which
is no-no according to spec, but you may be able to get away with it.

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
pomozte zachranit klanovicky les: http://www.ujezdskystrom.info/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andrew Morton wrote:
[...]
> Yes, I was hitting the text_poke() oops with 2.6.25-rc3-mm1 but not with
> 2.6.25-rc5-mm1.
>
> This _might_ have been due to a snafu in git-x86: it had a [patch 2/2] from
> Mathieu but was missing the needed [patch 1/2]. But I don't know if this
> was the cause and I don't know whether 2.6.25-rc3-mm1's git-x86 had the
> same problem.
>
The problem seems to be solved in 2.6.25-rc6.

Helge Hafting
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Dave Hansen wrote:
> On Fri, 2008-03-21 at 14:17 +0100, Pavel Machek wrote:
>
>>> So what's the reason for pushing for this insanely-early workaround in the
>>> first place, instead of letting user-space do something like
>>>
>>> cat my-dsdt-image > /proc/sys/acpi/DSDT
>>>
>>> or whatever at runtime?
>>>
>> You have interpretted code runing (AML), and you want to replace it
>> with different code?
>>
>> Akin to changing from one kernel to different during runtime?
>>
>
> Heh. That gave me an idea.
>
> Can we use kexec for this? Let's say you get as far in boot as the
> initrd and realize that you're running on one of these screwed up
> systems. Can you stick the new DSDT somewhere known (and safe) in
> memory, and kexec yourself back to the beginning of the kernel boot?
>
> When you boot up the second time, you have the new, shiny DSDT there
> which is, of course, used instead of the bogus BIOS one.
>
I see a problem here.
This could work. And if it is successful, the "kexec reboot around
busted hw"-trick
is used for other stuff as well.

So your broken machine reboots with some fix, then it reboots with the
custom DSDT. Is the previous fix preserved? Then a third problem is hit,
another kexec reboot. Is the first fix _and_ the custom DSDT
preserved on this reboot? Or do we get an infinite sequence of reboots,
alternating between a couple of completely unrelated fixes for bad
hw/bios...

Once there is more than one fix utilizing this trick, some "protocol" for
managing a string of kexec fixes might become necessary.

Helge Hafting

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hello,

The gregkh-pci-pci-sparc64-use-generic-pci_enable_resources.patch which
replaces arch-specific code with generic pci_enable_resources() makes my sparc64
box unable to boot (that's what quilt bisection says). At first I see these messages:

hme 0000:00:01.1: device not available because of BAR 0 [1ff80008000:1ff8000f01f] collisions
sym53c8xx 0000:00:03.0: device not available because of BAR 0 [1fe02010400:1fe020104ff] collisions
sym53c8xx 0000:00:03.1: device not available because of BAR 0 [1fe02010800:1fe020108ff] collisions

and finally, infamous

VFS: Cannot open root device "sda3" or unknown-block(0,0)

Mariusz

PS. I attached .config used at bisection time.

# lspci
0000:00:00.0 Host bridge: Sun Microsystems Computer Corp. Psycho PCI Bus Module
0000:00:01.0 Bridge: Sun Microsystems Computer Corp. EBUS (rev 01)
0000:00:01.1 Ethernet controller: Sun Microsystems Computer Corp. Happy Meal (rev 01)
0000:00:03.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 14)
0000:00:03.1 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 14)
0001:00:00.0 Host bridge: Sun Microsystems Computer Corp. Psycho PCI Bus Module

$ uname -a
Linux sparc64 2.6.25-rc5 #2 SMP PREEMPT Fri Mar 28 12:16:30 CET 2008 sparc64 sun4u TI UltraSparc II (BlackBird) GNU/Linux

From: Mariusz Kozlowski
Date: Fri, 28 Mar 2008 23:52:10 +0100

> The gregkh-pci-pci-sparc64-use-generic-pci_enable_resources.patch which
> replaces arch-specific code with generic pci_enable_resources() makes my sparc64
> box unable to boot (that's what quilt bisection says). At first I see these messages:

Yes, that generic code won't work because of the NULL
r->parent check.

Alpha, ARM, V32, FRV, IA64, MIPS, MN10300, PARISC, PPC,
SH, V850, X86, and Xtensa are all likely to run into
problems because of this change.

The only platform that did the check as a test of r->parent
being NULL is Powerpc.

The rest either didn't check (like sparc64), or tested it by going:

if (!r->start && r->end)

So the amount of potential breakage from this change is enormous.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Fri, 2008-03-28 at 16:10 -0700, David Miller wrote:
> From: Mariusz Kozlowski
> Date: Fri, 28 Mar 2008 23:52:10 +0100
>
> > The gregkh-pci-pci-sparc64-use-generic-pci_enable_resources.patch which
> > replaces arch-specific code with generic pci_enable_resources() makes my sparc64
> > box unable to boot (that's what quilt bisection says). At first I see these messages:
>
> Yes, that generic code won't work because of the NULL
> r->parent check.
>
> Alpha, ARM, V32, FRV, IA64, MIPS, MN10300, PARISC, PPC,
> SH, V850, X86, and Xtensa are all likely to run into
> problems because of this change.

ppc and x86 won't have problem, I haven't checked the others, sparc64
will as I see things.

> The only platform that did the check as a test of r->parent
> being NULL is Powerpc.

Yup, though that makes sense to do it that way on platforms that
actually build a resource tree like x86 or powerpc.

> The rest either didn't check (like sparc64), or tested it by going:
>
> if (!r->start && r->end)
>
> So the amount of potential breakage from this change is enormous.

Not that big, but yeah, it should be limited to platforms that actually
build a resource-tree and keep track of assigned & allocated resources,
which sparc64 doesn't (which is fair enough, if your firmware is 100%
right and your kernel never has to assigns things itself). The NULL
parent is a 100% indication that the resource was properly claimed and
put in the resource-tree (and thus is non conflicting) on those
platforms, but it's unused on sparc64.

Basically, on platforms like x86 or powerpc, the PCI subsystem at boot
builds a resource tree by collecting resources for all enabled devices
and bridges in a first pass, then all others in a second pass, checking
for conflicts or unassigned ones, and potentially re-assigning and
re-allocating bridges if necessary.

Sparc64 takes a different approach, it basically doesn't bother with a
full resource tree, and just claims what driver claim, which is fine as
long as you are certain that you always get a perfectly well assigned &
non conflicting setup done by your firmware.

The "full featured" approach is necessary for platforms where this isn't
the case, such as powerpc, even with a pretty good OF like Apple ones,
since they love to not assign resources that they know their MacOS
driver will not need (such as not assigning IO space and closing it on
the P2P bridge) which doesn't necessarily quite work with the
requirements of the linux drivers, in addition to also gross bugs they
have on some versions when using cards with P2P bridges on them.

In addition, we also need that resource management to be able to
dynamically assign resource after boot as our OF doesn't stay alive to
do it, such as when using cardbus cards, or other type of hotplug things
for which the firmware doesn't do dynamic resource allocation.

So, the meat of the original patch isn't bad per-se. There is definitely
a lot of interest in making a lot of this resource survey and management
code common for platforms who want it (for example, powerpc and x86 are
very close already), and in that regard, this NULL check is definitely
what we want in the "merged" version. But I can understand David
unwillingness in bringing that whole infrastructure on platforms that
don't need it.

A quick survey shows that:

- Use what looks like a full featured resource allocation scheme similar
to x86: alpha, powerpc, ppc,

- Use what looks like a slightly different scheme that still results in
resources being claimed in the resource tree when valid: ia64, mips (not
100% sure there, but it does call pci_assign_unassigned_resources),

- Don't build a resource-tree per-se and don't claim device resources
(and thus NULL parent check is unreliable): sparc, sparc64, parisc ?
(unsure but I didn't see code to claim resources in the pci layer), arm
(unsure but PCI here seems to be spread in sub platform code and doesn't
appear to do resource management)

And I stopped there. So we have people on all sides of the fence but it
would still be worth consolidating at least x86, alpha & powerpc, and
possibly bring in others like ia64 and mips.

Cheers,
Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/