Any chance to get an ACPI update into 2.4.20 ?
It doesn't like my Intel D845PESV.
Margit
On Tue, Nov 19, 2002 at 01:53:15PM +0100, Margit Schubert-While wrote:
> Any chance to get an ACPI update into 2.4.20 ?
Now that we're in 2.4.20rc stage ? No chance.
> It doesn't like my Intel D845PESV.
The newer ACPI code also introduces problems that aren't
present with the current 2.4.20rc code.
Eg: Last snapshot I tried, My Vaio wouldn't boot if it was
running on battery (which is the time I'd need it most).
It needs a lot more testing.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Hi Dave,
On Tue, Nov 19, 2002 at 01:07:28PM +0000, Dave Jones wrote:
> On Tue, Nov 19, 2002 at 01:53:15PM +0100, Margit Schubert-While wrote:
> > Any chance to get an ACPI update into 2.4.20 ?
>
> Now that we're in 2.4.20rc stage ? No chance.
>
> > It doesn't like my Intel D845PESV.
>
> The newer ACPI code also introduces problems that aren't
> present with the current 2.4.20rc code.
I disagree with you. It introduces more enhancements,
and more bugfix than the current code. I admit that tt
could introduce some news bugs, but in the balance it
should be more stable than before.
Really, I will be happy to see new code in mainstream.
> Eg: Last snapshot I tried, My Vaio wouldn't boot if it was
> running on battery (which is the time I'd need it most).
What is actually the trouble with your Vaio (I mean dmesg when
it failed) ? I saw some (old) Vaio where new code worked
like a charm (even speedstep worked, but it's another
story ;)
I would be happy also to take a look to the DSDT table of your model.
Cheers,
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page
On Tue, Nov 19, 2002 at 03:27:31PM +0100, Ducrot Bruno wrote:
>...
> I disagree with you. It introduces more enhancements,
> and more bugfix than the current code. I admit that tt
> could introduce some news bugs, but in the balance it
> should be more stable than before.
>...
It's not "in the balance". 2.4 is a stable kernel series. The problem is
that if you switch from one stable kernel series to another
(e.g. 2.2 -> 2.4) on a production machine you know that you have to
check whether everything works as before you upgrade your production
machines. This can take quite some time. Within a stable kernel series
everything that worked in earlier kernels within this series should work
in future kernels in this kernel series. Don't forget that e.g. a
fixed security problem might force people to do a quick upgrade of
production machines to the latest kernel in this series.
There's always the possibility that you apply patches or use one of the
many two-to-four-letter patches which might contain the patch you
need.
Note: I don't know the specific situation with the new ACPI code and
whether it might be good to include it, my arguments are an
answer to your "in the balance" argument.
> Cheers,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, Nov 19, 2002 at 03:27:31PM +0100, Ducrot Bruno wrote:
> > The newer ACPI code also introduces problems that aren't
> > present with the current 2.4.20rc code.
> I disagree with you. It introduces more enhancements,
> and more bugfix than the current code. I admit that tt
> could introduce some news bugs, but in the balance it
> should be more stable than before.
> Really, I will be happy to see new code in mainstream.
In fact, the problem with my Vaio happens due to the changes
_already_ in 2.4.20pre. I'm now backing them out to try and
isolate the exact changes that caused the problem.
This is exactly the sort of thing I meant. The ACPI stuff is
so fragile a few tiny changes makes a box unbootable.
Merging nearly 3MB of changes at this stage would be lunacy.
Save it for .20pre
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
On Tue, Nov 19, 2002 at 03:27:31PM +0100, Ducrot Bruno wrote:
> > The newer ACPI code also introduces problems that aren't
> > present with the current 2.4.20rc code.
Got it. This actually isn't a problem with new ACPI code, but
the addition of the new stack overflow check. It falls flat on
its face really early if that is enabled.
The box is totally dead before console is initialised, so I
don't have backtraces, I'll give that a shot with a serial
console later. In the meantime, acpi folks should probably
try testing with CONFIG_DEBUG_STACKOVERFLOW=y to see if they
hit the same problems I'm getting.
Back later..
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
On Tue, Nov 19, 2002 at 06:30:54PM +0000, Dave Jones wrote:
> On Tue, Nov 19, 2002 at 03:27:31PM +0100, Ducrot Bruno wrote:
> > > The newer ACPI code also introduces problems that aren't
> > > present with the current 2.4.20rc code.
>
> Got it. This actually isn't a problem with new ACPI code, but
> the addition of the new stack overflow check. It falls flat on
> its face really early if that is enabled.
>
> The box is totally dead before console is initialised, so I
> don't have backtraces, I'll give that a shot with a serial
> console later. In the meantime, acpi folks should probably
> try testing with CONFIG_DEBUG_STACKOVERFLOW=y to see if they
> hit the same problems I'm getting.
>
BTW, did you use the sonyip driver? I am not sure at 100% but
it look like that it request the same irq line than acpi...
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page
Hi,
I have a sony vaio qr10 and I use the sonypi driver.
If I boot the screen output will stop during acpi init and the notebook boots
(but no screen output). I can use vnc but....
I think this also happens in 2.4, 2.5 isn't better in this.
I will try to build the kernel without sonypi (never done that) maybe it
helps.
have fun
Felix
Am Wednesday 20 November 2002 07:37 schrieb Ducrot Bruno:
> On Tue, Nov 19, 2002 at 06:30:54PM +0000, Dave Jones wrote:
> > On Tue, Nov 19, 2002 at 03:27:31PM +0100, Ducrot Bruno wrote:
> > > > The newer ACPI code also introduces problems that aren't
> > > > present with the current 2.4.20rc code.
> >
> > Got it. This actually isn't a problem with new ACPI code, but
> > the addition of the new stack overflow check. It falls flat on
> > its face really early if that is enabled.
> >
> > The box is totally dead before console is initialised, so I
> > don't have backtraces, I'll give that a shot with a serial
> > console later. In the meantime, acpi folks should probably
> > try testing with CONFIG_DEBUG_STACKOVERFLOW=y to see if they
> > hit the same problems I'm getting.
>
> BTW, did you use the sonyip driver? I am not sure at 100% but
> it look like that it request the same irq line than acpi...
On Wed, Nov 20, 2002 at 11:29:19AM +0100, Felix Seeger wrote:
> Hi,
>
> I have a sony vaio qr10 and I use the sonypi driver.
> If I boot the screen output will stop during acpi init and the notebook boots
> (but no screen output). I can use vnc but....
>
> I think this also happens in 2.4, 2.5 isn't better in this.
> I will try to build the kernel without sonypi (never done that) maybe it
> helps.
>
What I mean is that the two seems to conflict.
Compiling with sonypi but without acpi is OK, without sonypi but
with acpi should also be OK, but the two should be not safe because
they use the same io registers in order to ack/clean/enable the same
interrupt.
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page
Hi!
> >...
> > I disagree with you. It introduces more enhancements,
> > and more bugfix than the current code. I admit that tt
> > could introduce some news bugs, but in the balance it
> > should be more stable than before.
> >...
>
> It's not "in the balance". 2.4 is a stable kernel series. The problem is
> that if you switch from one stable kernel series to another
> (e.g. 2.2 -> 2.4) on a production machine you know that you have to
> check whether everything works as before you upgrade your production
> machines. This can take quite some time. Within a stable kernel series
> everything that worked in earlier kernels within this series should work
> in future kernels in this kernel series. Don't forget that e.g. a
> fixed security problem might force people to do a quick upgrade of
> production machines to the latest kernel in this series.
ACPI is marked experimental (and it *is* experimental), if you run it
on production machine you loose.
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
On Sat, Nov 23, 2002 at 08:57:20PM +0100, Pavel Machek wrote:
> ACPI is marked experimental (and it *is* experimental), if you run it
> on production machine you loose.
Nice. Shame about all those boxes that won't boot without ACPI.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
On Mon, 2002-11-25 at 13:15, Dave Jones wrote:
> On Sat, Nov 23, 2002 at 08:57:20PM +0100, Pavel Machek wrote:
>
> > ACPI is marked experimental (and it *is* experimental), if you run it
> > on production machine you loose.
>
> Nice. Shame about all those boxes that won't boot without ACPI.
Fortunately there are very very few of those, with the exception of some
laptops with defective IRQ routing tables where the ACPI table happens
to be correct.
[email protected] said:
> Nice. Shame about all those boxes that won't boot without ACPI.
I've heard a lot about such beasts but have never actually _met_ one.
If I accidentally bought a box which wouldn't boot without ACPI, it would
go immediately back from whence it came -- just as it would if it turned up
with an nVidia graphics card.
--
dwmw2
On Mon, 25 Nov 2002, David Woodhouse wrote:
> [email protected] said:
> > Nice. Shame about all those boxes that won't boot without ACPI.
>
> I've heard a lot about such beasts but have never actually _met_ one.
>
> If I accidentally bought a box which wouldn't boot without ACPI, it would
> go immediately back from whence it came -- just as it would if it turned up
> with an nVidia graphics card.
A Vaio GR390 comes very close to not booting without the patches from
acpi.sourceforge.net.
--
-- John E. Jasen ([email protected])
-- User Error #2361: Please insert coffee and try again.
Hi!
> > Nice. Shame about all those boxes that won't boot without ACPI.
>
> I've heard a lot about such beasts but have never actually _met_ one.
>
> If I accidentally bought a box which wouldn't boot without ACPI, it would
> go immediately back from whence it came -- just as it would if it turned up
> with an nVidia graphics card.
I have omnibook xe3, will boot without ACPI but USB will not work due
to interrupt routing problems. It has buggy PIR$ table, acpi tables
are okay. Of course it is HP bug.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
[email protected] said:
> I have omnibook xe3, will boot without ACPI but USB will not work due
> to interrupt routing problems. It has buggy PIR$ table, acpi tables
> are okay. Of course it is HP bug.
BIOS authors are universally shite. Film at 11.
If it didn't have working ACPI tables either, what would we do? Probably fix
it with a DMI table entry. This box probably doesn't actually require ACPI
to boot.
--
dwmw2
On Mon, 2002-11-25 at 21:34, David Woodhouse wrote:
>
> [email protected] said:
> > I have omnibook xe3, will boot without ACPI but USB will not work due
> > to interrupt routing problems. It has buggy PIR$ table, acpi tables
> > are okay. Of course it is HP bug.
>
> BIOS authors are universally shite. Film at 11.
Not quite all of them. There are a few good ones out there, but not many
On Mon, 25 Nov 2002, David Woodhouse wrote:
>
> [email protected] said:
> > I have omnibook xe3, will boot without ACPI but USB will not work due
> > to interrupt routing problems. It has buggy PIR$ table, acpi tables
> > are okay. Of course it is HP bug.
>
> BIOS authors are universally shite. Film at 11.
>
> If it didn't have working ACPI tables either, what would we do? Probably fix
> it with a DMI table entry. This box probably doesn't actually require ACPI
> to boot.
Is this the same problem that Intel L440GX Motherboards have. In order to get
it to boot I need to compile a custom kernel with acpi enabled. I am told it
is some kind of irq routing problem and only Intel can fix it with a BIOS update
which they do seem interested in addressing. :-( Sure would be nice to be able
to boot stock Red Hat kernels on this machine.
--
.............Tom "Nothing would please me more than being able to
[email protected] hire ten programmers and deluge the hobby market
with good software." -- Bill Gates 1976
We are still waiting ....